Without a map, every audit starts from nothing. With one, every audit starts from yesterday’s answers.

A company that follows several rulebooks soon discovers that they overlap heavily. Almost all of them care about who has access, how people prove who they are, how access is approved and removed, how activity is recorded and how changes are controlled. The wording differs, the numbering differs, but the ideas repeat.

Without a map, each audit becomes a new project. Staff search for evidence, argue about which screen proves what, and answer the same question in four slightly different ways. Answers drift, and a careless inconsistency can cause an auditor to doubt everything else.

• Less repeated work. One piece of evidence answers many requirements.
• Fewer surprises. You find gaps before the auditor does.
• Clearer ownership. Each control has a named person, not a vague team.
• Faster onboarding of new frameworks. A new rulebook mostly maps onto controls you already have.
• Better engineering. Seeing the requirement beside the setting shows why a setting exists and what depends on it.

Mapping is not paperwork for its own sake. It is the habit of being able to say, for any setting, “this is why we have it,” and for any requirement, “this is how we meet it.”

A clear definition keeps expectations realistic and conversations with auditors honest.

Control mapping is the practice of linking three things: a requirement in a framework, a control your organisation operates, and the specific Okta configuration and evidence that make that control real.

What it is

• A table of relationships that is kept up to date.
• A way to reuse evidence across audits.
• A conversation tool between engineers, risk managers and auditors.

What it is not

• It is not certification. A product cannot make you compliant; your whole organisation, over time, with evidence, does.
• It is not a claim that Okta covers a requirement. Okta supplies tools; you configure and operate them.
• It is not a one-off document. Settings and rulebooks change, so the map must be maintained.
• It is not a replacement for judgement. Auditors decide whether a control meets a requirement.
• It is not only for security people. HR, IT operations, legal and application owners all hold pieces.

A handful of words appear again and again. Learn them once and the rest of the guide reads easily.

Keep apart two ideas that auditors treat very differently: design and operation. A beautifully designed control that nobody runs fails the second test. A control run perfectly with a poor design fails the first.

You do not need to memorise any framework. You need to know what each one cares about, so you can see the overlaps.

Notice that the third column contains almost the same words in every row. That is the opportunity.

The most common misunderstanding in audits is who is responsible for what.

Okta runs a cloud service. It is responsible for operating that service securely: its data centres, its software, its staff, its availability. You are responsible for how you configure and use it: who you give access to, which policies you set, how you review, how you respond to alerts.

• Collect Okta’s published assurance reports and review them yearly.
• Read the user entity controls section of such reports: they list what customers must do.
• Write down which of your controls depend on Okta and which are yours alone.

A control that is vague cannot be tested. A good statement says who, what, how often and how it is proven.

Write each control as a short sentence with five parts: who does it, what they do, when or how often, on what and what evidence it leaves.

• Avoid words you cannot test: appropriate, adequate, regularly.
• State the frequency in numbers.
• Name the system of record where evidence lives.
• Name the owner by role.

The heart of the method: map each framework to your own list, not to each other.

flowchart LR
    F1["Security attestation"] --> C["Your common control set"]
    F2["Information security standard"] --> C
    F3["Payment card standard"] --> C
    F4["Health privacy rules"] --> C
    F5["Privacy law"] --> C
    C --> O["Okta settings and processes"]
    O --> E["Evidence"]
    E --> A["Audits and attestations"]
    

If you map framework to framework, the number of links grows quickly: five frameworks need ten pairs. If you map each to a common set, you need only five links. Adding a sixth framework adds one more.

• Write the common set in your own words, at a level that engineers understand.
• Keep it small: dozens, not hundreds.
• Give each control an identifier that never changes, even if wording does.
• Map each framework requirement to one or more common controls.
• Note where a requirement is not fully met by any control: that is a gap.

Before mapping, list what you actually have to map with.

Mapping starts with an honest inventory. A control built on a feature you did not buy, or have not turned on, will fail the first test.

A working map has a few parts. Seeing them together makes the later chapters easier.

flowchart TD
    FW["Framework requirements"] --> MAP["Control map: requirement to control"]
    CS["Common control set with owners"] --> MAP
    MAP --> CFG["Okta configuration: policies, roles, lifecycle"]
    CFG --> EV["Evidence sources: exports, System Log, tickets"]
    EV --> REP["Evidence library"]
    REP --> AUD["Auditors and assessors"]
    CFG --> MON["Monitoring and alerts"]
    MON --> CS
    AUD -->|"Findings"| CS
    

The feedback loop is easy to forget. A map that never changes is a map that is wrong.

Follow Northgate’s auditor as she asks, “Show me how leavers lose access.”

sequenceDiagram
    participant A as Auditor
    participant C as Compliance lead
    participant M as Control map
    participant O as Okta and evidence library
    A->>C: How do leavers lose access?
    C->>M: Look up control IAM-04
    M-->>C: Owner, description, evidence sources
    C->>O: Fetch population of leavers and sample records
    O-->>C: Termination tickets, Okta events with timestamps
    C->>A: Provide control description and evidence
    A->>C: Select sample of 25 leavers
    C->>O: Retrieve evidence for each
    O-->>C: Matching tickets and events
    C->>A: Evidence package
    

When this works smoothly, the answer takes an hour, not a week. The speed comes from decisions made earlier: the control is described, the evidence has a home, and the population can be listed.

Nearly every framework asks how people get access, change it and lose it.

• Define how fast is prompt. Say 24 hours or four hours, in the control.
• Measure the actual gap between HR record and Okta action.
• Include contractors, who often come from outside the HR system.
• Prove the control for all applications, including those not connected to Okta.

How people prove who they are is a theme in every framework.

• List which applications fall under each rule.
• Prove the policy applies to everyone in scope with no unexplained exceptions.
• Keep a register of exceptions with approval and end dates.
• Back the policy with tests and exports that show it is on.

Be precise about what you claim. “Second step required for these twelve applications for all employees” is testable. “Strong authentication everywhere” is not.

Frameworks want people to have the access they need and no more.

• Define roles that match job functions and map them to groups.
• Assign access through groups, not individually.
• Keep roles small: separate read from change.
• Record who approved each non-standard grant.
• Remove unused access regularly.
• Treat sensitive applications with extra approval.

When describing least privilege to an auditor, bring numbers: how many roles, how many people per role, how many exceptions. Concrete figures build trust.

Administrators and powerful accounts get extra attention from every auditor.

• Keep the list of administrators current and reviewed every quarter.
• Show who approved each role.
• Use custom roles to limit what each administrator can do.
• Review changes made by administrators, not only who they are.

How long people stay signed in, and from where, matters to several frameworks.

• Set maximum session length and idle limits suitable to the risk.
• Require re-authentication for sensitive actions.
• Limit access by network and device state for sensitive applications.
• Record exceptions and why they exist.
• Make sure remote access follows the same rules.

Almost every framework asks: do you check, regularly, that people still need their access?

An access review asks the owner of an application or a manager to look at who has access and confirm or remove each person. It is one of the strongest pieces of evidence you can provide, because it shows a repeated human check.

• Make reviews meaningful: reviewers should know what each role allows.
• Avoid rubber stamping: track how many items are changed.
• Review privileged and sensitive access most often.
• Keep proof of removal, not only the decision.

No single person should be able to complete a sensitive process alone.

• Write the conflicting pairs of roles down.
• Check that no one holds both, or that an exception is approved and compensated.
• Review combinations in access reviews.
• Block self-approval in request flows.

Rules about credentials remain in most frameworks, even as passwordless grows.

• Minimum strength and length set by policy.
• Prohibition of known weak passwords where supported.
• Lock-out after repeated failures.
• Secure recovery that cannot be abused.
• No shared accounts and no default passwords.
• Protection of secrets used by systems.

Some frameworks change their guidance as research changes. Make sure your control reflects the current text, and be ready to explain deliberate differences, such as favouring length over frequent changes.

Where and on what a person connects affects risk.

• Define trusted places and keep the list current.
• Block or challenge unknown or high-risk places.
• Require managed devices for sensitive systems.
• Keep a register of exceptions, such as emergency access from personal devices.
• Test the rules regularly.

If it is not recorded, it did not happen as far as an auditor is concerned.

Every framework wants a record of who did what and when, kept safe from tampering and actually looked at. Okta’s event log records sign-ins, changes to policies, role assignments and many other events. A log nobody reads is only half a control.

• Define which events matter: administrator changes, policy changes, repeated failures, privileged sign-ins.
• Show who reviews alerts and how fast.
• Keep records that reviews happened, even when nothing was found.
• Test that alerts fire.

Changing a sign-in rule is a change to a security control, and frameworks treat it that way.

• Every change to a policy, role or integration has a request, a reason and an approver.
• Changes are tested before release.
• Changes are recorded with the person and time.
• Emergency changes follow a fast path that is documented and reviewed afterwards.
• The live setup is compared with the approved setup to detect unauthorised change.

A neat trick: for each sampled change ticket, show the matching administrator event in the log. The two together are strong evidence.

Frameworks often ask that development and live systems be kept apart.

• Use a separate Okta environment for testing configuration, if your plan allows.
• Keep real customer data out of test.
• Limit who can change production to fewer people than who can change test.
• Make sure test accounts are labelled, protected and reviewed.
• Document how changes move from test to production.

Identity systems hold personal data: names, emails, phone numbers, sometimes more. Privacy rules apply to them.

Privacy frameworks care about what you collect, why, how long you keep it, who can see it, where it goes and how people can exercise their rights. Many of these can be mapped to identity controls.

• Keep a data map of every attribute in Okta: purpose, source, who sees it, retention.
• Write a process for rights requests and test it.
• Record where your Okta tenant is hosted and what that means for transfers.
• Review attributes quarterly and remove those you do not use.

Every application connected to Okta is a vendor relationship and a path for data.

• Keep a register of connected applications, with owner, data classification and date connected.
• Approve new integrations through a defined process.
• Review the permissions each integration receives.
• Remove unused integrations regularly.
• Check vendor assurance reports for important suppliers.
• Protect API tokens and secrets used by integrations.

When something goes wrong, identity is often the first place to look and the first lever to pull.

• Write a playbook for a taken-over account: disable, revoke sessions, reset second steps, review activity.
• Write a playbook for suspected administrator compromise.
• Define who can suspend access quickly and how that is approved after the fact.
• Record each incident with timeline and lessons.
• Test playbooks with exercises and record the results.

Auditors like to see one real example, handled start to finish, with the records. Keep good records of small incidents too.

Frameworks that care about availability ask what happens if the identity system fails.

• Know the availability record of Okta and how you can follow service status.
• Plan for outage of Okta: how will staff reach critical systems?
• Keep emergency access accounts that do not depend on Okta, with strong protection and alerts.
• Document recovery steps and who performs them.
• Test the plan at least yearly.
• Back up your own configuration so you can rebuild.

Auditors will accept some evidence from the vendor and insist on the rest from you.

• Obtain Okta’s reports under the right agreement and store them in the library.
• Read the scope: what was included, what was not.
• Map each complementary user entity control in those reports to one of your controls.
• Do not over-rely: platform assurance does not prove your configuration.

The matrix is the working document. Start small and make it useful.

• Give each control a stable id.
• Keep one row per control, and list frameworks in a column, or keep a second table of requirement-to-control links.
• Mark each control as automated or manual.
• Add status: designed, operating, gap.
• Review the matrix at least twice a year.

Not all evidence is equal. Choose the sources that are hardest to argue with.

• Prefer exports over screenshots when a choice exists.
• Always show date and time and the system they came from.
• Keep a note of how evidence was gathered, so it can be repeated.
• Remove personal data that is not needed to prove the control.

Evidence collected by hand, a few days before an audit, is evidence you will dislike gathering.

• Schedule regular exports of policies, roles and group rules to the library.
• Record access review results as they complete.
• Stream events to a store with search.
• Create reports that list populations: leavers, joiners, administrators.
• Tag evidence with control ids at the moment it is stored.
• Keep a manifest of what should arrive each month and alert if it does not.

Take one real control and see how it answers several rulebooks at once.

Consider IAM-04: Leavers lose access within 24 hours of the HR termination record. Different frameworks phrase the need differently, but this one control and its evidence answer all of them.

• Write the control once, with its numbers.
• List the evidence once.
• Add a row to the framework table whenever a new framework arrives.
• Tell the auditor which requirement id you believe is answered, and let them confirm.

A map too coarse says nothing. A map too fine is never updated.

• Map at the level of a control and its evidence.
• Group related settings under one control.
• Link to the evidence, not to the screen.
• Record assumptions, such as the version of the framework.

A good test of granularity: if a setting changes, can you tell in under a minute which controls are affected? If not, the map is too coarse. If you must update twenty rows, it is too fine.

A control without an owner is a hope.

• Name owners by role and person.
• Plan backup owners for holidays and departures.
• Include control duties in job descriptions.
• Hold a short quarterly meeting to review controls and evidence.
• Make owners sign their control descriptions once a year.

No organisation meets every requirement perfectly. Honest handling of gaps earns trust.

flowchart TD
    A["Requirement mapped to a control"] --> B{"Is the control designed to meet it?"}
    B -->|"No"| C["Gap: design needed"]
    B -->|"Yes"| D{"Does it operate and leave evidence?"}
    D -->|"No"| E["Gap: operation or evidence needed"]
    D -->|"Yes"| F["Met"]
    C --> G{"Can it be fixed soon?"}
    E --> G
    G -->|"Yes"| H["Remediation plan with owner and date"]
    G -->|"No"| I["Compensating control with risk acceptance"]
    

• Record every gap with owner, plan and date.
• Use a compensating control only when the original is truly impractical, and show it gives similar protection.
• Get risk acceptance signed by someone with authority.
• Share known gaps with auditors early; surprises are punished more than gaps.
• Review the gap list every month.

Every environment has exceptions. Hidden ones damage trust; recorded ones show maturity.

• Keep an exception register: what, who, why, risk, approver, end date.
• Make exceptions expire. A renewal needs a fresh decision.
• Review the register in the quarterly control meeting.
• Look for patterns: many exceptions to one control suggest the control is wrong.
• Show auditors that exceptions are rare, approved and temporary.

Some audits look at one day; others look at a whole period. Your evidence must fit.

• For period audits, keep monthly snapshots and logs for the whole period.
• Make sure changes in the period are explained.
• Note any gaps in the evidence, such as a month with missing exports, and explain them.
• Practise continuous monitoring: alerts when a control stops working, so you are never surprised.

Continuous assurance is gentler than audit season. A small daily check replaces a large yearly scramble.

Auditors are not enemies. They want clear evidence delivered calmly.

• Hold a kick-off meeting to agree scope, period, systems and timeline.
• Give them a walkthrough of the control map, not a pile of files.
• Provide evidence in an organised, dated form, labelled with control ids.
• Answer exactly the question asked, with the evidence for it.
• If you do not know, say so and promise a time; do not guess.
• Keep a log of requests and responses.
• Hold a close-out meeting to learn from findings.

Evidence can be perfect and still fail if the person explaining it is lost.

• Run a mock interview with each control owner before the audit.
• Give each owner a one-page summary of their control and evidence.
• Teach everyone the rule: tell the truth, answer the question, stop talking.
• Agree who is the single point of contact.
• Prepare for follow-up questions: why this setting, who approved it, what happens when it fails.
• Make sure nobody edits evidence after the period to look better.

A map is only as good as its last update.

• Make the map part of the change process: a policy change includes a map check.
• Keep version history of the map.
• Have a named editor responsible for accuracy.
• Set reminders for framework revisions.

You can start with a spreadsheet. As the number of frameworks grows, consider more.

• Choose tooling after the control set is clear.
• Check the tool’s integration with Okta: what does it read, with what permissions?
• Give such tools read-only access with the least rights needed.
• Ensure the tool itself is a controlled system with its own access reviews.

A framework applies to a defined set of systems, people and data. Getting scope right saves enormous effort.

• List the systems that store or process the protected data: cards, health records, customer data.
• List the people and roles who can reach those systems.
• Decide which Okta applications and groups fall inside the scope.
• Draw a clear boundary: what is in, what is out, what connects them.
• Reduce scope where you can: fewer systems in scope means fewer controls to evidence.
• Write the scope statement down and have auditors agree it early.

Because Okta controls access to in-scope systems, the Okta tenant itself is almost always in scope, even if it holds no protected data. That means its administrators, policies and logs are in scope too.

Compliance programmes fail in predictable ways. Plan for them.

flowchart TD
    A["Problem found in the compliance programme"] --> B{"What kind?"}
    B -->|"Evidence missing for a period"| C["Explain gap, collect alternatives, fix collection"]
    B -->|"Control not operating"| D["Disclose, remediate, record date"]
    B -->|"Map out of date"| E["Update map, re-check affected controls"]
    B -->|"Owner left"| F["Reassign, brief successor, review evidence"]
    B -->|"Platform change broke a control"| G["Restore setting, update tests, add monitoring"]
    C --> H["Lessons recorded and process improved"]
    D --> H
    E --> H
    F --> H
    G --> H
    

After any failure, ask two questions: why did the control fail, and why did we not notice sooner? The answer to the second is usually a missing alert.

Someone will ask whether the mapping work is worth it. Prepare a plain answer.

Illustrative arithmetic: suppose Northgate spent 1,600 hours on four audits last year at 70 dollars an hour, or 112,000 dollars. A shared map and evidence library cut that by 40 percent, saving about 44,800 dollars. If building and keeping the map costs 25,000 dollars a year, the net gain is about 19,800 dollars, before counting faster customer questionnaires and fewer findings. Use your own figures.

No approach is perfect. Say plainly what you gain and what you pay.

State the downsides when you propose the programme. Leaders trust plans that name their own risks.

Patterns are habits worth repeating. Anti-patterns are traps others have already fallen into.

Some ideas sound sensible but lead teams astray.

Zero trust and compliance often pull in the same direction. The map can show it.

Zero trust asks you to verify every request, give the least access and assume breach. Many framework requirements say the same in older words. Mapping them together shows that effort spent on zero trust also builds compliance evidence.

When a leader asks, “Why are we doing this?”, you can answer both ways: it reduces real risk and it satisfies the auditor.

Evidence often contains the very personal data you are trying to protect.

• Store the evidence library in a place with restricted access and its own review.
• Mask personal data in samples where the control does not need it.
• Share evidence with auditors through secure channels, not email attachments.
• Keep evidence for the retention period required, then remove it.
• Record who accessed the evidence library.
• Do not copy production secrets or tokens into evidence.

Large organisations rarely have one set of rules.

• Identify which regions and units fall under which frameworks.
• Aim for one global baseline and add local extras only where required.
• Record differences in the map: the same control with a stricter number in one region.
• Check where data is stored and whether Okta organisations are separate by region.
• Keep local owners for local rules, with a central coordinator.
• Plan for acquisitions: new units bring their own systems and gaps.

A short list to read before every audit and every quarterly review.

• A common control set exists, written in plain language, with stable ids.
• Every control has a named owner, a frequency and a defined evidence source.
• Each framework requirement is mapped to one or more controls, using the official text and version.
• The map distinguishes design evidence from operation evidence.
• Scope is written and agreed with auditors.
• Okta capabilities used in each control are confirmed to be available in your edition.
• Evidence is system-generated, dated and tagged, and collected on a schedule.
• Okta’s own assurance reports are collected, reviewed and mapped to your controls.
• Access reviews, leaver checks and administrator reviews run on schedule and are signed.
• Logs are streamed, retained and reviewed, with alerts tested.
• Gaps, exceptions and compensating controls are recorded with owners and dates.
• Control owners rehearse auditor conversations.
• The evidence library is protected and reviewed.
• The map is updated when settings, applications, people or frameworks change.
• Lessons from every audit become improvements.

Let us solve the problem from the start of this guide, step by step.

flowchart LR
    S["Scope and frameworks"] --> CS["Common control set: 34 controls"]
    CS --> MAP["Requirement mapping"]
    MAP --> GAP["Gap list and plans"]
    CS --> AUTO["Automated evidence library"]
    AUTO --> MOCK["Mock audit"]
    GAP --> MOCK
    MOCK --> LIVE["Real audits"]
    LIVE --> REV["Quarterly review"]
    REV --> CS
    

Nine months later, the hospital client sends a long security questionnaire. Using the map, Northgate answers 80 percent of it from existing evidence in two days, instead of three weeks. The auditor for the card standard asks for the list of administrators and the last review, and receives both within the hour.

Numbers make the stakes visible. All figures are illustrative and meant to show the thinking, not to predict your results.

Scenario 1: Overlap

Four frameworks together list roughly 600 requirements. Mapping them to a common set shows that about 150 of them touch identity and access. Those 150 collapse into 34 controls. Instead of gathering evidence for 150 items four times, Northgate gathers it for 34 controls once, a reduction of more than 75 percent in the number of evidence packages.

Scenario 2: Leaver Timing

In a year Northgate has 180 leavers. The control says access is removed within 24 hours. A population report shows 171 removed within 24 hours, 7 within 48 hours and 2 later than a week because the leaver was a contractor outside the HR feed. That is a 95 percent success rate, and the two late cases are explained, fixed and used to justify bringing contractors into the feed.

Scenario 3: The Missing Month

A scheduled export fails in March and nobody notices. In the yearly audit, March evidence is missing. A manifest check, which alerts when an expected file does not arrive, would have caught it within a day. The cost of the check is an hour of setup.

You do not need to solve everything at once. Small steps beat grand promises.

The first 90 days

When someone says “the auditor wants proof and we cannot find it,” follow the same steps each time.

• State the exact request: which control, which period, which auditor.
• Find the control in the map and read the evidence sources.
• Check whether the evidence exists and is complete.
• If not, explain honestly, supply alternatives and fix the cause.
• Update the map and the process so it does not happen again.

Before listing any setting as a control in the map, ask the same short questions.

flowchart TD
    A["Setting or process in Okta"] --> B{"Does it meet a requirement or reduce a named risk?"}
    B -->|"No"| C["Not a control; leave it out of the map"]
    B -->|"Yes"| D{"Is there an owner and a frequency?"}
    D -->|"No"| E["Assign them first"]
    D -->|"Yes"| F{"Does it leave evidence you can retrieve?"}
    F -->|"No"| G["Create evidence: export, log, ticket or review"]
    F -->|"Yes"| H{"Is it available in our Okta edition and turned on?"}
    H -->|"No"| I["Do not map until it is"]
    H -->|"Yes"| J["Add to the control set and map requirements"]
    

• If you cannot say which requirement it serves, it may still be a good setting but it is not part of the map.
• If it has no evidence, an auditor will treat it as if it did not exist.
• If it depends on a feature you do not have, it is a plan, not a control.

Most programmes stumble on small details nobody wrote down.

Teams repeat the same early errors. Knowing them is a cheap kind of experience.

A strong design that people work around protects nothing. Colleagues must see the point and find the new way workable.

• Start with a story. Four audits, four screenshots, two lost weeks makes the point.
• Show a finished control. One example with owner, evidence and mapping beats a slide deck.
• Keep the effort small. Ask owners for ten minutes a month, not ten hours a quarter.
• Automate first. People accept a control that produces its own evidence.
• Celebrate catches. Share the gaps the map found before an auditor did.
• Make audits less scary. Rehearse, then reward calm.
• Link to customer wins. Show how the map speeds up security questionnaires and sales.

People move on. The programme must keep working without them.

• The control set and map: versioned, with owners.
• Evidence manifest: what should arrive, from where, how often.
• Runbooks: how to run exports, process reviews, answer a questionnaire.
• Gap and exception registers: with owners and dates.
• Audit calendar: periods, windows, contacts.
• Lessons log: what each audit taught.

Test the documents. Give a runbook to a new colleague and watch. Where they stumble, the document needs repair.

A concrete picture shows how the pieces behave together.

Nothing dramatic happens. That is the sign of a healthy programme: small items handled early, evidence arriving on its own and auditors who find answers in the first place they look.

Customers send long questionnaires. The map answers most of them.

• Keep a standard answer library linked to control ids.
• Review answers after every audit and major change.
• Have a reviewer check every answer for accuracy; a wrong answer is worse than a late one.
• Share reports under agreement rather than pasting details into forms.
• Keep a record of what was told to whom.
• Escalate unusual questions to the compliance lead.

Okta and the frameworks change often. A map that was right last year can quietly become incomplete.

• Read Okta release notes on a schedule. Thirty minutes a month is usually enough.
• Subscribe to framework revision announcements and plan re-mapping time.
• Keep a list of assumptions your controls depend on, such as how long logs are kept, and retest when a change touches one.
• Watch for renamed features and edition changes.
• Test changes in a preview environment before they reach production.
• Plan time each quarter for small updates rather than one big project every few years.

Write down which Okta features each control depends on. When a change is announced, you will know within minutes whether it matters.

Frameworks care about everyone who can reach protected systems, not only staff.

Contractors, agency workers, partner staff and customers with administrative rights often sit outside the HR system. They are exactly the group where leaver controls, access reviews and strong authentication tend to have holes. Auditors know this and ask about it.

• Include these populations in every population report.
• Give each contractor a sponsor who answers for them.
• Set automatic end dates and review them.
• Apply the same authentication standard as employees, or a stricter one.

Programs, scripts and integrations sign in too, and frameworks expect them to be controlled.

• Keep an inventory of service accounts and tokens, with owner and purpose.
• Apply least privilege: only the access each integration needs.
• Rotate secrets on a schedule and after staff changes.
• Monitor their use for odd behaviour.
• Review them in the same cycle as human access.
• Record exceptions, such as accounts that cannot use a second step, with compensating controls.

Compliance is a team sport. Map people as carefully as you map settings.

• Draw a simple chart of who feeds whom.
• Agree service levels between teams: for example, HR sends termination records within one hour.
• Hold a short joint review each quarter.
• Keep internal audit independent from the people who run the controls.

Controls need measurements, just as engines need gauges.

• Review the measures quarterly with owners.
• Use them as signals, not scores for punishing people.
• Beware of gaming: a high number of controls with weak evidence is worse than a few strong ones.

Quick plain-language meanings for the words used in this guide.

Short answers to questions that come up in almost every project.

Mapping turns what you already do in Okta into answers for every auditor, once.