Access Certification: Review Campaigns That Aren't a Blind Click

Four hundred items in ninety seconds

On the last day of a quarterly review campaign, a sales director opens the link she’s been ignoring for two weeks. Her twelve direct reports hold about 400 entitlements between them. The screen shows names, codes like SFDC_PS_EXP_02, and an “Approve all” button. She clicks it, the campaign shows 100% complete, and she goes back to her forecast. Two of her reports changed teams in the spring and still hold access from their old jobs, which nobody removed because the move happened between campaigns. One of the codes she approved lets its holder export the entire customer list.

That’s the most common way access certification fails, and it fails while looking like a complete success on every report. The previous article covered the front door, how case-by-case access comes in through a governed request with approvals, checks, and an end date. Together with the joiner-mover-leaver process, requests decide what access people should get. Neither can promise what access people still have six months later.

That gap exists in every organization, however good its front door. A mover’s old access survived because the removal step failed quietly on a legacy system. An end date was never set because the entitlement predates the request process. An administrator granted something directly during an outage. A role quietly picked up an entitlement half its members don’t need. None of it shows up unless someone goes looking, and the longer nobody looks, the more of it there is.

Access certification, also called recertification, attestation, or user access review, is that looking. An accountable person reviews a set of existing access and confirms, item by item, whether each one is still appropriate. What’s confirmed stays; what isn’t is removed. Done well, it’s the main defense against privilege creep, the slow build-up of access that each grant justified and nobody took back. Done badly, it’s the sales director’s ninety seconds, repeated across the company every quarter. Auditors test it more than almost any other IGA control, because it’s the one that shows whether the others work, and the difference between the two outcomes is almost entirely design.

What a campaign is

Certification is usually organized as campaigns: a defined review, with a scope, a set of reviewers, a deadline, and a remediation step. Every campaign answers four design questions, and most failures trace back to one of them answered carelessly. What’s in scope: which people, applications, and entitlements? Who reviews each item, and are they in a position to know? What does the reviewer see next to each item? And what happens to a revoke decision, and how do we know it happened?

flowchart TD
  accTitle: The life of an access certification campaign
  accDescr: A campaign starts by building its scope from the current state of access, filtered by risk tier and application. Each item goes to a reviewer, a manager or an entitlement owner, who sees context such as last use, grant date, and comparison with peers. The reviewer approves or revokes each item. Revocations are carried out in the target systems through connectors or manual tasks. Reconciliation then confirms the access is gone, and only then is the campaign closed and stored as audit evidence.
  SC[Build scope<br/>from current access] --> RV[Send items<br/>to reviewers]
  RV --> DC[Reviewer decides<br/>with context]
  DC -->|Approve| EV[Record decision]
  DC -->|Revoke| RM[Carry out removal]
  RM --> RC[Reconciliation<br/>confirms removal]
  RC --> EV
  EV --> CL[Close campaign<br/>store evidence]

Choosing who reviews

The decision with the biggest consequences is who reviews what, because a reviewer who isn’t in a position to know will approve by default. Four common campaign types each put a different kind of knowledge in front of the decision.

Managers know the people. The sales director knows that two of her reports moved teams in the spring, that one now handles key accounts, that a contractor’s engagement ended last month. What she often can’t tell is what SFDC_PS_EXP_02 allows, or whether it’s risky. Manager reviews give broad coverage and are weakest exactly where the access is most technical.

Owners know the access. The CRM owner knows exactly what each permission set grants and which ones can export customer data, but probably doesn’t know whether a particular rep in a distant region still needs them. Owner reviews are strongest for high-risk entitlements, where understanding the access matters more than knowing the person, and they’re the natural home for the risk tiers and ownership from the entitlement catalog article.

Role content reviews certify the definition, not the members. Everyone in a role can legitimately need the role while the role itself has quietly picked up an entitlement nobody in it should have. Reviewing membership will never catch that; only asking the role owner whether it’s still the right bundle will. The next article, on role engineering, covers that review in detail.

Account reviews cover what doesn’t map to a person with a manager: service accounts, API keys registered as identities, shared mailboxes, technical admin accounts. In a program that only runs manager reviews, these fall through entirely, because there’s no manager to send them to. They’re also overrepresented in breach post-mortems. Every non-human account needs a named human owner, as the data model article argued, and that owner is the reviewer.

Mature programs mix the four by risk: manager reviews for standard access, owner reviews (sometimes in addition) for elevated and privileged access, role content reviews on their own schedule, and account reviews for every non-human identity. The question is never which type is best, but who knows enough to make this particular decision. And in every type, nobody reviews their own access, or access their own work depends on. A manager reviewing their own entitlements, or an administrator certifying the admin group they belong to, isn’t a review; those items should go automatically to the next level up or to an independent owner.

Scope and frequency set by risk

The most common reason certification turns into rubber-stamping isn’t laziness. It’s volume. The sales director was asked to make 400 decisions; a manager with twelve reports who each hold eighty entitlements faces nearly a thousand. Nobody makes a thousand careful decisions in an afternoon. They make a few and approve the rest.

Cutting that volume without cutting control is the main lever in campaign design, and risk tiers are how you pull it.

The last row matters. Access everyone in a population receives automatically, email, the intranet, the expense tool, doesn’t need a manager to confirm it for each person every year; if the person still belongs to the population, the access is correct by definition. Leaving it out of item-level review removes a large share of the volume at no real cost, and moves the governance of that access where it belongs: reviewing the birthright rules themselves and making sure leavers are removed.

Regulations sometimes set minimums. Financially significant systems in scope for SOX are commonly reviewed quarterly, and PCI DSS requires user accounts and their privileges to be reviewed at least every six months. Those are floors for specific systems, not a reason to review everything at the highest frequency.

What the reviewer sees

Hand a reviewer names and codes and you’ve designed a campaign that can only be rubber-stamped, because there’s nothing to decide with. The biggest improvement most programs can make isn’t a new campaign type or a new frequency. It’s putting the right context next to each decision.

A readable description comes first: the plain-language name from the catalog instead of SFDC_PS_EXP_02. If the catalog work from the first module wasn’t done, the reviewer is reviewing strings. Last use is next, wherever the system can report it; an entitlement unused for 200 days is a far easier decision than one used this morning. How and when the access was granted matters too: through a role, through birthright, through an approved request with its justification, or with no record at all. Access with no governed origin deserves the hardest look.

Risk tier and conflict flags show whether an item is privileged and whether it forms a known dangerous combination with something else the person holds. A comparison with peers shows whether people with the same job and department hold the same entitlement; something one person in forty holds isn’t necessarily wrong, but it’s the one to look at first. And highlighting what changed since the last review lets reviewers focus on the difference instead of rereading the same stable access every quarter.

Order matters as much as content. Put the decisions that matter at the top: privileged access, conflicts, unused access, access with no governed origin, peer outliers. Stable, recently used, role-based standard access goes at the bottom. Reviewers who run out of attention will then run out of it on the low-risk items instead of the important ones. Had the sales director’s screen opened with “Export all customer contacts, unused for 140 days, held by 1 of 31 peers,” she might well have stopped.

The decisions a reviewer can make

At its simplest each item gets one of two answers: approve, the access is still appropriate, or revoke, it isn’t. Real campaigns need a few more options, each designed deliberately.

Reassign sends the item to a different reviewer when the original one genuinely can’t judge it, for example a manager who inherited the team last week. It should require a reason and shouldn’t be usable to pass hard items around until the deadline passes. Approve with an end date keeps access for now but turns it from standing into temporary, often the most honest answer for access that’s “probably needed until the project ends”; it connects review to the end-date discipline from the access request article. And “I don’t know” should exist, and should never quietly default to approve. An item the reviewer can’t judge goes up a level or to the entitlement owner.

Some programs add revoke by default for specific categories: if a privileged entitlement hasn’t been used in 90 days and the reviewer doesn’t explicitly approve it, it’s removed when the campaign closes. That reverses the burden of proof for the riskiest access. It works best when reviewers are told clearly beforehand and when removal is easy to reverse through a normal request, so a wrong removal costs a short delay rather than an outage.

A decision isn’t a removal

A revoke decision is a decision. Until the access is actually gone from the target system, nothing has changed. Remediation is the step most campaigns treat as an afterthought and the one auditors test hardest.

Revocations go through the same paths as fulfillment of requests, automatically through a connector or manually through a task for an administrator, and they fail the same ways. Connectors error out, tasks are closed without being done, access is removed from one system but not from the identical permission in another. The control that closes the gap is the same too: reconciliation reads the target system after remediation and confirms the access is gone.

A campaign shouldn’t count as complete when the last reviewer clicks submit. It’s complete when every revoke decision has been confirmed by reconciliation, and the campaign’s record should show decided, executed, and confirmed as three separate states. Set an explicit deadline for carrying out revocations, such as five business days for standard access and one for privileged access, and report on it. A revoke decision left unexecuted for two months means the access stayed two months after someone decided it shouldn’t, which an auditor will reasonably treat as the control failing.

Running the campaign

A well-designed campaign can still fail in execution, usually by drifting past its deadline while reviewers ignore it, as the sales director did for two weeks. The mechanics deserve as much design as the scope.

Announce it before it starts. Reviewers who get an unexpected email with 300 items treat it as noise. A short note a week ahead, what it covers, why it matters, how long it should take, where to get help, measurably improves completion and decision quality. For first-time reviewers, five minutes walking through the review screen removes the most common reason for bulk approval: not knowing what the buttons mean.

Size the window to the work. Two weeks is a common default for manager reviews; owner reviews of large populations may need longer. Too short pushes reviewers to approve everything to finish on time; too long lets the campaign slide off everyone’s list.

Remind, then escalate, then decide. A typical rhythm is a reminder halfway through and two days before the deadline, escalation to the reviewer’s manager at the deadline, and a defined outcome for anything still undecided after that. Choose that outcome explicitly and write it down. For privileged access, undecided usually means revoke; for standard access, some programs extend once and then revoke. It should never mean keep, because that turns not participating into approving, the review equivalent of a request that approves itself when nobody answers.

Watch it while it runs. Whoever owns the campaign needs a live view of progress by reviewer and by risk tier, so they can chase the few reviewers who haven’t started instead of discovering at the deadline that the privileged portion is a third done.

Designing out rubber-stamping

Approving everything without real evaluation is the defining failure of certification, and it’s rarely a character flaw in reviewers. It’s the predictable result of asking people to make too many decisions with too little information, and the fixes are structural.

Shrink the volume by leaving out birthright access, reviewing stable standard access by exception, and focusing item-level review on elevated and privileged access; the catalog’s granularity work pays off here, as two hundred near-duplicates become twenty meaningful entitlements. Add the context described above, which turns an impossible decision into an obvious one for most items. Watch for the pattern: decision times and approval rates per reviewer show who approved 400 items in ninety seconds, or who has never revoked anything in four campaigns. Some programs go as far as inserting a known-inappropriate item, access a test identity shouldn’t have, to see whether reviewers are reading; it’s controversial, but it measures attention directly.

Make approving everything harder than reviewing. Turning off bulk approval for privileged items, or asking for a comment when approving access that hasn’t been used in months, adds a little friction exactly where a careless decision costs the most. And split the review. Small, focused reviews of ten or twenty items, sent close to a relevant event, get far more attention per item than one enormous campaign a quarter. That’s the idea behind event-driven certification.

From quarterly campaigns to reviews triggered by events

The traditional model, every manager reviews all their reports’ access every quarter, has a structural weakness: it’s disconnected from the moment access actually becomes inappropriate. A mover’s old access becomes suspect the day they move, not on the first day of the next quarter, and in between it sits there for up to three months. The two sales reps who changed teams in the spring are exactly that case.

Event-driven certification, often called continuous certification, closes the gap by triggering small, targeted reviews when something happens that puts specific access in question. A change of manager or department sends the new manager only the access the person carried over. Long non-use sends an elevated entitlement to its owner to confirm or remove. An outlier among peers triggers a review of that one item. A security alert, a policy violation, or a conflict found after the fact triggers immediate review of the related access. And an entitlement whose risk tier goes up gets all its holders reviewed under the stricter standard.

sequenceDiagram
  accTitle: An event-driven review triggered by a move between teams
  accDescr: The HR system records that an employee moved to another department. The IGA platform detects the move and identifies the access the employee carried over from the previous job. It sends a small, targeted review of only that access to the new manager. The new manager keeps what is still needed and revokes the rest. The platform carries out the revocations in the target systems, and reconciliation confirms the access was removed, within days of the move rather than at the next quarterly campaign.
  participant HR as HR system
  participant IGA as IGA platform
  participant NM as New manager
  participant T as Target systems
  HR->>IGA: Move between departments
  IGA->>IGA: Find access carried over from old job
  IGA->>NM: Review 12 carried-over items
  NM-->>IGA: Keep 3, revoke 9
  IGA->>T: Carry out 9 revocations
  T-->>IGA: Reconciliation confirms removal

Event-driven reviews don’t usually replace scheduled campaigns entirely; auditors and regulations still expect a periodic, complete review of in-scope systems. What changes is the scheduled campaign’s role. Instead of being the only mechanism that catches inappropriate access, it becomes the backstop that checks nothing slipped past. Because most problems were already handled near the event, the scheduled campaign is smaller and reviewers have more attention for what’s left. The analytics behind triggers such as peer outliers and risk scores get their own article later in this domain.

What an auditor tests

For many organizations certification exists first because an auditor requires it, under SOX IT general controls, SOC 2, PCI DSS, or HIPAA. That’s a perfectly good reason, as long as campaigns are designed to produce evidence that holds up rather than just a completion rate.

When auditors test certification, they usually sample campaigns and individual items. They want to see that the scope was complete, built from the actual state of the in-scope systems rather than a list someone maintains by hand. They want the reviewer to have had the authority and knowledge to decide, and not to have been reviewing their own access. They want the campaign to have run on schedule and finished by its deadline. They want the trail of decisions, who decided what, when, with which comment. And for sampled revocations, they want evidence the access was actually removed, and when.

That last point is where programs most often fail. A campaign showing fifty revoke decisions and no proof any were carried out is, from an auditor’s point of view, a campaign that found fifty problems and fixed none. The confirmed state described earlier is what turns a log of decisions into evidence. And the sales director’s 100% completion, with zero revocations and an approval time of ninety seconds, is exactly the pattern an experienced auditor will pull a sample from.

Worked example: a regulated fintech’s first real campaign

A fintech with about 600 employees processes card payments, which puts it in scope for PCI DSS, and is preparing for its first SOC 2 Type II audit. Access reviews have been a yearly spreadsheet exercise: IT exports user lists, emails them to managers, and collects replies. The IGA program is asked to replace that with a real campaign.

The first campaign covers the six systems in scope for PCI DSS and SOC 2: the payment platform, the production cloud environment, the customer support console, the data warehouse with transaction data, the identity provider, and the code repository. Birthright access is left out, leaving about 9,000 assignments. Privileged access in all six systems, around 400 assignments, goes to entitlement owners; everything else goes to managers. The 140 service accounts go to their registered technical owners, and the review discovers that 31 have no registered owner at all, which becomes its own workstream. Each item shows last use, grant origin, risk tier, and a peer flag, sorted with privileged items first, then unused ones, then items with no governed origin.

The campaign runs for two weeks. Owners revoke 18% of privileged assignments, most unused for more than 90 days. Managers revoke 6% of the rest. Reviewer analytics flag four managers who approved everything in under two minutes; their items go to the entitlement owners for a second look, and the owners revoke another 70 assignments.

Revocations in the four connected systems complete automatically within a day. The data warehouse and support console need manual tasks, and reconciliation a week later finds 22 of those weren’t done; they’re escalated and completed. The campaign record shows scope generated from system state, every decision with its reviewer and time, and reconciliation confirmation for every revocation, the package the SOC 2 auditor will sample. The 31 ownerless service accounts and 22 failed manual revocations become documented findings with remediation plans, which auditors generally view far more kindly than problems nobody found.

A second example: service accounts with no manager

A smaller case isolates the hardest population. A logistics company runs manager reviews only, and a pre-audit check reveals that its 260 service accounts have never been reviewed, because none has a manager in HR data.

The fix starts with ownership, not a campaign. Each service account is matched to the application team that uses it, and a named technical owner is recorded. Accounts nobody claims after two rounds of outreach are disabled for 30 days, not deleted, and re-enabled only if something breaks and an owner comes forward. Eleven are re-enabled; the rest are deleted when the window closes.

From then on an account review runs every six months, sent to each owner with last authentication and credential age as context. The first one removes excess permissions from 40 accounts, most created with broad administrator rights “to get it working” and never reduced. The same review also finds nine accounts whose credentials hadn’t been rotated in more than three years, which go to the security team as a separate finding, since an account review is often the first time anyone has looked at a service account’s credentials at all.

How certification goes wrong

Reviewing everything, always, at the same frequency guarantees fatigue and rubber-stamping; scope by risk instead. Asking people to review what they can’t understand turns every decision into a guess, and guesses default to approve, so fix the catalog before blaming reviewers. Treating completion as success hides failure: 100% on time with no revocations, as in the sales director’s campaign, strongly suggests nothing was reviewed. Stopping at the decision, with revocations never carried out or never confirmed, makes the campaign worthless as evidence and as a control. Forgetting accounts with no manager leaves service and shared accounts outside every review. And building the scope by hand, from a list someone maintains rather than from the systems themselves, guarantees the campaign misses exactly the access granted outside the process, which is the access most in need of review.

Measuring whether it works

A handful of measures show whether certification is a real control. The on-time completion rate shows whether reviews happen as planned, though on its own it proves little. The revocation rate, by campaign and risk tier, shows whether reviews find anything; close to zero for several cycles suggests rubber-stamping. The median time per decision shows whether reviewers are reading. Remediation time and the share of revocations confirmed show whether decisions turn into removals. Repeat findings, access revoked in one campaign and back by the next, show whether the front door is leaking. And the share of access reviewed through events shows progress toward continuous certification.

A healthy trend usually looks like a high revocation rate in the first campaigns, as the backlog of accumulated access is cleaned up, settling at a lower but non-zero level as requests, end dates, and event-driven reviews stop the build-up in the first place. A revocation rate of zero from day one doesn’t mean the organization had perfect access. It means nobody looked.

Where this maps to standards

Certification is among the most explicitly required IGA controls:

• NIST SP 800-53 Rev. 5, control AC-2 (Account Management), requires accounts to be reviewed for compliance at an organization-defined frequency, and AC-6(7) requires reviewing the privileges assigned to roles and users to confirm they’re still needed.
• PCI DSS v4.0, Requirement 7.2.4, requires all user accounts and related access privileges to be reviewed at least every six months, with results acted on and documented.
• SOC 2 Trust Services Criteria, CC6.2 and CC6.3, expect access to be reviewed periodically and removed when no longer appropriate; auditors test this by sampling campaigns.
• HIPAA Security Rule, §164.308(a)(4), requires information access management, including reviewing and modifying a user’s right of access.
• SOX IT general controls, evaluated under the PCAOB’s auditing standards, routinely include periodic user access reviews of financially significant systems.
• ISO/IEC 27001:2022, Annex A control 5.18 (Access rights), requires access rights to be reviewed at regular intervals.

Closing the loop

Requests and JML decide what access people should have. Certification checks whether reality still matches that decision and fixes it when it doesn’t. That makes it the place where every earlier piece of this domain shows up as a dependency: the identity record to know who the reviewer is looking at, the catalog to make each entitlement readable and owned, JML and access request to record where each assignment came from, and the program roles to know who answers when a campaign fails. With all of that in place, the sales director’s screen would have shown her a dozen items worth her attention instead of 400 she couldn’t read.

Recap

• Access certification is a detective control: accountable people periodically confirm existing access is still appropriate, and what isn’t is removed.
• Choose reviewers by what they know: managers know the people, owners know the access, role owners know a role’s content, and every non-human account needs a named owner to review it. Nobody reviews their own access.
• Scope and frequency follow risk: privileged access quarterly plus events, elevated twice a year, standard yearly or by exception, and birthright governed through its rules.
• Context is the control: readable entitlements, last use, grant origin, risk flags, and peer comparison, sorted so the important items come first.
• A revoke decision isn’t a removal until reconciliation confirms it, and that confirmation is what an auditor tests.
• Event-driven reviews catch access close to the moment it becomes suspect; the scheduled campaign becomes the backstop.
• Run campaigns deliberately: announce them, size the window, remind and escalate, and decide in advance that undecided items are never simply kept.

Three questions to test yourself

1. A manager review campaign finishes with 100% on-time completion and a 0.2% revocation rate. List three things you’d check before concluding the organization’s access is in good shape.
2. Why is an entitlement owner a better reviewer than a manager for production administrator access, and why might the manager still be useful in the same review?
3. Explain why a campaign whose scope comes from a list the IAM team maintains, rather than from the target systems’ actual state, will systematically miss the riskiest access.

Hands-on exercise

Design a certification program for one system you know, or for the fintech in the worked example.

1. Split its access into risk tiers and give each tier a campaign type, a reviewer, and a frequency. Decide which access you’ll leave out of item-level review and why.
2. List the context you’d show next to each item, and the order you’d sort items in.
3. Define two events that should trigger a targeted review outside the scheduled campaign.
4. Set deadlines for carrying out revocations, and describe how you’d prove to an auditor that a sampled revocation really happened.