The annual spreadsheet is not a bad idea carried out badly. It is a good idea that cannot survive its own size.

An access review is a regular check that each person still needs the access they hold. The idea is simple and sound. The practice fails in the same ways in almost every company.

• Too big. A manager receives hundreds of lines to check in one sitting.
• Too little information. A name and an application do not tell anyone whether the access is still needed.
• Too slow. By the time the list is made, half of it is already out of date.
• Too easy to ignore. There is no consequence for skipping, and no reminder that works.
• Too manual to act on. Even when a manager says remove, someone must find the request, make a ticket and do the removal, and often does not.
• Too hard to prove. Auditors want to see who decided what and when; spreadsheets edited by email leave a muddy trail.

The result is a ritual that consumes weeks and catches almost nothing. Worse, it creates a false sense of safety, because the box is ticked.

A clear definition keeps expectations realistic.

Access review automation means using software to prepare the lists, send the right questions to the right people, remind and escalate, record the decisions and carry out the removals, with people deciding and machines doing the carrying.

What it is

• A routine that runs on a schedule or when something changes.
• A way to give reviewers context in the question itself.
• A way to turn a decision into an action without retyping.
• A source of evidence that the review happened.

What it is not

• It is not a machine deciding who keeps access. People, or clearly written rules, decide; automation delivers and records.
• It is not a replacement for good access design. If roles are a mess, reviews will be a mess.
• It is not one big yearly event. The best programmes review risky access often and low-risk access rarely.
• It is not finished when the campaign is sent. Removals, exceptions and follow-ups are the real work.
• It is not only for auditors. It reduces real risk by removing access nobody needs.

A helpful test: if a reviewer can answer in ten seconds with confidence, and the answer automatically changes the system, you have automation worth having.

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

Keep apart two ideas that people often confuse: review asks, “Is this access still right?” Approval asks, “Should this new access be granted?” They use similar screens but serve different moments in the life of access.

Access tends to grow. Nothing in the daily flow of work makes it shrink.

Meera joins Silverline as a dispatcher. She is given access to the dispatch board and the route planner. A year later she moves to customer service and gains access to the ticket system and refund tool. Nobody removes the dispatch board access, because she might need it for a cover shift. Two years on she supports a project and gains access to a reporting tool. Each addition was reasonable. Together they form a pile that no single person decided on.

• Access is added by requests, and each request has an owner who wants it.
• Access is removed only when someone remembers.
• People change roles more often than systems notice.
• Applications add their own permissions over time.
• Contractors and temporary staff leave traces after projects end.

A review is the counterweight to creep. It is the regular moment when the question, “Does this still make sense?” is asked on purpose.

Every campaign, manual or automated, passes through the same stages.

• Each stage can be automated to a different degree.
• Stages 3 to 6 are where most of the time is lost in manual campaigns.
• Stage 8 is the one most often skipped.

There is no single review. Different risks call for different shapes.

• Choose the shape by who knows best. A manager knows what a person does; an application owner knows what a permission means.
• Combine shapes: privileged roles by security every quarter, ordinary access by managers every six months, others on events.
• Avoid asking a manager to review technical entitlements they cannot understand.

The aim is not to click quickly. The aim is to make a defensible decision.

A good decision has three ingredients: the reviewer knows the person or the system, the reviewer has the facts and the reviewer can act. If any is missing, the decision is a guess.

• Show the plain-language name of every access, not a code.
• Show last use and peers where available.
• Make revoke as easy as keep, with an undo or quick re-request.
• Ask for a comment on risky keeps.

Before designing, list what Okta can provide.

Remember that campaign tools are only as good as the data beneath them. Accurate groups, profiles and manager fields are the foundation, and Chapter 15 returns to this.

Every automated review follows the same shape.

flowchart LR
    T["Trigger: schedule or event"] --> S["Select scope and reviewers"]
    S --> N["Send review items with context"]
    N --> D{"Reviewer decides"}
    D -->|"Keep"| K["Record decision"]
    D -->|"Revoke"| R["Remediate: remove access"]
    D -->|"No answer"| E["Remind, escalate, apply default"]
    E --> D
    R --> V["Verify removal"]
    K --> EV["Evidence store"]
    V --> EV
    EV --> L["Metrics and lessons for next campaign"]
    

Three ideas sit inside this picture. First, triggers can be a calendar or an event. Second, unanswered items have a defined path, not a shrug. Third, every path ends in evidence.

An automated review system has a handful of parts. Seeing them together makes the later chapters easier.

flowchart TD
    SRC["Sources: HR system, directory, applications"] --> OK["Okta: users, groups, profiles, manager fields"]
    OK --> CAM["Campaign engine: scope, reviewers, schedule"]
    CAM --> REV["Reviewer experience: list, context, decision"]
    REV --> DEC["Decisions"]
    DEC --> REM["Remediation: group removal, provisioning, tickets"]
    REM --> APPS["Connected applications"]
    CAM --> WF["Workflows: reminders, chat, tickets, checks"]
    DEC --> EV["Evidence store and reports"]
    OK --> LOG["System Log"]
    LOG --> EV
    

Notice that the review itself is only one box. Most of the value sits in the data before it and the action after it.

Follow a quarterly review of finance system access at Silverline.

sequenceDiagram
    participant S as Scheduler
    participant C as Campaign engine
    participant R as Reviewer (manager)
    participant W as Workflows
    participant A as Finance application
    participant E as Evidence store
    S->>C: Quarterly trigger
    C->>C: Build items from current group membership
    C->>R: Send 14 items with context
    R->>C: Keep 11, revoke 3
    C->>W: Revoke decisions
    W->>A: Remove access, check result
    A-->>W: Removed
    W->>E: Record action with time
    C->>E: Record decisions
    C->>R: Reminder for unanswered items (if any)
    

In a manual campaign the same journey takes weeks and loses information at each hand-off. In an automated one, the journey is hours, and nothing is retyped.

You cannot review everything equally. Choose by risk.

Start by listing the applications and groups. Rank each by how much harm excess access could do. Sensitive data, money movement, administrative powers and personal data all raise the rank.

• Score each application on data sensitivity, ability to change things and breadth of users.
• Begin with five to ten applications, then widen.
• Do not forget shadow applications connected without a formal process.
• Record the reason an application is in or out of scope.

Reviewing too rarely misses creep. Reviewing too often exhausts reviewers.

• Use events to supplement the calendar: a move to a new department triggers a review of old access.
• Avoid everyone in December: stagger campaigns across the year so reviewers face fewer items.
• Shorten the interval for areas with high turnover or past incidents.
• Lengthen it only with evidence that few changes happen.

As a rough guide, a reviewer who must answer more than about fifty items in a sitting will begin to approve everything. Plan campaigns so that no one faces much more than that at once.

The right reviewer is the person who can actually judge.

• Use managers for who-does-what questions.
• Use owners for what-does-this-permission-allow questions.
• For critical access, use both.
• Never let a person be the only reviewer of their own access.
• Plan a backup for each reviewer.
• Keep manager data accurate; a wrong manager means a wrong reviewer.

Reviewers lose faith in the first campaign if it contains wrong names, wrong managers and accounts that make no sense.

Automation multiplies whatever it is given. Good data produces a smooth review. Bad data produces a flood of complaints and a campaign that nobody trusts.

• Run a data quality report a week before launch.
• Fix what you can; list what you cannot and tell reviewers.
• Treat the first campaign as a pilot for data quality too.

Do not build each campaign from scratch. Make a few templates and reuse them.

• Create a template per tier: critical, high, medium.
• Fix the scope rules, reviewer rules, durations, reminders and default actions inside the template.
• Name campaigns consistently: tier, scope and period, so evidence is easy to find.
• Schedule campaigns in advance for the whole year.
• Review templates once a year.
• Keep a change log of template edits.

Most reviewers are not lazy. They are busy. A good nudge changes the outcome.

• Keep messages short and specific: how many items, how long it takes.
• Send reminders where people work: email and chat.
• Show a progress bar so people feel the end.
• Let reviewers delegate when they are away.
• Do not nag without end; escalation exists for this.

What happens when nobody answers is the most important design choice in the whole campaign.

• Decide the default before the campaign, and tell reviewers what it is.
• For critical access, revoke on silence is often justified, with a fast re-request route.
• Pair revoke defaults with clear communication and a rapid restore path.
• Test the restore path before using revoke defaults.
• Record every default action as a distinct kind of decision in the evidence.

A revoke decision that nobody carries out is worse than no review at all, because it creates a written record that the risk was known.

In a manual process, a manager says revoke, someone creates a ticket, the ticket waits and the access remains. Automation connects the decision to the action. When a reviewer revokes, the system removes the person from the group or the application assignment, and checks that it worked.

• Set a time limit from decision to removal, such as 24 hours.
• Report decisions not acted on every day.
• Let the person re-request quickly if the removal was a mistake.
• Keep a log of every automated removal.

Not every application connects neatly. Many have no way for Okta to remove access.

• Keep a register showing, for each app, how removal happens.
• Use Workflows or a ticketing tool to create and track manual tasks.
• Verify removals by comparing lists afterwards.
• Prioritise integration work for critical applications with manual removal.

Be honest in the evidence. If a removal is manual, say so and show the ticket, the date and the check. Auditors trust honesty more than hidden manual steps.

The calendar is not the only trigger. Some moments are riskier than others.

• Link events to reviews through Workflows or lifecycle triggers.
• Keep event reviews small and fast: a handful of items with a short deadline.
• Use events to reduce the size of calendar campaigns, because creep is dealt with early.
• Record the event as the reason in the evidence.

The most powerful accounts deserve the most frequent and careful reviews.

• Review administrator roles in Okta itself: who holds them, who approved, how recently used.
• Review privileged groups in key applications.
• Use two reviewers: a business owner and security.
• Make the cycle quarterly or more often.
• Pair reviews with time-limited access so less needs reviewing.
• Include emergency accounts and check they still work and are protected.

Many permissions come through groups, and groups hide complexity.

• A person may be in a group directly or through another group.
• Reviewers should see effective access, not only direct membership.
• Groups should have owners and descriptions.
• Review the group itself: does it still serve a purpose?
• Remove empty and stale groups regularly.
• Check group rules for conditions that put the wrong people in.

A review that asks about a person’s membership of a vaguely named group produces vague answers. Fix the group first, then review it.

Sometimes the question is not whether someone can use the finance system, but which parts of it.

Many applications have fine-grained permissions: view, create, approve, export, administer. A person might have access to the finance system and, inside it, the right to approve payments. The danger is in the details.

• Review high-risk entitlements separately from general access.
• Give reviewers plain descriptions of each entitlement.
• Start with the five or ten riskiest entitlements.
• Combine with segregation of duties checks.
• Ask application owners to maintain the descriptions.

People outside the company often hold access in places the HR system never sees.

• Give every contractor a sponsor who reviews them.
• Set end dates on external accounts and review before they expire.
• Run shorter cycles for contractors: monthly or quarterly.
• Include them in every population report.
• Check for shared accounts and remove them.
• Treat partner staff like employees when they hold sensitive access.

Programs sign in too. They rarely leave, and nobody asks them how they feel.

• Keep an inventory of service accounts, API tokens and integrations.
• Give each a technical owner who reviews it.
• Ask: is it still used, does it have more access than needed, is the secret rotated?
• Remove unused ones after notice.
• Review them in a separate campaign, not mixed with people.
• Alert on new service accounts created outside process.

Reviews should survive holidays, illness and job changes.

• Allow reviewers to delegate to a named colleague, with a record.
• Set automatic backups for known absences.
• If a reviewer leaves, reassign their open items at once.
• Prevent circular delegation and self-review.
• Limit delegation for critical items to people of suitable seniority.
• Track the time items wait because of absence.

The great enemy of every review is the reviewer who approves everything in thirty seconds.

Rubber stamping is rarely laziness. It is what happens when the question is too big, too unclear or too boring. Good design makes careful answers the easy answers.

flowchart TD
    A["Reviewer opens campaign"] --> B{"Too many items at once?"}
    B -->|"Yes"| C["Split into smaller batches"]
    B -->|"No"| D{"Is context shown for each item?"}
    D -->|"No"| E["Add role, last use, peers, plain names"]
    D -->|"Yes"| F{"Is revoke as easy as keep?"}
    F -->|"No"| G["Add one-click revoke and quick restore"]
    F -->|"Yes"| H{"Are speed and approve-all rates checked?"}
    H -->|"No"| I["Add monitoring and sampling"]
    H -->|"Yes"| J["Meaningful decisions"]
    

• Small batches: a dozen to fifty items at a time.
• Context: role, last use, peers, plain names.
• Symmetry: revoke is as easy as keep.
• Highlight the unusual: put risky or unused access first.
• Monitor behaviour: flag reviewers who approve hundreds in minutes.
• Sample: a second person re-checks a few of each reviewer’s keeps.
• Training: a five-minute guide on what to look for.

The best help is a hint at the right moment.

• Use recommendations such as suggested revoke for accesses unused for 90 days, but let the reviewer decide.
• Show the reason for each recommendation.
• Track how often reviewers follow recommendations and whether outcomes were good.
• Never hide how the recommendation was made; reviewers must trust it.

Not all items in one campaign are equal. Show the important ones first.

• Sort riskier items to the top.
• Allow reviewers to bulk-approve the low-risk items after a quick look, with a sample check.
• Require a comment for keeping a high-risk item.
• Use risk to decide who reviews, not only the order.

A review is a good moment to spot dangerous combinations.

Some pairs of permissions should never sit with one person: creating a supplier and paying a supplier; requesting access and approving it; changing a policy and reviewing its logs. Reviews can surface these combinations.

• Keep a list of conflicting pairs.
• Highlight people who hold both sides of a pair in the review.
• Offer the reviewer a choice: revoke one side or request an approved exception.
• Record exceptions with compensating controls and an end date.
• Run a separate conflicts check before each campaign.

A review is only as honest as the reviewer is independent.

• A person should never review their own access.
• A manager reviewing their team may have a reason to keep access for convenience; sample their decisions.
• Administrators should not approve their own roles.
• Where the reviewer is also the owner of the risk, add a second reviewer.
• Rotate reviewers for critical areas where practical.
• Record any conflict declared by a reviewer and reassign.

If you cannot prove a review happened, as far as an auditor is concerned it did not.

• Store evidence automatically as the campaign runs.
• Keep it for the period your rules require.
• Protect it from edits.
• Link decision to action to verification.
• Be able to show a complete population, not only a sample.

Different people need different views.

• Show completion in plain numbers.
• Show trend across campaigns.
• Show revocation rate by application.
• Show time from launch to decision and from decision to removal.
• Send a weekly digest during campaigns.

Completion alone proves nothing. Look for signs of real decisions.

• A revocation rate of a few percent is common for healthy programmes; zero is a warning.
• Compare across campaigns and teams, not against a fixed target alone.
• Beware gaming: reviewers revoking things to look active.

Reviews work best where people already live.

• Send chat messages with a link to the review and a count of items.
• Create tickets for manual removals and track them to closure.
• Link each ticket to the review item for evidence.
• Put deadlines in calendars.
• Let reviewers ask questions through chat about an item.
• Close the loop: when a ticket is done, update the review item.

Automation tools fill gaps that the standard campaign does not cover.

• Give each flow an owner and a description.
• Make flows safe to repeat.
• Log failures and review them.
• Test flows with sample users before live use.
• Keep flows few and clear.

A review that goes wrong in front of nine thousand people is hard to forget.

• Use test users and test groups that mirror real structures.
• Run the campaign on a small scope first.
• Ask a few friendly reviewers for feedback on wording and layout.
• Check the time a typical reviewer needs.

The first campaign is a learning exercise. Treat it that way.

• Avoid launching to everyone in the first campaign.
• Pick pilot reviewers who will tell you the truth.
• Announce the pilot so no one is surprised.
• Use the pilot to build templates and runbooks.

Reviews fail in predictable ways. Plan for them.

flowchart TD
    A["Review programme problem"] --> B{"What kind?"}
    B -->|"Reviewers do not respond"| C["Check workload and reminders, escalate, adjust defaults"]
    B -->|"Wrong people asked"| D["Fix manager data, relaunch affected items"]
    B -->|"Revokes not carried out"| E["Run remediation report, fix automation, track manual tasks"]
    B -->|"Mistaken mass revoke"| F["Restore from record, pause defaults, communicate"]
    B -->|"Evidence missing"| G["Rebuild from logs, fix storage"]
    C --> H["Lessons recorded and templates updated"]
    D --> H
    E --> H
    F --> H
    G --> H
    

After every incident ask: why did the problem occur, and why did we not notice sooner? The second answer is usually a missing alert.

A campaign for nine thousand people and three hundred applications is a big piece of work for the system and for people.

• Know the limits on campaign size, items per campaign and campaigns running at once for your edition.
• Split large reviews into several campaigns by application tier or department.
• Stagger launches so notifications and removals do not all land together.
• Watch rate limits on the interfaces used by remediation flows.
• Plan reviewer workload: items per person, not only per campaign.
• Allow time for remediation after decisions: large removals take time to run.

Reviews show who has access to what. That information is personal.

• Show reviewers only what they need for the decision.
• Avoid showing sensitive personal data in review screens.
• Be careful with usage data: last sign-in is helpful, detailed activity trails are not needed.
• Explain to staff what is reviewed and why.
• Make sure reviews are applied fairly: same rules for similar roles.
• Keep evidence for no longer than needed.
• Allow a person to question a revocation and have it checked.

Someone will ask whether automation is worth the effort. Prepare a plain answer.

Illustrative arithmetic: a manual annual review took the identity team 600 hours and managers 1,800 hours, at an average of 60 dollars an hour, or 144,000 dollars. An automated programme that halves the manager time and cuts the team time by 70 percent saves about 66,000 dollars a year. If tooling and upkeep cost 30,000 dollars, the net gain is about 36,000 dollars, before counting the reduced risk and cleaner audits. 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.

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

• Applications are tiered by risk, with a clear schedule for each tier.
• Data is cleaned before every campaign: managers, groups, leavers, duplicates.
• Reviewers are chosen for knowledge, with backups and no self-review.
• Items arrive in small batches with plain-language context, riskiest first.
• Revoke is as easy as keep, with a quick restore route.
• Reminders and escalations are planned; defaults are decided and communicated.
• Revocations are automated or tracked, and verified.
• Event-triggered reviews supplement the calendar.
• Privileged access and non-human accounts have their own reviews.
• Segregation of duties conflicts are checked.
• Evidence is stored automatically and protected.
• Metrics include revocation rate, time per decision and decision-to-removal time.
• Campaigns are tested and piloted before wide launch.
• Owners are named for the programme, templates and flows.
• Lessons from every campaign update templates and data.

Zero trust means no access is trusted forever. Reviews are how that idea becomes a habit.

Zero trust says verify explicitly, give the least access, and assume breach. A review answers the second directly: it asks whether access is still the least needed. It also supports the third, because less excess access means less damage when an account is stolen.

If a leader asks why the company reviews access this often, the answer is simple: because trust expires.

If no one owns the programme, everyone assumes someone else does.

• Hold a quarterly review of metrics, incidents and plans.
• Agree service levels: HR updates managers within a day; owners keep descriptions current.
• Require sign-off for changes to templates and defaults.
• Give every flow and every template a named owner.

The words of the invitation decide whether the review is done today or never.

• Say what: the number and kind of items.
• Say why: a one-line reason, such as protect customer data.
• Say how long: a realistic time estimate.
• Say by when: a date and what happens after it.
• Give one clear link and a name for help.
• Keep the tone respectful, not threatening.
• Write the subject line so it is recognised as real, to resist phishing look-alikes.

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

flowchart LR
    T["Tiers and calendar"] --> C["Cleaned data"]
    C --> CP["Campaign templates"]
    CP --> R["Reviewers with context"]
    R --> D["Decisions"]
    D --> AU["Automatic removal and tracked tasks"]
    AU --> VE["Verification"]
    VE --> EV["Evidence and dashboard"]
    EV --> TU["Quarterly tuning"]
    TU --> T
    EVT["Events: moves, risk, contract changes"] --> R
    

Nine months later, an auditor samples twenty people who changed jobs. All twenty had old access reviewed within a week of the move, and removed where not needed. The warehouse supervisor’s payments role was revoked in the first week.

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

Scenario 1: Workload per Reviewer

Nine thousand employees hold an average of 22 access items each, so 198,000 items. A single yearly campaign asking 1,000 managers to review them would be 198 items per manager, far above comfortable. With tiering, only the roughly 30 percent of items in high and critical tiers are reviewed more than once a year, and events handle movers. A typical manager now sees about 25 items per campaign.

Scenario 2: Revocation Rate

In the first automated campaign, 4.1 percent of 11,400 critical and high items are revoked, or about 467 removals. The manual yearly review a year earlier had a revocation rate of 0.3 percent, about 34 removals, mostly typos. The jump comes from context and fewer items per person, not from stricter managers.

Scenario 3: Time to Remove

Before automation the average time from a revoke decision to actual removal was 19 days. After, for connected applications it is under 4 hours, and for manual ones 3 days with tracking. A 19-day window across 467 removals is about 8,900 person-days of unneeded access; at 3 days for the 18 manual applications, the exposure is a small fraction of that.

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

The first 90 days

When someone says “I got a review for someone I do not know” or “I revoked it and they still have access,” follow the same steps each time.

• State the exact problem: which campaign, which reviewer, which item.
• Look at the item’s history: assignment, decision, action.
• Compare Okta’s view with the application’s.
• Fix the case, then the cause, then check for others with the same pattern.

Before setting up any review, run through the same short list.

flowchart TD
    A["Access to review"] --> B{"Is it high or critical risk?"}
    B -->|"Yes"| C["Quarterly campaign, owner plus manager, revoke on silence with restore"]
    B -->|"No"| D{"Does it change often with job moves?"}
    D -->|"Yes"| E["Event-triggered review plus yearly manager campaign"]
    D -->|"No"| F{"Is it low risk and widely held?"}
    F -->|"Yes"| G["Self-attestation or rely on lifecycle"]
    F -->|"No"| H["Yearly manager campaign"]
    C --> I{"Can removal be automated?"}
    E --> I
    H --> I
    I -->|"Yes"| J["Automate and verify"]
    I -->|"No"| K["Tracked task with deadline"]
    

• If you cannot say who will judge it, you are not ready to review it.
• If you cannot remove it, plan the task before the campaign.
• If nobody can describe the access in plain words, fix the description first.

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. The supervisor who could still approve payments makes the point in a sentence.
• Respect managers’ time. Short lists, clear context, ten minutes.
• Explain why. Reviews protect customers and colleagues.
• Train reviewers. A five-minute guide on what to look for.
• Show results. Share the number of excess accesses removed.
• Back it from the top. Executives complete their own reviews first.
• Listen. Use feedback to improve each round.

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

• Application tier register: tier, owner, reason.
• Campaign templates: scope, reviewers, timing, defaults.
• Runbooks: launching, handling absence, restoring mistaken revokes, closing a campaign.
• Flow map: every automation, its owner and last test date.
• Description library: plain-language access descriptions.
• Lessons log: what each campaign 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, removals done and checked, and reviewers who know what to expect.

Okta and the applications it connects to change often. A design that was right last year can quietly become incomplete.

• Read release notes on a schedule. Thirty minutes a month is usually enough.
• Test changes in a preview environment before they reach production.
• Keep a list of assumptions, such as which events start flows, and retest when a change touches one.
• Watch for renamed features and edition changes.
• Re-check application integrations after upgrades.
• Plan time each quarter for small upgrades rather than one big project every few years.

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

Most reviewers have never been taught how to review. A little help goes a long way.

A reviewer is usually a busy manager with a day job. They did not choose to become a guardian of access. Give them a short, friendly introduction and a place to ask questions, and the quality of their decisions rises sharply.

• Teach the three questions: Does this person still do this job? Does the job need this access? Have they used it?
• Tell reviewers it is fine to revoke and easy to restore.
• Thank reviewers publicly when campaigns finish on time.
• Collect questions and turn them into better item descriptions.

When the company changes shape, access has to follow, and reviews are the safety net.

A reorganisation moves hundreds of people in a month. Managers change, departments merge and old groups lose meaning. Acquisitions bring whole new populations with their own systems, standards and habits.

• Refresh manager data before any review after a reorganisation.
• Run shorter cycles for the months after big changes.
• Treat administrator access from an acquired company with extra care.
• Record exceptions that exist only for the transition, with end dates.

Many frameworks ask for regular access reviews. Automation makes it easier to answer them.

Auditors usually ask the same five things: what did you review, who reviewed, what did they decide, what happened after and where is the proof. An automated campaign produces answers to all five by design.

• Give each campaign a name and period that matches the audit period.
• Keep evidence for the retention period your rules need.
• Show complete populations, not just samples.
• Explain exceptions openly.

Leaders do not want a table of numbers. They want to know whether risk is going down.

• Show three numbers: completion, revocations and time to remove.
• Show trend across quarters.
• Show a story: one example of excess access found and removed.
• Show risk areas still open and the plan to close them.
• Ask for one decision per report, such as backing for revoke on silence in a critical tier.
• Keep it to one page.

A person can have no special application role and still reach sensitive data through shared folders, reports or exports.

• List data stores such as shared drives, warehouses and report tools that hold sensitive information.
• Give each store an owner who reviews who can reach it.
• Review sharing links and external shares.
• Include cloud storage and consoles in privileged reviews.
• Watch for broad groups such as everyone in the company with access to sensitive folders.
• Reduce access through roles and groups so it can be reviewed at all.

Sometimes a reviewer revokes access that a person insists they need. Plan for the conversation.

A fair process lets people question a decision quickly. Without one, staff will quietly ask for extra access to be restored through side doors, and the review loses its point.

• Make the request route short and visible.
• Set service levels for appeals so work is not blocked for days.
• Track restore rates by application and reviewer.
• Use patterns to improve descriptions and reviewer training.
• Never let an appeal route become a way to skip approvals.

The calendar of the business shapes when reviews can succeed.

• Avoid launching campaigns at year end, tax time or peak trading seasons for the reviewing teams.
• Check public holidays in every region before setting deadlines.
• Stagger campaigns by department and by tier across the year.
• Schedule privileged reviews for quiet weeks so they receive full attention.
• Leave a buffer before audit dates so that follow-up work can finish.
• Publish the year’s calendar early so managers can plan.

The end of a campaign is the start of the next one. Use the lessons while they are fresh.

Within two weeks of closing a campaign, gather the campaign owner, a few reviewers, an application owner and an identity engineer for a one-hour review. Look at the numbers, the complaints and the surprises, and agree on three changes for the next round.

• Write the three changes down, with owners and dates.
• Update templates, descriptions and training straight away.
• Share a short summary with reviewers, so they see that feedback matters.
• Keep the notes in the lessons log for the next owner.

A programme that learns after every round becomes calmer, faster and more accurate each time. One that does not repeats its first year again and again.

Everything in this guide can be scaled down. A company of two hundred does not need the machinery of nine thousand.

• Start with one spreadsheet-free campaign for the three most sensitive applications.
• Use owners as reviewers when there are few managers.
• Review quarterly for critical access and yearly for the rest.
• Do removals by hand at first, but with a checklist and a check.
• Keep a simple register of applications, owners and tiers.
• Add automation only where effort is painful.

The principles do not change with size: review by risk, give context, act on decisions, prove it.

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

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

Access review automation turns a yearly ritual into a steady routine that actually removes access nobody needs.