Access reviews and certification

An access review is a periodic exercise in which somebody who knows what people do looks at what people can reach, and confirms or removes each one. That is the whole idea. It is unglamorous, it is required by three separate frameworks, and almost no small organisation has ever done it.

Why three different frameworks all ask for this

Because standing access is the most reliable way an organisation accumulates risk without deciding to. Nobody grants a person too much access on purpose. It happens one project at a time, over four years, and the only mechanism that reverses it is somebody deliberately looking.

NIS2 — Article 21(2)(i)

Human resources security, access control policies and asset management. Evidenced in the control catalogue as NIS2-A21-9, which the catalogue-level mapping puts against ISO 27001 A.5.15 access control and A.5.18 access rights. A.5.18 is specifically about reviewing rights, which is the part a paper policy does not satisfy.

DORA — Article 9

Protection and prevention, covering how access is granted and how identity is proven. Relevant if you are an EU financial-sector entity or you supply one. Findings about privileged and administrative access carry this tag.

SOC 2 — CC6.1 and CC6.3

The trust-services criteria on logical access and on managing changes to it. An American customer's questionnaire usually asks this version, and it will ask when the last review was.

Notice what all three want. Not a policy saying reviews happen. Evidence that a specific review happened on a specific date, that a named person decided about each entitlement, and that removals were carried out. A policy document with no review behind it is the answer auditors are most practised at recognising.

Why a small company never actually runs one

Because the enterprise version of this exercise is unaffordable in every currency that matters to you. Identity governance products build campaigns, assign reviewers, chase them, and produce an attestation record per entitlement. They are priced for organisations with an identity team and they take weeks of somebody's attention to configure. A forty-person firm with one IT generalist will not do that, and it is not irrational of them.

So the honest position, recorded in our own engineering notes rather than in a brochure, was this: an SMB will never run a manual access review, yet NIS2, DORA and SOC 2 all require evidence that access is periodically justified, and nobody serves that segment. That is the problem this product exists for, and it is why certification is now in the console rather than on a roadmap. The part that makes it affordable for a forty-person firm is not the campaign machinery — every governance product has that — it is that Sentinel Q can read the evidence and argue a position on each row first, so the reviewer is correcting a draft rather than starting from a blank list. The model can recommend and cite; only the named human can decide.

What the platform gives you today

The permission catalogue and role grants

Permissions expressed as resource.action, with the grants for the built-in roles held as data in the database rather than scattered through application code, so "what does a viewer actually get" has one auditable answer. Read the catalogue at GET /api/v1/permissions and a role's grants at GET /api/v1/roles/{roleID}/permissions. See Who can see and do what.

The audit log

Role changes, invitations, disablements and session revocations, recorded with an actor and a timestamp under action names such as role.granted, organization.member_added and user.status_changed. This is what turns "we reviewed access" into "here is the removal we performed on 14 March". Read it at GET /api/v1/organizations/{orgID}/audit, which accepts actor, action, from and to filters, the last two as RFC 3339 timestamps.

Posture findings on privileged accounts

The assessment of your Microsoft 365 estate produces named findings about exactly the population an access review is about. Each finding enumerates the real accounts rather than a count, and that list is the raw material.

A booked review

Four posture checks propose a change of kind schedule_access_review, which books a review and changes no access at all. It is one of only nine change kinds the platform applies without asking you, precisely because booking a review cannot break anything. The undo is cancel_access_review, and cancelling affects no access either.

Something is being built underneath, which explains why the next wave is a smaller job than it sounds. An append-only history of access changes is captured by database triggers on group and organisation membership, so a grant cannot be missed by an application path that forgot to log it. Its own comment calls it groundwork rather than a feature, and nothing reads it today. It exists because certification needs access history rather than current state: "these twelve users acquired the same four groups within a week of joining" is only visible if the grants were recorded as events at the time.

How to run a defensible review now

This takes an afternoon for an organisation of forty people and produces something an auditor will accept. The discipline that makes it defensible is recording the decision, not the mechanics of gathering the list.

1. 1

   Fix the scope and the date before you look at anything

   Write down what you are reviewing — for a first review, everyone with any administrative access, in the platform and in Microsoft 365 — the date, and who is doing it. An undated review of an unstated scope is not evidence of anything. Quarterly is defensible for privileged access; annually for ordinary staff access.

2. 2

   Pull the two lists

   Platform side: your organisation's memberships with the role against each name. Microsoft 365 side: start a posture run and read the privilege findings, which name your actual global administrators, the people holding four or more roles, and the groups that confer administrative roles. Do not reconstruct either list from memory or from a spreadsheet somebody maintains.

3. 3

   Decide per person, and say why

   Keep, reduce, or remove. The reason is the part that matters — "keep: runs the finance system" and "remove: left the project in January" are both fine, and "keep" with no reason is what an auditor will pick on. Two administrators is the right number for a small business: one working admin and one emergency account.

4. 4

   Check the two cases a manual review usually misses

   Roles held through a group, because the group looks ordinary and nobody thinks of it as an access grant. And role accumulation on one long-serving person, because each individual grant was reasonable at the time. Both have a dedicated posture finding, and both are worth checking explicitly rather than trusting a name list to reveal them. Review guests as a separate population, against finished projects rather than against people you recognise.

5. 5

   Carry out the removals through the platform, not around it

   A role change made in the console produces an audit row with an actor and a timestamp. The same change made by somebody logging directly into Microsoft with a shared credential produces nothing you can show. This is the step that converts your review into evidence.

6. 6

   Record the decisions on the findings themselves

   Where a finding is one you are consciously accepting rather than fixing, accept it in the report and give the reason. An accepted finding appears in the evidence bundle exactly as a fixed one does, and a register of risks seen, weighed and accepted with dates and reasons is stronger evidence of governance than a bundle with no accepted risks in it. See Done, approve, decide.

7. 7

   Generate and stamp an evidence bundle, then keep your own sheet alongside it

   The bundle captures the state at the end of your review with a verifiable chain of custody. It does not contain your review sheet — the scope, the date, the reviewer and the per-person decisions — so keep that yourself and file the two together. That pair is what you hand over when the request in What an auditor will ask for arrives.

What is not built, precisely

Precision here is worth more than reassurance, because these are the words a questionnaire uses.

• No recertification schedule. Booking a review does not drive a recurrence; you book the next one yourself.
• No per-user effective-permission view. Assembling "what can this one person actually do" means joining the members list, the roles list and each role's permissions yourself.
• No tenant-role revocation performed by the platform. A campaign can revoke group memberships and application assignments; a tenant role is recorded as revoked and left for a human, for the reason given above.

What certification does and does not do for you

The design position was settled before the feature was built, and the shipped behaviour follows it.

• Certifying or revoking an entitlement is never decided autonomously. Sentinel Q writes a recommendation and a rationale citing the evidence snapshot it read; the row stays undecided until a named person clicks. The column the model writes to and the column the verdict lives in are different columns, and the statement behind the model's tool does not name the second one. A product that auto-approves the easy 80% of a review is auto-approving the entitlements nobody was worried about, and reporting that as coverage.
• A revocation the platform did not perform is labelled as one. Removing a group membership or a directly-assigned application happens immediately and is recorded as removed. A tenant role is recorded as revoked and marked "not removed — manual step", and the campaign keeps counting it as outstanding after the review closes. The difference between those two states is whether somebody still has the access, so they never share a colour.
• Role mining is presented as a hypothesis, not a finding. Deriving roles from observed access is a computationally hard problem with no published accuracy worth quoting, and the shipped feature describes itself the honest way: a lossy compression of your current access. Every proposal carries the people and the support fraction behind it, the low-confidence tail is visible rather than hidden, and acceptance is always a human decision.
• Granting privileged access will still never be automated. That rule holds at every autonomy tier and is structural: the capability is not exposed to the model at all, so it cannot be reached by a cleverly worded instruction.
• The evidence shape will not change much. A review with a date, a reviewer, a per-entitlement decision and a record of removals is what the frameworks want, and it is what you should be producing by hand in the meantime. A review you run manually this quarter is not wasted work that a future feature will replace — it is the same artefact produced the slow way.

What to read next

1. What an auditor will ask for — where the access review sits among the other nine requests.
2. Who can see and do what — the roles and permission catalogue your platform-side review works from.
3. Discovering privileged accounts — finding the administrative accounts nobody remembers creating.