Access Certification: What It Is and How to Run It

Three names for one job

Access certification is a review of who can get into what, where the people who know say yes or no to each access. “User access certification” is the same words with “user” added. “Access recertification” is the same job done again on a schedule. The “re” means repeat: if you run it every quarter, each quarter is a recertification.

“Certify” here means confirm. The reviewer confirms, line by line, that the access is right. It has nothing to do with a certificate on a wall, or with ISO 27001 certification, which is a certificate an outside body gives to a company. Do not mix them up. This guide is about the review.

You will also see the plain name, access review or user access review. Product makers pick different words for the same thing:

Where each name for the job appears
Name	Where you meet it
Access review	Microsoft Entra ID Governance calls its feature access reviews. Its documentation also uses the word "recertify" for role assignments.
Access certification	Okta Identity Governance calls it access certifications and runs each round as a campaign. SailPoint IdentityIQ calls a whole round a certification.
Access recertification	The same job, with the stress on doing it again and again on a schedule.

The product pages are What are access reviews? from Microsoft, Campaigns from Okta and About certifications from SailPoint.

Some writers keep a small difference. They call the whole round a certification and one reviewer’s list inside it an access review. SailPoint’s documentation does this: a certification is made of many access reviews.

Some vendors go further. They say a certification is formal and scheduled, and a review is ad hoc. The frameworks do not draw that line: PCI DSS, ISO 27001 and SOC 2 ask for the list, the decisions and the follow-through, whatever the round is called. What counts is whether the list was whole, each access got a decision, and the decisions were carried out. Nothing in them depends on which word you choose. The user access review guide shows what each of them asks for.

What a certification campaign is

A campaign is one round of certification. It has a scope (which systems and which people), reviewers, a deadline and a result. It starts and it ends. In order:

Scope. Pick the systems and the people.
Population. Take the full list of accounts and access from the systems, so no one is missing. This full list is called the population.
Assignment. Give every line to a reviewer who is not the person holding the access.
Decisions. Each reviewer certifies the line (keeps it), revokes it (removes it) or changes it, and writes why.
Close. Chase the late ones, then end the round. Lines with no decision are recorded as open.
Follow-through. Administrators carry out the revokes and changes, and someone checks they happened.
Record. Keep the list, the decisions and the follow-through together.

Ways to cut a campaign

Okta cuts a campaign two ways. An identity campaign picks people and reviews everything those people can reach. A resource campaign picks a system or a group and reviews everyone who has access to it. A third cut, by role, is covered below. Each suits a different reviewer.

Three ways to cut a certification campaign
Cut	Who it suits	What it catches well
By person	A manager: my team, across all systems.	A person who kept access from an old job. Accounts that belong to people who left.
By system or group	A system owner: my system, across all people.	Too many administrators. A group that grew past its purpose. Vendor accounts nobody remembers.
By role	A system owner, before the other two.	A role that holds more than its name says, which makes every holder wrong at once.

Run the first two and you have the two steps described in the user access review guide: managers by person, then owners by system.

Certify the role first

A role is a named set of permissions, such as “billing-admin”. If the role holds more than its name suggests, every person who holds it has too much, and a reviewer cannot see it from a list of names. So the owner confirms what the role contains before anyone certifies who holds it. Write one plain sentence for each role: what it lets a person do. Put that sentence next to every line that shows the role.

Other rounds you may want

Privileged access only. Administrators and anyone who can change other people’s access, reviewed more often than the rest.
Event-driven. A review of one person’s access when they change team or leave, without waiting for the round.
One system. A review of a single system after an incident, a merger or a change of vendor.

Who certifies

The manager knows what the person does now.
The system owner knows what the access allows. This is the person who answers for the system.
The data owner answers for access to a particular set of data, such as customer records.
The keeper of an account that software uses. Such an account has no manager. The person named as looking after it certifies it.
Security or compliance runs the round and checks it. They should not be the only certifier, because they rarely know the people.
Never the person themselves.

If a reviewer is away or has left, move their lines to a deputy, and record who. Most tools call this reassign or delegate. Name deputies before the round starts. Otherwise lines wait with someone who is on leave.

What to put in front of the certifier

A certifier needs two things: knowledge and the authority to decide. A bare list of names gives them neither, so each line carries:

The person, their manager, and the system.
The role or group, and the plain sentence about what it allows.
How the person got it: directly, through a group, or through a role that contains other roles.
When the account was last used, or “Unknown” if the system does not say.
For the second step, the first reviewer’s answer and reason.

How it relates to IGA suites

IGA stands for identity governance and administration. An IGA suite is software that handles the whole life of access: asking for it, approving it, creating and removing accounts (called provisioning), and certifying it. Certification is one feature of such a suite. Microsoft Entra ID Governance, Okta Identity Governance and SailPoint IdentityIQ are examples that include it.

A suite has to be connected to the systems it manages, so setting one up is a project. Suites can also carry out a removal themselves, which means giving the tool write access to your systems. Some teams want that. Others do not.

You do not need a suite to certify access. PCI DSS and ISO/IEC 27001 ask that access is reviewed; the SOC 2 points of focus mention a periodic review. None of them names a product. What they leave to you is what a suite also cannot skip: the list must include every account, and someone must confirm that the removals happened.

How to do it without a suite

Write a one-page policy. The systems, how often, and who certifies what.
Export the list from each system. Use the system’s own export, and keep the raw file. Ask for access that comes through groups and nested roles, not only direct assignments.
Put the lists in one sheet. The free user access review template has the columns.
Send each manager their lines and each owner theirs. Ask one question: does this person still need this access to do their job?
Collect the decisions with reasons, and chase. Record anything without a decision as open.
Have administrators carry out each removal. One ticket per line.
Export again and check. Removed access should be gone. Then file the records.

The user access review guide explains each step, and the checklist puts them on one page you can print.

Where certification goes wrong

A “certify all” button. If one click approves everything, many reviewers will click it. Keep lists short and ask for a reason on every revoke and change.
A campaign that is too big. Give each reviewer only their own lines, not the whole company’s.
Reviewers with no context. Show how the person got the access and when it was last used.
A role nobody has read. Certify the role before the people who hold it.
No check on the removal. A revoke that nobody confirms may not have happened.

Where Acciew fits

Acciew is for teams that want a certification without an IGA project. Its open-source collectors only read. They collect accounts, groups and roles from Keycloak, GitHub and AWS IAM. Managers decide from an email link, in one or two steps. At the end you get an evidence pack. Acciew never removes access, so your administrators stay in charge of your systems.

Have an access review coming up?

Acciew is in early access. We are looking for design partners: teams with a user access review ahead of them.

Apply as a design partner

Questions and answers

Is access certification the same as a user access review?

Yes, it is the same job under another name. Some tools use "certification" for the whole round and "access review" for one reviewer's list inside it. The standards care about the list, the decisions and the follow-through, not the word.

What is a certification campaign?

One round of certification. It has a scope (which systems and people), reviewers, a deadline and a result, and it ends. Tools call the round a campaign. A scheduled review is a campaign that comes round again.

How often should we certify access?

PCI DSS says at least once every six months for user accounts. SOC 2, ISO 27001 and HIPAA set no interval, so your policy sets it. Certify privileged access more often than the rest, and certify a person's access when they change role or leave.

Is access certification the same as ISO 27001 certification?

No. ISO 27001 certification is a certificate that an outside body gives a company for its whole security management system. Access certification is one check inside that system, and it supports ISO/IEC 27001 Annex A control 5.18, Access rights.

Who certifies service accounts?

An account that software uses has no manager. The person named as looking after it certifies it, and the owner of the system checks the answer. Without a named person, nobody can say if the account is still needed.

Do we need an IGA suite to certify access?

No. PCI DSS, ISO/IEC 27001 and SOC 2 name no product. You need a whole list, a reviewer for every line, a decision with a reason, and a record that the changes were made. A spreadsheet can do that for a few systems.

This guide is part of User Access Review: How to Run One, Step by Step. Read the whole guide there.