Before learning any settings, it helps to see how access builds up on its own, and why that build-up is a security and compliance problem rather than a mere untidiness.

How creep happens

Access is easy to give and hard to take back. Giving access has a clear trigger: someone asks, a manager approves, and work can start. Removing access has no natural trigger. Nobody files a request saying “please take away what I no longer need”. People change projects, teams, and countries, and each change leaves behind something. Over the years, the pile grows. A typical long-serving employee in a mid-sized company may hold dozens of application accounts, many group memberships, and a handful of powerful roles, of which only a fraction match their current job.

Why it matters

• Bigger blast radius. If an attacker steals an account, the damage is bounded by that account’s access. More leftover access means more damage.
• Insider risk. Honest people with too much access can make costly mistakes, and the rare dishonest person has more to abuse.
• Compliance failures. Many rules and standards expect organizations to prove that access is reviewed regularly.
• Wasted money. Unused licenses for paid applications are a hidden cost. Reviews often find savings.
• Audit pain. Without regular reviews, audits turn into panicked spreadsheet exercises.

The idea is simple. The hard part is doing it at scale, with evidence, without exhausting everyone involved.

The plain definition

An access certification, also called an access review or attestation, is a formal check in which a responsible person looks at a list of access and says, for each item, “yes, this is still appropriate” or “no, this should be removed”. The word “certify” means to confirm in a way that can be proven later. A campaign is a planned, time-limited round of such checks, covering a defined set of people or resources, assigned to defined reviewers, with a start date, a deadline, and defined consequences for the decisions.

The three questions every campaign answers

Why a campaign, not ad hoc checks?

Informal checks happen when somebody remembers, cover whatever they happen to look at, and leave no record. A campaign has a schedule so it happens, a scope so nothing important is missed, named reviewers so someone is accountable, a deadline so it ends, and a history so an auditor can see what was decided, by whom, and when. Those five properties turn a good intention into a control.

flowchart LR
    A["Define scope"] --> B["Assign reviewers"]
    B --> C["Launch campaign"]
    C --> D["Reviewers decide on each item"]
    D --> E["Revocations carried out"]
    E --> F["Evidence stored for audit"]
    F --> G["Next campaign scheduled"]
    

The figure shows the loop. Notice that deciding is only the middle of the process. The steps before it make sure the right people look at the right things. The steps after it make sure decisions actually change access and leave proof. A campaign that skips the last two steps is just a survey.

Many organizations run campaigns because someone outside requires evidence. Understanding what outsiders look for makes the campaign easier to design.

The common expectation

A wide range of security and financial control frameworks expect periodic review of user access. Examples include financial reporting controls for public companies, security assurance reports that customers ask vendors to provide, international information security standards, healthcare privacy rules, and payment card standards. They differ in wording and in how often they expect reviews, but share the same core idea: access must be justified, and the organization must be able to show that someone checked. This post does not give legal or audit advice, and your own compliance team decides exactly what your frameworks require.

What auditors usually want to see

Look at the last two rows. Many programs fail audits not because reviewers said the wrong things, but because revocations were never carried out or because nobody can prove what happened to items left undecided. Designing for those two questions from the start saves a lot of grief.

A few terms appear everywhere in governance. Learning them once makes the rest of this guide easy to follow.

Key terms

The anatomy, from creation to closure

stateDiagram-v2
    [*] --> Draft: Designer sets scope and reviewers
    Draft --> Scheduled: Start date set
    Scheduled --> Active: Start date reached
    Active --> Active: Reviewers make decisions
    Active --> Closed: Deadline reached or all items decided
    Closed --> [*]
    

The state picture is a useful mental model. Before a campaign starts, you can freely change its design. Once it is active, changes are risky because people are already making decisions. After it closes, it becomes a record. Design carefully while in draft, and treat an active campaign as something to nudge, not redesign.

Scope decides what the campaign covers. Too wide and nobody finishes. Too narrow and risky access slips through.

Two ways to slice the same data

Access can be viewed from two angles. A user-centered campaign starts with people: for each person in scope, the reviewer sees all of that person’s access and decides on each item. A resource-centered campaign starts with a resource: for each application or group in scope, the reviewer sees everyone who has access to it and decides on each person. Both examine the same set of connections between people and resources, but they suit different reviewers.

Filtering the scope

• By resource. Choose specific applications or groups, typically the most sensitive ones first.
• By people. Limit to a department, location, worker type, or other attribute, so different business units can be reviewed in different rounds.
• By status. Normally include only active accounts. Deactivated people should have been removed already, and they belong in a different check.
• By risk. Concentrate effort where the damage would be greatest: financial systems, customer data, administrative roles.
• By age. Some campaigns focus on access granted long ago, or access not used recently.

flowchart TD
    ALL["All access in the company"] --> F1{"Risk level?"}
    F1 -- "High: finance, admin, customer data" --> HI["Review often, resource owners plus managers"]
    F1 -- "Medium: internal business tools" --> ME["Review twice a year, managers"]
    F1 -- "Low: general productivity tools" --> LO["Review yearly or rely on automated cleanup"]
    

The picture reflects a basic fact: reviewers have limited attention, so spend it wisely. Reviewing every low-risk application every quarter drowns reviewers and hides the important decisions among the trivial ones. A tiered approach keeps the important reviews sharp.

A review is only as good as the person doing it. The right reviewer knows enough to judge and has the standing to say no.

Common reviewer types

What makes a good reviewer

• Knowledge. They understand what the access means and who needs it.
• Authority. They are senior enough to refuse requests and defend the decision.
• Independence. They have no personal stake in the answer. Nobody should approve their own access.
• Availability. They are around to finish the work during the review period.
• Accountability. The organization expects them to take this seriously, and their own manager knows it.

Where reviewer information comes from

Managers are usually found through the manager attribute in the user profile. Application owners come from an ownership record kept for each application or group. If those records are wrong or missing, review items go to the wrong people, or to nobody. That is why clean ownership data is a prerequisite, a point this guide returns to in a later chapter.

flowchart LR
    ITEM["Review item: Priya has payroll access"] --> R1{"Reviewer type chosen"}
    R1 -- "Manager" --> M["Look up Priya's manager from the profile"]
    R1 -- "Application owner" --> O["Look up the payroll application owner"]
    R1 -- "Named reviewer" --> N["Use the fixed person or team"]
    M --> D["Decision task assigned"]
    O --> D
    N --> D
    

The picture shows how each review item finds its reviewer. Because the lookup depends on data that changes, such as who reports to whom, two items in the same campaign can go to different people, and an item can fail to find anyone when the data is missing.

Real organizations have people on leave, managers who left, and empty ownership fields. A good design plans for all of these.

Fallback reviewers

When the normal reviewer cannot be determined or is not available, a fallback reviewer receives the items. A fallback may be a security administrator, a compliance officer, or the manager’s manager. It should be a named person or a small team, never an empty mailbox. Without a fallback, orphaned items either block the campaign from finishing or silently go unreviewed.

Delegation

A reviewer who is going on leave, or who is not the best judge of a particular item, may hand the decision to someone else. This is useful, but dangerous if uncontrolled. Rules should say who may delegate, to whom, whether the delegate may re-delegate, and how delegations are recorded. Delegation to a subordinate defeats independence, because the subordinate may feel unable to say no.

Second-level review

For high-risk access, one pair of eyes may not be enough. A second level of review means that a different person reviews the first reviewer’s decisions, either all of them or a sample. This catches careless approvals and prevents a single weak reviewer from becoming the failure point. Some organizations review reviewers’ revoke decisions only, to catch mistakes that could disrupt work, and review approvals on a sample basis, to catch rubber-stamping.

sequenceDiagram
    participant S as Campaign system
    participant M as Manager
    participant D as Delegate or fallback
    participant L as Second-level reviewer
    S->>M: Assign review items
    M->>D: Delegate items while on leave
    D->>S: Submit decisions
    S->>L: Send high-risk decisions for second review
    L->>S: Confirm or overturn decisions
    S->>S: Record all actors and times
    

The sequence shows how a single item can touch several people. What matters is that the system records each step, so an auditor can see who decided and under whose authority.

The decision is the heart of the campaign. Each choice has a meaning, a consequence, and a way it can go wrong.

The usual choices

What should happen to undecided items?

This is one of the most important design choices. There are two basic philosophies. In a “keep unless revoked” approach, items nobody decided on stay as they are, and the campaign merely records that no decision was made. This is safe for business continuity but weak for security, since silence means access continues. In a “remove unless approved” approach, undecided items are revoked at the deadline. This is strong for security and creates strong pressure on reviewers to respond, but it can cause disruption if reviewers are simply late or absent. Many organizations choose the second for high-risk access and the first for low-risk access.

flowchart TD
    DL["Deadline reached"] --> UN{"Item undecided?"}
    UN -- "No" --> DONE["Apply the reviewer decision"]
    UN -- "Yes" --> RISK{"High-risk access?"}
    RISK -- "Yes" --> REV["Revoke by default, notify the user and manager"]
    RISK -- "No" --> KEEP["Keep access, record as not reviewed, follow up"]
    

The picture shows a balanced approach. High-risk access is removed by default when nobody speaks up, since the cost of leaving it is high. Low-risk access is left in place but flagged so it can be followed up. In both cases, a record is kept.

Making decisions meaningful

Good campaigns ask for a reason on revoke decisions, and sometimes also on approvals for sensitive items. The reason helps the next reviewer, helps auditors, and gently pushes reviewers to think. It also gives the support team context when the person asks why their access was removed.

A decision to remove access means nothing until the access is actually gone. This step is where many programs quietly fail.

Two ways to remove access

When a reviewer chooses revoke, the system can take one of two paths. In automatic remediation, Okta itself removes the access, for example by removing the user from a group or unassigning an application, and the downstream effects (such as removing the account in a connected application) follow from the usual provisioning rules. In manual remediation, Okta records the decision and creates a task, ticket, or message for someone to carry out the removal in the target system. The first is fast and leaves less room for human error. The second is needed for systems that Okta cannot change directly.

The proof problem

Auditors do not accept “the reviewer clicked revoke” as proof that access ended. They want evidence that the account or permission is truly gone. That means checking the target system, or at least recording the successful response from the removal action. Where removal is manual, track each ticket until it is closed, and compare the list of revoked items with the list of closed tickets.

sequenceDiagram
    participant R as Reviewer
    participant OK as Okta
    participant APP as Application
    participant T as Ticketing system
    R->>OK: Revoke decision
    OK->>APP: Remove assignment through provisioning
    APP-->>OK: Success or failure response
    OK->>T: Create ticket if removal failed or is manual
    T-->>OK: Ticket closed with confirmation
    OK->>OK: Mark item remediated and keep evidence
    

The sequence shows a layered approach: try the direct removal, check the response, and open a tracked task if it did not work. Every path ends with the item marked as truly remediated. An item stuck between “decided” and “removed” is a gap an attacker or auditor may find.

Typical failures

• Removal fails silently. The application rejects the change and nobody notices.
• Access returns. A group rule or an access request gives the access back after the review removed it.
• Access removed in one place only. The person still has the permission through a second path, such as a different group.
• Local accounts remain. The application has its own local admin accounts that Okta does not manage.

How often to review is a balance between catching problems early and exhausting people. The answer differs for each kind of access.

One-time and recurring campaigns

A campaign can be a one-time event, such as a special review before an audit or after an acquisition, or it can be scheduled to repeat, for example every quarter. Recurring campaigns build the habit and generate the steady history auditors like to see. One-time campaigns are good for targeted projects. Most programs use a mix.

Matching frequency to risk

These cadences are common examples, not rules. Your compliance team and your own risk assessment decide the right frequency. What matters is that the frequency is stated, followed, and justified.

Staggering

Running every campaign at the same time overloads reviewers, especially managers who receive items from many campaigns at once. Staggering campaigns across the year, with each starting in a different month, spreads the load. It also gives the identity team room to learn from one campaign before running the next.

gantt
    title Example yearly campaign calendar
    dateFormat  YYYY-MM-DD
    axisFormat  %b
    section Privileged
    Admin roles review Q1      :a1, 2027-01-05, 14d
    Admin roles review Q2      :a2, 2027-04-05, 14d
    Admin roles review Q3      :a3, 2027-07-05, 14d
    Admin roles review Q4      :a4, 2027-10-05, 14d
    section Business applications
    Finance applications       :b1, 2027-02-01, 21d
    Customer data systems      :b2, 2027-05-03, 21d
    General applications       :b3, 2027-09-06, 21d
    section Third parties
    Contractor review          :c1, 2027-03-01, 14d
    Contractor review second   :c2, 2027-08-02, 14d
    

The calendar shows privileged reviews every quarter, finance and customer data reviews on offset schedules, and a general review later in the year. No month has more than one or two campaigns, so reviewers are not buried.

Choosing the review window

Campaign length is a trade-off. Too short and people on holiday miss it. Too long and urgency fades. Two to three weeks is typical for large campaigns, with reminders at fixed points and a final warning shortly before the deadline.

Most campaigns fail because people do not finish, not because they decide badly. Communication design is a large part of success.

The communication ladder

Writing messages people read

• Clear subject. “Action needed by 14 March: review access for your team” beats “Access certification notification”.
• One request. Tell the person exactly what to do and how long it should take.
• A direct link. No hunting for the page.
• Consequences stated plainly. What happens if nothing is done.
• A named human. Someone to ask for help.

flowchart LR
    L["Launch day 0"] --> R1["Reminder day 7"]
    R1 --> R2["Reminder day 12"]
    R2 --> F["Final warning day 14"]
    F --> E["Escalate to reviewer's manager day 15"]
    E --> C["Closing rule applied day 21"]
    

The ladder in the picture starts gently and ends firmly. Notice that escalation happens before the deadline, giving the campaign owner time to chase people. Waiting until after the deadline to discover that half the reviewers never opened their email turns a campaign into a failure.

A reviewer faced with hundreds of unexplained rows will click approve. Making the work easier is not a nicety, it is what makes the control work.

Why rubber-stamping happens

When a reviewer sees a list of two hundred lines with cryptic names, no context, and a deadline in an hour, the rational response is to approve everything and move on. Revoking something wrongly causes complaints. Approving something wrongly causes no visible problem until much later. The incentives reward saying yes. Good campaign design pushes back against those incentives by lowering effort and increasing meaning.

Ways to reduce effort

Measuring attention

Some warning signs suggest a rubber-stamping problem: reviewers who approve everything in seconds, campaigns where the revoke rate is almost zero every time, and decisions made in huge bulk batches. A very low revoke rate is not proof of good access hygiene. It may only show that reviewers are not looking. Investigate by sampling a few approved items and asking the reviewer to justify them.

flowchart TD
    A["Reviewer opens campaign"] --> B{"Items have context?"}
    B -- "No" --> C["Cryptic list, rubber-stamp likely"]
    B -- "Yes" --> D["Last use, peer comparison, plain names"]
    D --> E{"Volume manageable?"}
    E -- "No" --> C
    E -- "Yes" --> F["Considered decisions"]
    

The picture shows two gates. Without context, even a short list gets stamped. Without a manageable size, even a well-explained list gets stamped. Both conditions must hold.

The most familiar campaign asks every manager to review the access of their direct reports. It is simple to explain and hard to do well.

The setup

Imagine a fictional company, Brightwater Insurance, with 3,000 employees and 450 managers. Each quarter, the identity team runs a campaign in which every manager reviews the applications and groups assigned to each direct report. Managers see their team members, the access each person holds, and when it was last used.

How the team made it work

• Scope by risk. Only applications classified as medium or high risk are included, which cuts the number of items per manager to about twenty.
• Plain-language descriptions. Each application has a one-line description of what it is for and what it allows.
• Peer comparison. Items that most of the team holds are shown as normal, and unusual ones are highlighted.
• Clear timeline. Three weeks, with reminders at day seven, day fourteen, and day eighteen, and escalation to the director at day nineteen.
• Defined closing rule. High-risk items undecided at the deadline are revoked, and medium-risk ones are flagged.
• Training. A ten-minute video shows managers what to look for.

flowchart LR
    HR["Manager relationships from profile data"] --> CAMP["Quarterly campaign"]
    APPS["Medium and high risk applications"] --> CAMP
    CAMP --> MGR["Each manager sees team access with context"]
    MGR --> DEC["Approve or revoke"]
    DEC --> REM["Automatic removal and tracked tickets"]
    REM --> REP["Report to security and audit"]
    

Results in the first year

In the first quarter, 38 percent of managers finished on time, and the team learned that many managers did not recognize their own direct reports because the manager attribute was out of date after a reorganization. After a data cleanup and clearer instructions, the on-time rate rose to above 90 percent by the third quarter. The revoke rate settled at about five percent of items, mostly from people who had changed teams. The team also found three unused paid licenses for every hundred users, a saving that helped pay for the program.

Administrator roles deserve their own campaign. Few accounts, enormous power, and a long record of breaches that started with a forgotten admin.

Why privilege is special

Privileged access means the ability to change systems, not only use them. Administrators can create accounts, change policies, read sensitive data, and remove logs. A small number of such accounts can do more damage than thousands of ordinary ones. Attackers target them first, and insiders with more power than they need are among the most expensive risks. Reviews should therefore be more frequent, more thorough, and conducted by someone with the skill and independence to judge.

Design choices

• Frequency. At least quarterly, and some organizations review monthly.
• Reviewers. Security or the system owner rather than the line manager alone, with a second-level review.
• Scope. Every administrator role in Okta itself and in critical applications, including custom roles and delegated administration.
• Evidence of need. Each administrator should justify why they still need the role, and how recently they used it.
• Strict closing rule. Undecided privileged access is removed at the deadline.
• Emergency accounts. Break-glass accounts are reviewed too, and checked for secure storage and tested sign-in.

flowchart TD
    ADM["Administrator role assignment"] --> Q1{"Still employed and in role?"}
    Q1 -- "No" --> RV["Revoke"]
    Q1 -- "Yes" --> Q2{"Used in last 90 days?"}
    Q2 -- "No" --> RV
    Q2 -- "Yes" --> Q3{"Lesser role enough?"}
    Q3 -- "Yes" --> DG["Downgrade role"]
    Q3 -- "No" --> AP["Approve with justification, second review"]
    

The picture shows that approval is the last outcome, not the first. Each question tries to shrink the role before approving it. The downgrade outcome is especially valuable: instead of a yes-or-no choice, it recognizes that the right answer is often “less power”.

When a single application holds money or financial reporting data, the owner who understands it should confirm who may use it.

The scenario

Consider a fictional manufacturer, Ironvale Components, with a general ledger application used by 120 people. Auditors expect Ironvale to show that access to this system is reviewed twice a year by the business owner, who knows which roles are appropriate. The business owner is the head of financial reporting, not an IT person. The campaign must therefore present the access in business terms.

Design choices

sequenceDiagram
    participant ID as Identity team
    participant OW as Business owner
    participant OK as Okta
    participant LG as Ledger application
    participant AU as Auditor
    ID->>OK: Launch twice-yearly campaign
    OK->>OW: Review items with role descriptions
    OW->>OK: Decisions, with reasons for revokes
    OK->>LG: Remove roles through provisioning or ticket
    LG-->>OK: Confirm current user and role list
    ID->>AU: Provide decisions, confirmations, and sign-off
    

The picture shows an end-to-end chain. The last two steps matter most for audit: the application confirms its real user list after the changes, and the identity team provides the complete package to the auditor. A review that stops after the decision step is unfinished.

What the first review found

The first review at Ironvale found nine accounts belonging to people who had left the finance department, two people who held both payment entry and approval roles, and one shared account used by a temporary team. All were corrected within the review window. The owner also asked for a regular report of new access granted between reviews, to catch problems sooner.

People who are not employees come and go quickly, are managed loosely, and often keep access long after their work ended.

Why contractors need extra care

Contractors, consultants, vendors, and temporary workers often have shorter relationships, weaker ties to the company, and less visibility in HR systems. Their access is commonly granted quickly to get work started, and the end of the engagement may not be recorded anywhere. Without a deliberate check, accounts outlive contracts. In many breach investigations, a long-dormant contractor account turns up as the entry point.

A stronger approach

• Sponsor. Every external person has a named internal sponsor, who is accountable for them and acts as reviewer.
• End date. Every external account has an end date in the profile, and access expires or is reviewed at that date.
• Shorter cycle. Contractor access is reviewed more often, for example every quarter, with the sponsor confirming the engagement continues.
• Narrow access. Contractors receive only the applications they need for their work.
• Strict closing rule. Undecided contractor access is revoked at the deadline.
• Vendor-level review. Where a vendor supplies many people, ask the vendor to confirm who still works on the contract.

flowchart TD
    CON["Contractor account created with sponsor and end date"] --> TIME["Time passes"]
    TIME --> EV{"Quarterly review or end date reached?"}
    EV -- "Review" --> SP["Sponsor confirms engagement continues"]
    SP --> Y{"Still needed?"}
    Y -- "Yes" --> EXT["Extend end date with reason"]
    Y -- "No" --> OFF["Remove access"]
    EV -- "End date" --> OFF
    

The picture reverses the usual default. For employees, access continues unless removed. For contractors, access ends unless someone actively extends it. That one change closes the most common gap.

Calendar-based reviews catch slow creep. Event-based reviews catch the sudden jumps, such as a change of job, before they become years of leftover access.

Why events matter

A quarterly campaign may find that someone who moved from sales to finance still holds sales permissions, but only after three months of unnecessary access. If the system reacts at the moment of the move, the problem is caught immediately. These event-driven reviews trigger on specific changes: a new department, a new manager, a change of location, a long leave of absence, a change of worker type, or a nearing contract end date.

Events worth reacting to

How events and campaigns work together

Event-based reviews do not replace regular campaigns. They are smaller, faster, and aimed at one person or a few people. Regular campaigns remain the safety net that checks everything, including cases where events were missed because the data was wrong. Some organizations also automate the first step: when a person moves, roles that belong to the old department are removed automatically through rules, and a review covers only the leftover access that rules cannot decide.

flowchart LR
    HRC["HR change recorded: new department"] --> OKP["Okta profile updated"]
    OKP --> RULE["Rule-based access adjusts automatically"]
    OKP --> EVT["Event triggers a focused review"]
    EVT --> NM["New manager reviews remaining access"]
    NM --> OUT["Keep, revoke, or downgrade"]
    

The figure shows two layers. Rules handle the predictable parts, such as access that always goes with a department. A short review handles the unpredictable leftovers, such as special project access. Together they shrink the time during which a mover carries two roles’ worth of access.

Knowing that someone has an application is only half the picture. What they can do inside it often matters more.

Entitlements in plain words

An entitlement is a specific permission inside an application, such as “view invoices”, “approve payments”, or “administer users”. Two people can both have the same application and have very different powers. A review that looks only at whether the application is assigned misses the real risk. Entitlement-level review asks about each permission, which is more work but far more meaningful.

Separation of duties

Separation of duties is the principle that no single person should control every step of a sensitive process. The person who creates a payment should not be the person who approves it. The person who writes code should not be the only person who can release it to production. Rules can define pairs of entitlements that are not allowed together. These pairs are called conflicts. A good campaign highlights any person who holds both sides of a conflict.

flowchart TD
    P["Person holds entitlement A"] --> CK{"Also holds conflicting entitlement B?"}
    CK -- "No" --> OK["No conflict flagged"]
    CK -- "Yes" --> FL["Flag in review with reason"]
    FL --> RV{"Reviewer choice"}
    RV --> R1["Remove one entitlement"]
    RV --> R2["Approve exception with compensating control and expiry"]
    

The picture offers two legitimate outcomes. Sometimes the person genuinely needs both, for example in a very small team. Then the exception must be written down, given an end date, and backed by a compensating control such as an extra independent review of that person’s actions.

A campaign is only as good as the data behind it. Missing managers, wrong owners, and stale statuses quietly spoil the whole exercise.

What the campaign relies on

• Manager attribute. Used to find the reviewer for each person. If it is wrong or missing, items go to the wrong person or to the fallback.
• Ownership records. Every application and group in scope needs a current, named owner.
• Employment status. Used to include or exclude people. A leaver still listed as active will be reviewed pointlessly or, worse, never removed.
• Worker type. Used to apply different rules to employees and contractors.
• Resource descriptions. Used to show plain-language names.
• Accurate assignments. The list of who has what, which should match what the target application really holds.

Symptoms of poor data

flowchart LR
    DQ["Data quality checks before launch"] --> M1["Every active user has a manager"]
    DQ --> M2["Every resource has an owner"]
    DQ --> M3["Every account maps to a real person"]
    DQ --> M4["Descriptions exist for all resources"]
    M1 --> GO{"All checks pass?"}
    M2 --> GO
    M3 --> GO
    M4 --> GO
    GO -- "Yes" --> L["Launch campaign"]
    GO -- "No" --> FX["Fix and recheck"]
    

The diagram suggests a simple gate before launching. A one-hour check of the four conditions often saves a week of confused reviewers. Treat the results as a to-do list for the HR and application teams, not as an excuse to delay forever.

Campaigns do not live alone. They connect to workflows, ticketing, messaging, and monitoring systems that make them smoother and more provable.

Where integrations help

A typical flow

sequenceDiagram
    participant OK as Okta campaign
    participant WF as Automation flow
    participant AP as Target application
    participant TK as Ticketing
    participant SM as Security monitoring
    OK->>WF: Revoke decision event
    WF->>AP: Remove permission through its interface
    AP-->>WF: Result
    WF->>TK: Open ticket only if removal failed
    WF->>SM: Send decision and result record
    TK-->>OK: Ticket closure updates item status
    

The sequence shows automation as the hands of the campaign. The decision is Okta’s, the action is the flow’s, the fallback is a ticket, and the audit trail goes to monitoring. Each piece does one job.

Cautions

• Secure the automation. A flow that can remove access can also remove it wrongly. Restrict who can edit it and log all changes.
• Handle failures. Plan for a target application being down. Retry, then ticket.
• Avoid loops. Make sure removal does not trigger a rule that re-grants the access.
• Protect personal data. Messages and tickets should not carry more personal information than needed.

A review you cannot prove is a review you cannot defend. Good evidence is planned, not assembled in a panic.

What to keep

The completeness question

The hardest evidence question is: “How do you know the list you reviewed was complete?” If the list was built from Okta, but the application also has accounts Okta does not know about, the review missed them. Strong programs reconcile the application’s own user list with the campaign population. The reconciliation, with its differences explained, is evidence in itself.

flowchart LR
    SNAP["Population snapshot at launch"] --> REC["Reconcile with application user lists"]
    REC --> DEC["Decisions recorded with times"]
    DEC --> REM["Remediation confirmed"]
    REM --> PACK["Audit pack assembled"]
    PACK --> SIGN["Control owner signs off"]
    SIGN --> ARCH["Archived for the required retention period"]
    

Notice the first step is a snapshot. Data changes during a campaign as people join and leave. Capturing the population at launch lets you answer what was reviewed, even if the situation has moved on since.

The review process itself is a target. If it can be manipulated, it provides false comfort, which is worse than no control at all.

Risks to the process

• Self-approval. A person approving their own access, directly or through a friendly delegate.
• Collusion. Two people agreeing to approve each other’s excessive access.
• Reviewer impersonation. An attacker who controls a reviewer’s account can approve access they should not.
• Tampering with scope. Quietly removing risky applications from a campaign so they are never reviewed.
• Tampering with reviewers. Changing the manager attribute so items go to a friendly reviewer.
• Pressure on reviewers. A senior person insisting that their team’s access be approved without scrutiny.
• Over-broad campaign administration. Too many people able to create, edit, or close campaigns.

flowchart TD
    ATT["Threats to the review"] --> T1["Self-approval or collusion"]
    ATT --> T2["Hijacked reviewer account"]
    ATT --> T3["Scope or reviewer tampering"]
    T1 --> C1["Independence rules, sampling"]
    T2 --> C2["Strong sign-in, confirmation for sensitive actions"]
    T3 --> C3["Restricted administration, change alerts"]
    

The picture reminds us that reviews are controls that need controlling. Independence, strong sign-in, and tamper detection protect the integrity of the whole exercise.

What you measure shapes what you improve. A few well-chosen numbers reveal both the health of the campaign and the health of access itself.

Metrics worth tracking

flowchart LR
    CAMP["Campaign events and decisions"] --> LOGS["Central log store"]
    LOGS --> DASH["Dashboards: progress, revoke rate, removal time"]
    LOGS --> ALERT["Alerts: stalled campaign, failed removals"]
    DASH --> REV["Post-campaign review"]
    ALERT --> OPS["Identity operations respond"]
    REV --> IMP["Improve the next campaign"]
    

Hold a short retrospective

After each campaign, spend an hour with the campaign owner, a few reviewers, and the application owners. Ask what confused people, which data was wrong, which items were hardest to decide, and what was learned about access. Write down three changes for the next round. Over a year, this habit turns a clumsy first campaign into a smooth routine.

A pilot with ten reviewers is easy. A company-wide campaign with thousands is a project of its own. Plan the rollout like one.

Start small, grow deliberately

Scale concerns

• Number of items per reviewer. Keep it small enough to finish in about an hour. More than a few hundred is too many for careful review.
• Large resources. An application used by everyone creates one enormous list. Use manager-based review for it, or break the population into smaller campaigns.
• Remediation volume. Hundreds of removals at once can strain applications and support teams. Phase removals and warn help desks.
• Support load. Expect questions on launch day and after removals. Prepare short answers and a contact path.
• Product limits. Governance features have limits on campaign sizes and numbers, which vary by license and over time. Check your own limits.

flowchart TD
    BIG["Large population: 20000 users on one application"] --> SPLIT{"How to split?"}
    SPLIT --> S1["By department, one campaign each"]
    SPLIT --> S2["By manager, each sees their team only"]
    SPLIT --> S3["By risk, only elevated roles go to owners"]
    S1 --> OUT["Each reviewer has a manageable list"]
    S2 --> OUT
    S3 --> OUT
    

The picture offers three ways to cut a big problem into small ones. The best choice depends on who knows the access best. Often, a mix works: managers review standard access, and the owner reviews only elevated roles.

Campaigns fail in a small number of predictable ways. Knowing them in advance turns surprises into routine fixes.

A recovery routine

flowchart TD
    P["Problem noticed"] --> Q1{"Wrongly removed access?"}
    Q1 -- "Yes" --> RES["Restore from decision record, notify users"]
    Q1 -- "No" --> Q2{"Reviewers missing or inactive?"}
    Q2 -- "Yes" --> ESC["Fix data, escalate, reassign"]
    Q2 -- "No" --> Q3{"Removals not happening?"}
    Q3 -- "Yes" --> TK["Check integrations, open tickets, verify"]
    Q3 -- "No" --> INV["Investigate scope and design"]
    

These patterns have proved themselves in many organizations. Adapt them to your own size and risk.

flowchart LR
    RULES["Rules and expiry shrink access automatically"] --> CAMP["Campaigns review what remains"]
    CAMP --> EVT["Event reviews catch sudden changes"]
    EVT --> CAMP
    CAMP --> PROOF["Verified removal and evidence"]
    PROOF --> LEARN["Retrospective improves rules and data"]
    LEARN --> RULES
    

These habits look sensible at first and lead to empty reviews. Recognize them early.

Every choice in a campaign gives something up. Naming the trade-offs makes decisions deliberate.

The main trade-offs

Best practices

• State the purpose and risk of each campaign in one sentence before building it.
• Scope by risk and start with a small, meaningful pilot.
• Choose independent reviewers who know enough to judge.
• Define fallbacks, delegation rules, and second-level review for high-risk access.
• Run a data readiness check before launch.
• Give reviewers context: plain names, last use, peers, and changes since the last review.
• Define closing rules by risk level, and make them known in advance.
• Verify every removal in the target system.
• Keep evidence from the start and ask auditors what they need.
• Hold a retrospective after every campaign and act on it.

Common mistakes

• Launching before checking manager and owner data.
• Treating completion rate as the only measure of success.
• Forgetting that rules may regrant what a review removed.
• Reviewing application access but ignoring roles inside the application.
• Launching during busy periods.
• Forgetting the service desk when removals are large.
• Leaving long-lived exceptions with no expiry.

quadrantChart
    title Choosing review depth
    x-axis Low impact if misused --> High impact if misused
    y-axis Few people --> Many people
    quadrant-1 Manager plus owner review
    quadrant-2 Manager review with automation
    quadrant-3 Light yearly review
    quadrant-4 Owner or security review
    Productivity tools: [0.15, 0.85]
    Internal business apps: [0.4, 0.6]
    Customer data systems: [0.7, 0.55]
    Financial ledger: [0.85, 0.3]
    Administrator roles: [0.95, 0.1]
    

The picture is a way of thinking, not a measurement. Items with high impact and few holders, such as administrator roles, justify intense, specialist review. Items with low impact and many holders, such as productivity tools, are better handled by light, mostly automated checks.

To pull everything together, here is an invented company and a complete campaign program. The company, numbers, and names are made up for teaching.

The company

Cedarpoint Health is a fictional healthcare services company with 5,000 employees, 900 contractors, and about sixty applications, including a patient records system, a billing platform, and a general ledger. It faces audits that expect regular access reviews, and it recently found a former contractor’s account active eleven months after the contract ended. Leadership asked the identity team to build a proper certification program within six months.

The design

flowchart LR
    DATA["Readiness gate: managers, owners, descriptions"] --> PRIV["Privileged campaign"]
    DATA --> REG["Patient records and billing campaigns"]
    DATA --> MGR["Manager campaign in stages"]
    DATA --> CON["Contractor campaign with sponsors"]
    EV["Event triggers"] --> MGR
    PRIV --> REM["Automatic removal plus tickets"]
    REG --> REM
    MGR --> REM
    CON --> REM
    REM --> EVD["Evidence archive and dashboard"]
    

How the first year went

In the first month the team ran a readiness check and discovered that 14 percent of employees had no manager recorded and that a third of applications had no named owner. They fixed these before launching anything. The pilot, a review of the general ledger, found two people holding conflicting payment roles, which the finance owner resolved the same week. The privileged campaign removed 41 unused administrator roles and downgraded 17 more.

The contractor campaign was the biggest surprise. It found 130 accounts past their end dates, nearly all because sponsors had changed roles or left. Introducing an end date and a sponsor requirement for every new contractor, plus the sponsor-departure trigger, reduced the number of overdue accounts to a handful per quarter. The manager campaign’s first run reached 71 percent on-time completion, rising to 93 percent after clearer descriptions and weekly progress reports to department heads. A sample check of approvals found that a few managers were approving everything in bulk. Their directors discussed this with them, and later campaigns showed a more varied pattern of decisions.

When the external audit arrived, the team provided the population snapshots, decision records, ticket confirmations, and executive sign-offs. The auditors raised no findings about access review. The program also freed up roughly 400 unused application licenses, which reduced costs.

Short answers to questions that come up often. Feature names, screens, and licensing change over time, so confirm exact details in current Okta documentation.

Access certification campaigns turn a good intention, keeping access honest, into a repeatable control with owners, deadlines, and proof.