A company can have perfect authentication and still be badly exposed. The gap between “this really is Maria” and “Maria should have this access” is where governance lives.

Three Questions, Three Disciplines

Access management answers three separate questions. Confusing them is the root of many weak programs.

How Access Rots

Access is not static. It decays in predictable ways, and every one of them is invisible to an authentication system.

• Privilege creep. People change roles and collect permissions. Nobody removes the old ones, so a long-serving employee ends up with far more access than any single job needs.
• Orphan accounts. Accounts that belong to nobody active, such as a leaver’s account in an app that was never connected to the central process.
• Over-provisioning. A new hire is “set up like Dana” and receives everything Dana has, including things Dana needed only for a one-off project.
• Toxic combinations. Two permissions that are harmless alone but dangerous together, such as creating and approving the same payment.
• Stale approvals. An approval from three years ago is treated as permanent, though the reason may have ended.
• Unknown ownership. Nobody can say who is responsible for deciding who gets access to a given app.

Identity governance and administration, often shortened to IGA, is a field with its own history and vocabulary. A clear definition keeps projects focused.

A Plain Definition

Identity governance is the set of processes and tools that make sure the right people have the right access to the right resources for the right reasons, and that you can show evidence of this at any time. It combines three activities: deciding who should have access, enforcing that decision by creating and removing accounts and permissions, and verifying over time that the decision is still correct.

The Four Pillars

What Governance Is Not

Governance has a precise vocabulary. Learning these terms once makes everything that follows easier to read and to discuss with auditors.

Before any tool is configured, decide how access will be organized. The model you choose determines how easy reviews, requests, and audits will be for years.

Three Ways to Decide Who Gets What

Mature programs use all three, each for what it does best. Standard access for a job is granted by role or attributes, so it appears automatically. Special access is requested, approved, and given an end date. Everything is reviewed on a schedule.

The Layered Model

flowchart TD
    P["Person: attributes from HR"] --> BR["Birthright access: automatic for everyone"]
    P --> RL["Role access: from job, department, location"]
    P --> RQ["Requested access: approved, time-limited"]
    BR --> ACC["Effective access in applications"]
    RL --> ACC
    RQ --> ACC
    ACC --> RV["Periodic review and certification"]
    RV -->|"Revoke"| ACC
    

Groups, Roles, and Entitlements in Okta

In Okta, the most common building block is the group: a collection of users to which apps and policies can be assigned. Governance thinking adds two finer layers. A role is a business-level idea that usually maps to one or more groups. An entitlement is a permission inside an application. For apps that support it, Okta can manage entitlements and bundle them, so that a request can say “I need the Claims Adjuster bundle” rather than a list of twelve individual permissions. The mapping looks like this.

Okta provides governance through a set of connected capabilities. Knowing what each does, and where its boundary lies, prevents both gaps and overlaps.

The Main Capabilities

The Big Picture

flowchart LR
    HR["HR system: source of truth"] --> UD["Universal Directory"]
    UD --> LCM["Lifecycle Management"]
    LCM --> APPS["Connected applications"]
    REQ["Access requests"] --> APPR["Approvers"]
    APPR --> LCM
    CERT["Access certification campaigns"] --> REV["Reviewers"]
    REV -->|"Revoke"| LCM
    SOD["Separation of duties rules"] --> REQ
    SOD --> CERT
    WF["Workflows"] --> REQ
    WF --> CERT
    LCM --> LOG["System Log and reports"]
    REQ --> LOG
    CERT --> LOG
    

Where Okta Ends

No platform governs everything. Okta governs the identities and the applications connected to it. Permissions that live outside connected apps, such as local accounts on servers, database roles, or cloud platform permissions, may need other tools or may need integration work to be visible. Part of a good governance foundation is an honest list of what is inside the scope and what is not.

Governance is only as good as the data flowing into it. This chapter traces where facts come from, how decisions are made, and where results go.

Four Kinds of Data

From Event to Evidence

flowchart TD
    E1["Event: new hire recorded in HR"] --> S1["Okta creates identity and sets attributes"]
    S1 --> S2["Rules assign groups and birthright apps"]
    S2 --> S3["Lifecycle provisions accounts in apps"]
    S3 --> S4["Person asks for extra access"]
    S4 --> S5["Approvers decide, SoD check runs"]
    S5 --> S6["Access granted with end date"]
    S6 --> S7["Campaign asks reviewer to confirm"]
    S7 --> S8["Reviewer confirms or revokes"]
    S8 --> EV["Evidence stored: who, what, when, why"]
    

The Principle of One Source Per Fact

Every fact should have exactly one authoritative source. A person’s employment status comes from HR. A person’s department comes from HR. An application’s owner comes from the application inventory. Permissions inside an app come from the app itself, read through connections. When two systems both claim to own a fact, they fight, and governance decisions flip randomly. Decide the source for each fact early, write it down, and make every other system a reader of that source.

Reading Access: The Hard Part

Granting access is easy compared to seeing it. To review who has what, the governance system must read the real state of each application, not just what it last pushed. Okta’s connections can import accounts and, for supported apps, entitlements. For apps without a good connection, the data may arrive through files, scripts, or manual exports. The quality of your reviews is limited by the quality of this reading. A review of stale data is a ceremony, not a control.

Every governance decision starts with a fact about a person. If those facts are wrong, the best tooling in the world produces confident mistakes.

Why Data Quality Comes First

Group rules, role assignment, approvers, and review assignments all read profile attributes. If the manager field is empty, requests have no approver and reviews have no reviewer. If the department field has five spellings of “Finance,” a rule that grants finance access misses most of the team. If employment status is wrong, leavers stay active. Teams often rush to buy governance tools and then spend months discovering that their data was never good enough to use. Fixing data first is not glamorous, but it is the highest-value work in the whole program.

The Attributes That Matter Most

Making HR the Source

For employees, the HR system is the natural source of truth. Okta can import people from HR systems and keep them in step, so that a hire, a transfer, or a termination in HR becomes an event in Okta within minutes. For contractors and partners, which HR often does not hold, you need another authoritative source, such as a vendor management system or a sponsor-driven process in which a named employee vouches for the person and sets an end date. Without such a source, contractors become the largest group of accounts that nobody owns.

You cannot govern what you have not listed. An application inventory with owners and risk levels decides where reviews should be frequent, and where they can be light.

Build the Inventory

Start with what is already connected to Okta, then widen. Sources of unknown applications include finance records of software purchases, network logs showing sign-in pages, browser extension reports, and simply asking departments. For each app, record the following.

Tiering

Why Tiering Saves Effort

A company with two hundred applications cannot review them all with the same intensity. Tiering lets you spend attention where risk lives. Reviewers face fewer, more meaningful decisions, and quality improves. Without tiering, reviewers drown in requests to approve access to low-risk tools, and begin to approve everything automatically, including the dangerous items.

flowchart TD
    A["Application found"] --> B{"Handles financial, personal, health or admin data?"}
    B -->|"Yes, critical"| T1["Tier 1: frequent review, strict approval"]
    B -->|"Yes, sensitive"| T2["Tier 2: twice a year, owner approval"]
    B -->|"No"| C{"Used by many people for ordinary work?"}
    C -->|"Yes"| T3["Tier 3: yearly review"]
    C -->|"No, low risk"| T4["Tier 4: birthright, light review"]
    

Groups and roles are the building blocks that turn people data into access. Careful design here makes everything else easier. Careless design makes everything harder.

Principles for Good Groups

• One purpose per group. A group should mean one thing, such as “Finance analysts” or “Payroll app users,” not a mix of both.
• Name with a pattern. A prefix that says what the group is for, such as role, app, or policy, makes reviews and searches far easier.
• Every group has an owner and a purpose line. The description answers “why does this group exist?”
• Prefer rule-based membership. Let attributes from HR drive membership, so people move in and out automatically. Hand-made membership should be rare and reviewed.
• Avoid nesting that confuses. Deep chains of group-inside-group make it hard to see why someone has access.
• Separate role groups from policy groups. A group that means “Finance staff” should not also be used as a security exception list.

Role Design: Top-Down and Bottom-Up

The best approach combines both. Mine the existing data to see what exists, then review the draft roles with owners, remove access that is not justified, and fix the final design top-down. Treat mined results as evidence, not as truth.

How Many Roles Are Too Many?

Role explosion is a common failure. If every small difference becomes a new role, a company with 3,000 people ends up with 2,500 roles, which is close to one role per person and defeats the point. A useful rule is to start with a small number of broad roles, plus well-defined add-on bundles for common extra needs, and use requests for the rare cases. If you have more roles than managers can name, the model is too fine.

flowchart LR
    ATTR["HR attributes: department, job code, location"] --> RULE["Group rules"]
    RULE --> RG["Role group: Claims Adjuster"]
    RG --> BUN["Entitlement bundle: standard claims access"]
    RG --> APP["App assignments: claims system, email, intranet"]
    EXTRA["Approved request"] --> ADD["Add-on bundle with end date"]
    ADD --> PERSON["Person's effective access"]
    BUN --> PERSON
    APP --> PERSON
    

Most governance failures begin with a life event that did not reach every system. A reliable joiner-mover-leaver process is the single most valuable control you can build.

Joiners: Day-One Readiness

The goal for joiners is simple: on the first morning, the new person has exactly the access their role needs, no more and no less. The process starts before the start date. HR records the hire with a start date, manager, department, and worker type. At the right moment, Okta creates the identity, rules assign role groups, and lifecycle management provisions accounts. The new hire receives activation instructions, enrolls in strong factors, and opens their apps. Anything beyond standard access is requested through the normal process, not copied from a colleague.

Movers: The Forgotten Case

Movers are the most dangerous group, because adding access for the new role is easy and removing access from the old one is easily forgotten. A good mover process treats the move as two events: remove access tied to the old role, and add access tied to the new one. Role-based groups make this natural, because a change in department attribute changes group membership, which removes old apps and assigns new ones. Requested access, however, does not disappear automatically. A good practice is to trigger a review of all requested and exception access whenever a person’s department or manager changes.

Leavers: Speed and Completeness

For leavers, two things matter: how fast access is removed, and whether it is removed everywhere. Deactivating the Okta account stops sign-in through Okta, but accounts in apps that keep their own passwords, API keys, and long sessions may live on. A complete leaver process also deprovisions accounts in connected apps, revokes tokens, ends sessions, reassigns or archives owned resources such as files and mailboxes, and removes the person from approval chains and reviewer lists.

flowchart TD
    HR["HR event"] --> T{"Type of event"}
    T -->|"Hire"| J1["Create identity and assign role groups"]
    J1 --> J2["Provision birthright apps"]
    T -->|"Transfer"| M1["Recalculate role groups"]
    M1 --> M2["Remove old role access"]
    M2 --> M3["Flag requested access for review"]
    T -->|"Termination"| L1["Suspend and revoke sessions and tokens"]
    L1 --> L2["Deprovision apps"]
    L2 --> L3["Reassign owned items and approver duties"]
    J2 --> LOG["Record in System Log"]
    M3 --> LOG
    L3 --> LOG
    

Measuring the Process

Knowing that someone has an account in the payments system is useful. Knowing exactly what they can do inside it is what governance really needs.

The Problem With “Has Access”

Most early governance work treats access as on or off: you either have the app or you do not. But the real risk is inside. Two people with accounts in the same payments app may have very different power: one can only view reports, the other can release payments. A review that shows “both have access to Payments” tells the reviewer almost nothing. Entitlement-level governance shows “view reports” for one and “release payments, up to a high limit” for the other.

How Entitlements Appear

Bundling for Humans

Raw entitlements are written for systems, not people, and their names are often cryptic: “AP_RLS_04” means little to a manager. Governance platforms let you give entitlements plain names and descriptions, and group them into bundles that match business needs, such as “Accounts payable clerk” or “Accounts payable approver up to 10,000.” Good descriptions are not decoration. They are what lets a reviewer decide correctly. A reviewer who does not understand an entitlement will approve it, because denying something you cannot explain feels riskier than approving it.

Notice that the first two rows together form a classic toxic combination. A person who can create a vendor and release payments to that vendor holds the power to commit fraud alone. Plain names and risk labels make this visible to reviewers, and separation of duties rules can block it automatically.

Coverage Is Uneven

Okta supports entitlement data for a growing list of applications, but not every app exposes permissions in a way a platform can read. For unsupported apps you can still govern at the account level, and bring in entitlement data through files, scripts, or custom connections for the most critical ones. Prioritize by risk: the apps where entitlements matter most are usually financial, administrative, and customer-data systems.

Not all access can be automatic. When a person needs something beyond their standard set, a good request process is fast for the requester, clear for the approver, and rich in evidence for the auditor.

What a Good Request Contains

• What: the specific app, role, or entitlement bundle, in plain language.
• Why: a business reason in the requester’s own words. A free-text field with a sensible minimum prevents “need it.”
• How long: a duration or end date for anything that is not permanent by nature.
• Who approves: determined automatically from the manager, the app owner, and the risk level.
• What it conflicts with: a check against separation of duties rules before approvers see it.

Approval Design

Where Requests Live

People ask for access where they already work. Okta lets users request access from their dashboard, and, where supported, from chat tools such as Slack or Microsoft Teams, where approvers can also respond. Making approval easy matters: if approving takes six clicks in an unfamiliar portal, approvers delay, requesters complain, and people look for shortcuts like sharing accounts.

The Rubber-Stamp Risk

Approvers see dozens of requests. If every request looks identical and carries no context, they approve all of them. To avoid it, show approvers helpful information: the requester’s role and team, what access they already have, how common this request is for their peers, the risk label, and any conflict warnings. Reduce volume by moving common requests into birthright or role bundles. An approver who sees five requests a week with good context will think. One who sees fifty with none will not.

flowchart TD
    R["Requester asks for access with reason and duration"] --> C["System checks risk level and SoD conflicts"]
    C -->|"Conflict found"| BLK["Blocked or sent to exception process"]
    C -->|"Low risk"| AUTO["Auto-approve"]
    C -->|"Needs approval"| M["Manager approves"]
    M --> O["Application owner approves if required"]
    O --> S["Security approves for high risk"]
    AUTO --> G["Access granted by lifecycle engine"]
    S --> G
    G --> E["End date set and request recorded"]
    E --> X["Access removed automatically at expiry"]
    

Reviews are the heart of governance, and the most commonly wasted effort. A review that nobody reads carefully produces paperwork and no safety. This chapter is about making reviews meaningful.

What a Campaign Is

An access certification campaign is a time-boxed review. It selects a scope of access, assigns reviewers, gives them a deadline, asks them to confirm or revoke each item, and records every decision. When it closes, the revoked items are removed, and the whole campaign is stored as evidence.

The Design Choices

Making Reviews Better

• Show context. For each item, show the person’s role, how long they have had the access, when they last used it if the app reports that, and what peers in the same role hold.
• Highlight outliers. Access that most peers do not have deserves a closer look. Put it at the top.
• Reduce volume. Remove low-risk items from review, and split the rest into manageable lists of a few dozen items per reviewer.
• Use plain language. Entitlement descriptions should be understood by the reviewer.
• Remind and escalate. Reminders at the start, middle, and end. Escalate overdue items to the reviewer’s manager.
• Measure quality, not just completion. A 100 percent completion rate with zero revocations should raise questions, not applause.

The Campaign Lifecycle

flowchart LR
    D["Design: scope, reviewers, schedule"] --> L["Launch and notify reviewers"]
    L --> R["Reviewers confirm or revoke"]
    R --> RM["Reminders and escalations"]
    RM --> R
    R --> C["Close campaign at deadline"]
    C --> A["Apply revocations through lifecycle engine"]
    A --> V["Verify removal"]
    V --> E["Store report as audit evidence"]
    E --> I["Improve next campaign"]
    

Event-Driven and Risk-Based Reviews

Calendar reviews alone are blunt. Smart programs add reviews triggered by events: a person changes department, a person is granted a very powerful entitlement, a person’s manager changes, or a security alert involves the account. They also concentrate effort by risk, reviewing high-risk access monthly or quarterly and low-risk access yearly. This puts attention where it matters and keeps reviewers from tiring.

Some risks cannot be solved by reviewing access alone. They require rules that prevent one person from holding dangerous combinations in the first place.

The Idea

Separation of duties says that sensitive processes should be split among several people so that no single person can complete the whole thing alone, whether by mistake or by fraud. A familiar example: the person who writes a cheque should not be the person who signs it. Financial regulations such as those that apply to public companies expect such controls, and auditors test them directly.

Typical Conflicts

Preventive and Detective Controls

You need both. Preventive rules stop new conflicts. Detective scans find old ones, and also catch conflicts that arise through paths the preventive check cannot see, such as access granted directly inside an application.

Handling Exceptions

Sometimes a conflict is unavoidable, especially in small teams where one person must cover several duties. The answer is a documented exception with compensating controls: an owner accepts the risk in writing, the access is time-limited, and extra monitoring or a second reviewer checks the person’s activity. Exceptions should be rare, visible, and reviewed often.

flowchart TD
    REQ["Access request or assignment"] --> CHK{"Conflicts with an SoD rule?"}
    CHK -->|"No"| OK["Continue normal approval"]
    CHK -->|"Yes"| EXC{"Exception allowed?"}
    EXC -->|"No"| DENY["Deny and explain why"]
    EXC -->|"Yes"| ACC["Risk owner accepts in writing with compensating controls"]
    ACC --> TL["Grant with end date and extra monitoring"]
    TL --> REVIEW["Review exception at each campaign"]
    

Administrators hold the keys to everything else. If governance is weak anywhere, it must not be weak here.

Why Privileged Access Is Special

A normal user can damage a small piece of the business. An administrator can change policies, create accounts, read data, and erase evidence. Attackers know this and target administrators first. Auditors know it too, and almost always ask for a list of every administrator and proof that each is justified.

The Governance Pattern for Admins

People are not the only ones with access. Service accounts, API tokens, and connected applications hold power too, and they are the part of governance most often forgotten.

The Non-Human Crowd

Why They Escape Governance

Non-human identities usually have no manager, no HR record, and no leaver event. Their passwords never expire, because rotating them might break something. Their owners change jobs and nobody notices. They often hold high privileges because it was easier to give too much than to work out the minimum. In many breaches, the stolen credential was not a person’s password but a forgotten service account or token.

Bringing Order

• Register every one. Name, purpose, system, owner, backup owner, creation date, and expiry or review date.
• Assign a human owner. A real person is accountable. When the owner leaves, the leaver process reassigns ownership before the account is orphaned.
• Apply least privilege. Narrow scopes and roles, reviewed with the owner.
• Rotate secrets. Store them in a vault and replace them on a schedule. Prefer short-lived tokens over permanent ones.
• Review them like people. Include non-human identities in certification campaigns, with the owner as reviewer.
• Ban sharing. Where a team needs shared access, use named accounts or a privileged access tool that records who used it.
• Watch usage. Alert when a service account signs in from an unexpected place or at an unusual time.

flowchart LR
    NH["Non-human identity: token, service account, OAuth client"] --> REG["Register: purpose, owner, scope, review date"]
    REG --> LP["Apply least privilege"]
    LP --> V["Store secret in vault and rotate"]
    V --> CERT["Include in review campaigns with owner as reviewer"]
    CERT --> MON["Monitor usage and alert on anomalies"]
    OWN["Owner leaves"] --> RE["Reassign owner before offboarding completes"]
    RE --> REG
    

People who are not employees often have as much access as employees, with far less oversight. They deserve their own rules.

Why External Workers Are Different

Contractors, consultants, partner staff, and auditors are not in the HR system, so no leaver event fires when their work ends. They may use their own devices. They change employers without telling you. Yet they often work on the most sensitive projects, because that is why they were hired. In many organizations, external workers are the largest source of stale accounts.

The Sponsor Model

The most reliable control is the sponsor model. Every external person has a named employee sponsor who vouches for them and is responsible for their access. The sponsor sets an end date at the start, which cannot be left blank. As the end date approaches, the sponsor must either renew with a reason or let the account expire. When the sponsor leaves, the leaver process transfers the sponsorship or ends the accounts.

Practical Steps

Let us watch two governance processes from the inside: an access request and a review campaign. Seeing the steps clarifies where delays, errors, and evidence come from.

An Access Request, Step by Step

Ravi, a junior accountant, needs read access to the quarterly payments report for a three-month audit project.

sequenceDiagram
    participant R as Ravi
    participant G as Governance engine
    participant S as SoD checker
    participant M as Manager
    participant O as App owner
    participant L as Lifecycle engine
    participant A as Payments app
    R->>G: Request report access with reason and 3 months
    G->>S: Check conflicts with Ravi current access
    S-->>G: No conflict found
    G->>M: Ask for approval with context
    M-->>G: Approve
    G->>O: Ask for approval as Tier 1 app
    O-->>G: Approve
    G->>L: Grant bundle with end date
    L->>A: Create entitlement for Ravi
    A-->>L: Confirmed
    L-->>G: Grant recorded
    G-->>R: Notify access is active
    G->>G: Schedule automatic removal in 3 months
    

Notice the points where things can go wrong. The conflict check depends on correct data about Ravi’s current access. The approvals depend on correct manager and owner data. The grant depends on a working connection to the payments app. The expiry depends on the engine remembering. Each is a place to monitor.

A Campaign, Step by Step

sequenceDiagram
    participant C as Campaign owner
    participant G as Governance engine
    participant D as Access data
    participant V as Reviewer
    participant L as Lifecycle engine
    participant E as Evidence store
    C->>G: Define scope, reviewers, deadline
    G->>D: Read current access from apps and directory
    D-->>G: Access list with entitlements
    G->>V: Send items with context
    V-->>G: Confirm some, revoke others
    G->>G: Remind and escalate overdue items
    G->>L: Send approved revocations
    L->>D: Remove access in apps
    D-->>G: Confirm removal
    G->>E: Store decisions, timestamps, reviewer identities
    G-->>C: Final report
    

Where Evidence Comes From

Governance that depends on people remembering to do things will fail on a busy Monday. Automation turns good intentions into steady habits.

What Can Be Automated

Okta offers a no-code automation tool called Workflows, and also supports event hooks that send a message to another system when something happens, such as a user being created or a group membership changing. Feature names and limits change over time, so confirm current capabilities in the official documentation before designing around them. The pattern, however, is stable: an event happens, a rule decides, an action follows.

Guardrails for Automation

Automation is a power tool, and power tools need guards. A mistaken rule can remove access from thousands of people in seconds.

• Test in a preview environment first. Run new flows against test users before real ones.
• Limit blast radius. Cap how many accounts a single run may change, and stop and alert if the cap is exceeded.
• Prefer suspend over delete. Suspension can be reversed. Deletion often cannot.
• Log every action. Each automated step should leave a record saying which rule fired and why.
• Own every flow. A named owner, a description, and a review date, just like any other access-related asset.
• Handle failures. If a step fails, retry sensibly, then raise a visible ticket. Silent failure is the enemy.

flowchart TD
    EV["Event: attribute change, expiry, overdue review"] --> RULE{"Rule matches?"}
    RULE -->|"No"| IGN["Ignore and log"]
    RULE -->|"Yes"| CAP{"Under safety cap?"}
    CAP -->|"No"| HALT["Stop and alert a human"]
    CAP -->|"Yes"| ACT["Perform action: notify, suspend, open task"]
    ACT --> LOG["Write log entry with rule name and reason"]
    LOG --> FAIL{"Action succeeded?"}
    FAIL -->|"Yes"| DONE["Done"]
    FAIL -->|"No"| RETRY["Retry then raise ticket"]
    

Most organizations start governance because an audit demands it. Understanding what auditors actually ask for lets you build once and satisfy many.

What Auditors Want to See

Different frameworks use different words, but their identity questions are surprisingly similar: Who has access? Who approved it? Is it still needed? Is it removed promptly when people leave? Are conflicting duties separated? Are administrators controlled? Can you prove all of this?

This table is a simplified orientation, not legal or audit advice. Each framework has its own detailed text and your auditor interprets it for your situation, so always confirm requirements with your compliance team.

Build Once, Map Many

The efficient approach is to design a small set of strong controls and then map each to the requirements it satisfies. A quarterly review of financial-system access, run properly, may serve several frameworks at once. A single leaver process with measured removal times is evidence for all of them.

Making Evidence Easy

• Evidence by design. Choose processes that create records as a side effect, not as an extra chore.
• Immutable storage. Keep reports and logs where they cannot be quietly edited.
• Sampling readiness. Auditors pick random people and ask for the full story. Be able to retrieve request, approval, grant, review, and removal for any one person in minutes.
• Retention. Keep records as long as policy and regulation require, and no longer than necessary.
• Walkthrough documents. Short descriptions of each control, with owner and frequency, save hours of meetings.

The system that decides who gets access is itself a prize. If an attacker controls governance, they can grant themselves anything and erase the trail.

Threats to Governance

Protecting the Controls

• Few governance administrators, each with strong multi-factor sign-in and a dedicated account.
• Change control for rules, with a second person reviewing each change.
• Independent log copy sent to a system the governance admins cannot edit.
• Break-glass accounts sealed, monitored, and tested on a schedule, so that emergencies do not force risky shortcuts.
• Approver independence rules, such as no approving for people who report to you in a conflict of interest.

flowchart LR
    ADM["Governance admin"] -->|"phishing-resistant sign-in"| GOV["Governance rules and campaigns"]
    GOV -->|"every change logged"| LOG["Copy to protected log store"]
    LOG --> SIEM["Security monitoring"]
    SIEM -->|"alerts on rule or role changes"| SEC["Security team"]
    GOV --> CHG["Second person reviews rule changes"]
    

You cannot improve what you do not measure. A handful of well-chosen numbers tells you whether governance is working or just running.

What to Log

Okta records activity in its System Log, which can be queried and streamed to other tools. For governance, make sure these categories are captured and retained, and confirm the exact event names in the current documentation:

• User lifecycle changes: creation, activation, suspension, deactivation.
• Group and role assignment changes, including who made them.
• Application assignments and removals.
• Administrator role grants and changes to policies.
• Access request submissions, approvals, denials, and expirations.
• Certification decisions and revocations.
• Token and API key creation and use.
• Failed provisioning attempts and integration errors.

The Key Metrics

Alerts Worth Having

• A new super administrator, or any change to administrator roles.
• A mass change: many group removals or deactivations in a short time.
• A governance rule or workflow edited outside change control.
• A service account signing in from a new location.
• A leaver whose account is still active after the target time.

A design that works for 200 people may buckle at 20,000. Thinking about scale and failure early prevents unpleasant surprises.

Where Scale Hurts

• Review volume. Reviews multiply: users times apps times entitlements. Without tiering and role-based review, volumes become impossible for humans.
• Provisioning bursts. A merger or a yearly intake of new hires creates thousands of changes at once, which may reach rate limits on Okta or on connected apps. Limits vary by plan and endpoint, so check the current documentation.
• Group sizes and rule complexity. Very large groups and complicated dynamic rules take longer to evaluate and are harder to understand.
• Reconciliation time. Comparing millions of records takes time, so plan windows and avoid peak hours.

Failure Scenarios and Responses

flowchart TD
    CHG["Large change planned"] --> PRE["Preview on test group"]
    PRE --> OK{"Result as expected?"}
    OK -->|"No"| FIX["Fix rule and retest"]
    FIX --> PRE
    OK -->|"Yes"| STG["Stage in batches off-peak"]
    STG --> MON["Watch errors and rate limit signals"]
    MON --> ISSUE{"Problems seen?"}
    ISSUE -->|"Yes"| PAUSE["Pause and roll back batch"]
    ISSUE -->|"No"| NEXT["Continue to next batch"]
    NEXT --> REC["Reconcile at the end"]
    

Governance is not free. An honest view of the costs helps you decide how far to go and in what order.

The Main Trade-offs

Nobody builds a full governance program in one leap. A maturity model shows where you are, and a short roadmap shows the next useful step.

Five Levels of Maturity

The First 90 Days

flowchart LR
    A["Level 1: Ad hoc"] --> B["Level 2: Basic hygiene"]
    B --> C["Level 3: Defined"]
    C --> D["Level 4: Managed"]
    D --> E["Level 5: Optimized"]
    B -.->|"90-day plan targets"| C
    

Patterns are solutions that keep working. Anti-patterns are mistakes that keep recurring. Learning both from others saves you from paying for the lessons yourself.

Patterns That Work

Anti-Patterns to Avoid

A compact list to review before launch and again each year. Each item is a habit, not a one-time task.

Foundations

• HR data has one source of truth, with owners for manager, department, and status fields.
• Every application is in an inventory with an owner, a tier, and a method of connection.
• Groups are named by pattern, owned, and reviewed, and role groups are separate from app groups.
• Leaver, joiner, and mover steps are written down, automated where possible, and measured.

Access Decisions

• Birthright access covers the common needs of each role and nothing more.
• Requests ask for a reason and an end date, and show approvers real context.
• Separation of duties rules protect the most sensitive processes, with documented exceptions.
• Entitlements inside critical apps are described in plain language.

Review and Control

• Reviews are tiered by risk and triggered by events as well as by the calendar.
• Reviewers have context, deadlines, reminders, and escalation.
• Revocations are applied automatically and verified.
• Administrators, contractors, and non-human identities are reviewed more often than ordinary users.

Operations and Evidence

• Logs go to protected storage, and key changes raise alerts.
• Metrics have owners and are reviewed monthly.
• Automation has safety caps, tests, and rollback plans.
• Break-glass access is sealed, monitored, and tested.
• Evidence for any person can be retrieved within minutes.

Here are four short stories from the fictional Westbrook Insurance, plus a worked example of how much review work a good design can remove. All numbers are illustrative, chosen to show the method.

Worked Numbers: Why Design Reduces Review Work

Suppose Westbrook has 6,000 employees and 60 applications, and each person holds on average 12 application accounts. That is 72,000 account assignments. A naive review asks managers to check every one.

The review shrank from 72,000 decisions to roughly 9,000, with about 1,500 deserving real thought. The numbers are invented for explanation, but the pattern is real: governance succeeds by removing what does not need reviewing, so that humans can focus on what does.

Governance turns “we think people have the right access” into “we know, and here is the proof.” It is built on good data, clear ownership, sensible design, steady review, and careful automation.