TL;DR
- Do not ask owners to attest. They usually cannot, and a rubber-stamped review is worse than none because it produces a record showing someone approved the thing that later failed.
- Review by usage instead. Present the diff between permissions granted and permissions exercised, and ask the owner to justify the difference.
- Scope by blast radius, not by uniform interval. Production write access and third-party boundaries first.
- A review is complete when revocations have been executed, not when decisions have been recorded.
- Set the default to remove. No response inside the window means access goes, with a documented rollback path.
Why attestation fails for machine identities
Human access review works because a manager can answer the question. They know what their report does, they know whether the access is still needed, and they carry consequences for getting it wrong.
None of that transfers. The registered owner of a service account is frequently the engineer who created it three years ago, or their successor, or a name inherited through a transfer. Asked whether the account still needs write access to a database they have never opened, the honest answer is that they do not know, and the cheapest answer is yes.
The result is a completed campaign, a full set of attestations, and no change in access. Worse, you now hold a record showing a named person approved the permissions that were later abused. Rubber-stamping does not merely fail to reduce risk. It creates evidence against you.
Review by usage
Replace the question the owner cannot answer with one they can.
This identity has been granted 47 permissions. Over the last 90 days it used 6. Here are the 41 it did not use. We propose removing them. Reply by 14 March if any are needed.
Three things change. The owner is evaluating a concrete list rather than recalling intent. The default is removal, so silence produces the safe outcome rather than the permissive one. And the exercise generates a specific, defensible action rather than a signature.
Two cautions. Ninety days may not cover a quarterly or annual job, so exclude identities with known periodic patterns or extend their window and record why. And usage data has to come from the authoritative source rather than from an agent's own logs, which can be incomplete or manipulable.
Scoping a campaign
Reviewing every non-human identity on the same cycle is neither achievable nor useful. Scope by reach:
| Tier | Population | Cycle | Method |
|---|---|---|---|
| 1 | Can write to production data, or crosses a third-party boundary | Quarterly | Usage diff, plus owner confirmation of continued need |
| 2 | Reads production or sensitive data | Semi-annual | Usage diff, default remove |
| 3 | Non-production and low-privilege | Annual | Automated: retire on disuse threshold, no human step |
Tier 3 should not consume human attention at all. If an identity has not authenticated in ninety days and holds no production access, suspend it automatically and retire it after a further window. The value of a review is concentrated almost entirely in tier 1.
The runbook
- Freeze the population and record how it was generated. An auditor will ask, and a population produced by an undocumented method is a finding regardless of what the review found. See SOC 2 evidence.
- Pull usage for the window from the authoritative log source per platform, not from the application.
- Generate the diff per identity. Granted against exercised, with the unused set listed explicitly.
- Route to the named individual owner. If the owner field holds a team, that is finding number one and the identity goes to the exception path.
- Set a response window and a remove default. Two weeks is typical. State the default in the request.
- Execute. This is the step that turns a review into a control. Removals happen on a stated date whether or not everyone replied.
- Record exceptions properly. Any retained permission that was not exercised needs a reason, a named approver and an expiry. See the policy template.
- Measure the execution rate and report it. Decisions made against changes executed. See metrics.
- Hold a rollback window. Removals are reversible for a defined period. This is what makes a remove default safe enough to run.
What the evidence must show
Assessors under ISO/IEC 27001 A.5.18 and SOC 2 CC6.3 test the same four things:
- Population completeness, with the generation method documented.
- Reviewer identity, a named individual rather than a queue or a team.
- The decision, and what was presented to the reviewer when they made it.
- Executed change, with timestamps. A decision to revoke that was never carried out is the single most common way a review fails testing.
Keep the request artefact itself, not only the outcome. Being able to show exactly what the reviewer saw is what distinguishes a real review from a signature collection exercise, and it is the difference an experienced auditor is looking for.
Frequently asked questions
How do you run an access review for service accounts and machine identities?
Not by attestation. Present the diff between permissions granted and permissions exercised over a window, typically ninety days, list the unused permissions explicitly, propose removing them, and set a response deadline with removal as the default. This replaces a question the owner cannot answer, whether the access is still needed, with one they can, whether these specific unused permissions are required.
Why does attestation-based review fail for non-human identities?
Because there is no manager who knows what the identity does. The registered owner is often the engineer who created it years ago or someone who inherited it, and asked whether it still needs a permission they have never observed being used, the honest answer is that they do not know and the cheapest answer is yes. The result is a completed campaign with no change in access, plus a record showing a named person approved permissions that may later be abused.
How often should non-human identities be reviewed?
By reach rather than uniformly. Quarterly for identities that can write to production data or cross a third-party boundary, semi-annually for those reading production or sensitive data, and annually for non-production low-privilege identities, which should be handled automatically through a disuse threshold rather than consuming human attention. Nearly all the value of a review is concentrated in the first tier.
When is an access review complete?
When the revocations decided have been executed, not when the decisions have been recorded. A review that decided to remove access and did not is a finding rather than a control, and the gap between decisions made and changes executed is worth measuring and reporting as a metric in its own right.
What evidence does an auditor want from an NHI access review?
Four things: population completeness with the generation method documented, a named individual reviewer rather than a queue or team, the decision together with what was actually presented to the reviewer, and executed changes with timestamps. Keeping the request artefact rather than only the outcome is what distinguishes a real review from a signature collection exercise.
Need these numbers before your next board cycle?
HumanAudit produces the baseline: measured inventory coverage, credential lifetime distribution, authority ratio and a timed revocation drill. Four numbers, evidenced, in a form a board can read.