How to run an access review

Pull the current account list from each system, compare it with your list of people and their roles, and ask each system’s owner to confirm, change or remove every account. Act on the decisions within an agreed window, check the removals took effect, and keep the dated lists and decisions as evidence. Review privileged access more often than everyone else.

When you need this

ISO 27001:2022 Annex A 5.18 expects access rights to be reviewed at regular intervals and when people change role or leave, within the access control rules of 5.15 and the identity lifecycle of 5.16. Annex A 8.2 adds tighter handling of privileged rights, and 8.3 restricts access to what each role needs. SOC 2 CC6.1 to CC6.3 cover logical access, registering and removing users, and role-based access; auditors sample the review under CC6.2 and CC6.3. Cyber Essentials, user access control requires accounts to be approved, kept unique and removed when no longer needed. UK GDPR Article 32(1) and Article 5(1)(f) require appropriate security of personal data, which access control is part of.

An IT or security lead usually runs the review; each system owner makes the decisions.

This is guidance to help you understand the requirement, not legal advice.

Before you start

You need a current people list from HR with roles, start dates and leave dates; an asset or application inventory showing each system and its owner; and administrator access to export each system’s user list. Agree the decision window (10 working days is common) and who signs off.

A review of three or four systems at a 30-person firm takes half a day of preparation and an hour per system owner. A first review, before the inventory is clean, can take a week.

Steps

Scope the review: list the systems in scope and the account populations in each, including users, privileged accounts, service accounts and third-party accounts. Done when every population has an owner.
Pull the current account list from each system, with the export date and who pulled it. Done when each list is saved unaltered.
Include Sted in the scope. Open Plan and Users and save a dated screenshot of the user list with each person’s level. Done when the roster is saved with the date.
Map every account to a person on the people list, flagging joiners, movers and leavers since the last review. Done when no account is unmatched or every unmatched account is flagged.
Review each account with the system owner for role fit, least privilege, separation of duties and inactivity over 90 days. Done when the owner has decided keep, change or remove for every account.
Record each decision and the reason. Done when the record shows every account and its outcome.
Act on the decisions within the agreed window. Done when each change or removal has a date and a ticket or log entry.
Verify the removals by pulling the lists again. Done when no removed account still appears.
Record the completed review, the sign-off and the next review date. Done when the next date is scheduled.

Frequency and leavers

Set the frequency in your access control policy and keep to it. A common pattern is all user access once a year, privileged accounts every six months, and anything holding payment card data at least every six months. Sted’s Access Control Policy uses that pattern and adds a 90-day limit on inactive accounts. SOC 2 teams often run user reviews quarterly because the auditor tests each period.

The leaver checklist

Most access review findings are leavers whose access was missed. A review catches them late; the leaver process should catch them on the last day. Build the leaver checklist from the asset inventory so it lists every system, including those outside single sign-on, shared passwords and physical access. Record the date each was removed. The review then becomes the check that the checklist worked.

Reviews that change nothing

A review where every account is kept, every time, is a sign the reviewer is not looking. Ask the owner to state the role each account serves, and treat “not sure” as remove.

Worked examples

ISO 27001, a six-monthly privileged review at a 30-person firm

On 1 September 2026 the IT lead of a 30-person software firm pulls privileged accounts from the identity provider, the cloud console and the CRM: 23 accounts in all. Mapped against the people list, four are dormant with no sign-in for over 90 days: two former contractors, a test administrator and a service account whose owner left. Two are over-privileged: a support lead keeps cloud administrator rights from an old project, and a sales manager has CRM super-administrator rights when reports would do (Annex A 8.2 and 5.18).

The system owners decide on 2 September. The four dormant accounts are removed or, for the service account, given a new owner and rotated credentials; the two over-privileged accounts are reduced. Every change is made by 9 September and verified by a fresh export on 10 September. The completed Access Review Record notes the populations, decisions and evidence, and the next review is set for March 2027.

SOC 2, a quarterly user access review the auditor samples

A 50-person SaaS company runs a quarterly user access review of production systems as a stated control under CC6.2 and CC6.3. For a 12-month Type II period the population is four reviews. The auditor samples two and asks for the dated exports, the reviewer’s sign-off, and the tickets for each removal. They also sample five of 18 leavers and compare each leave date with the account disable date. A review with no export, or a removal with no ticket, becomes an exception.

Cyber Essentials, accounts removed when no longer needed

The same leaver and dormant-account checks are the evidence for Cyber Essentials, user access control, with administrator accounts kept separate and used only for administration.

Under UK GDPR Article 32(1), the review shows that only people who need personal data can reach it; apply it first to systems holding special category data.

Checklist

How Sted helps

33 periodic record types come with a suggested frequency, but nothing is scheduled until you pick a first due date.
Records follow templates with sections and, where useful, structured fields you can report on.
Records are part of the Full Management System plan.
People have one of four levels: Administrator, Policy and Process Owner, Reviewer, Personnel.
One shared rule set decides what each level may do, the app and the API apply the same one, and ownership, record classification and document status narrow it further.
Sted does not connect to your cloud, code or HR systems to collect evidence automatically; you record it.

Sted does not connect to your identity provider or other systems to pull account lists; you export them and record the review.

ISO 27001 organisational controls: controls 5.15 to 5.18 in context.
ISO 27001 technological controls: privileged access and access restriction.
SOC 2 security common criteria: CC6.1 to CC6.3 and what auditors test.
Cyber Essentials five technical controls: user access control in the scheme.
Repeating records: scheduling the review in Sted.
People and levels: what each level in Sted can do.

Frequently asked questions

How often should a SOC 2 access review happen?

Quarterly is the common choice for systems in scope, and many firms review privileged access monthly. SOC 2 does not set a frequency; your own policy does, and the auditor tests that you met it in every period. Pick a frequency you will keep, because a missed quarter is an exception in the report.

What goes on a leaver access removal checklist?

Every system the person could reach: single sign-on, email, cloud consoles, code repositories, the CRM, finance tools, shared passwords, and physical keys or badges. Add the date each was removed and who removed it. Build the list from your asset inventory, not from memory.

Should service accounts be in the review?

Yes. Service accounts often hold broad rights and outlive the person who created them. Each needs a named owner, a stated purpose and a check that its credentials are rotated or protected.