Attestation is the moment someone with authority puts their name to a set of access and states that it is correct. In identity governance it is the closing act of an access review or certification. After the access has been examined, the accountable person formally confirms the result and takes responsibility for it. The word carries weight on purpose. To attest is to stand behind a statement, and an attestation is meant to mean that a specific person with the standing to judge looked at this access and vouches for it.
the examination the attestation ---------------------------------------- ---------------------------------------- look at each grant: what it is, a named person signs: "this access is whether it is used, why it exists correct as of this date" decide keep or remove per entitlement, timestamped (the work) (the accountability) defensible only if: context was shown, decisions are per item, rejections were removed
Where does attestation sit in a review?
A review has two halves, and they carry different weight.
| Half | What happens | What it produces | What a framework can inspect |
|---|---|---|---|
| Examination | Access is looked at and decisions are made | Keep-or-remove calls | Nothing directly; the quality of thinking is not inspectable |
| Attestation | The decisions are formally recorded and owned | A named, timestamped sign-off | Everything: who, when, on what |
Why frameworks lean on the second half
The examination is the work and the attestation is the accountability, and compliance frameworks lean on the second because it is what makes a review inspectable after the fact. A framework cannot examine the quality of someone's thinking during a review. It can require a named, timestamped sign-off from an accountable party and hold the organization to it, which is why the paperwork centers on the attestation step. The consequence is worth stating plainly: every framework requirement in this area is satisfiable by a signature, and only the organization has any real interest in the examination behind it. A security engineer who has argued about what SOC 2 can and cannot prove made the same point from the other direction:
SOC2 does a great job of assuring that you don't have to trust us that we're terminating access when employees leave, and that we're conducting frequent access review meetings.
Who attests, and why does it matter?
The attester should be someone accountable for the access, and accountability has two components.
Standing
Standing is the authority to make the call. The person's manager has standing over the person's access, because the manager is accountable for what the role requires. The owner of an application has standing over its entitlements, because the owner is accountable for what the application permits. Standing follows the org chart, which makes it easy to route on and easy to audit.
Knowledge
Knowledge is enough understanding to make the call truthfully: a manager knows what their reports do, and an application owner knows what an entitlement grants. Knowledge belongs to the person rather than the role, so nothing in a routing rule guarantees it, and nothing in the resulting record reveals its absence.
When the two live in different people
The two do not always sit in the same person. A manager has standing over a report's access to the support platform and no idea what a role inside it grants. The application owner knows the role and has no idea whether the report still needs it. Three routings resolve this, and they trade defensibility against effort. Send the row to both and require both. Send it to the manager with the application owner's plain-language description of the role attached. Or split by entitlement class, sending the sensitive roles to the owner and the ordinary ones to the manager. The first is the most defensible and the most expensive. The second is what works in practice, and it depends on someone having written the descriptions.
How attestation goes hollow
This requirement is where attestation most often fails. When the sign-off is routed to someone without context, such as a manager handed a list of entitlements they cannot interpret, the attestation still gets signed. It satisfies the form while meaning nothing. A signature from someone who could not actually evaluate the access is the identity-governance version of a rubber stamp.
What does the record have to contain?
An attestation is only as good as the record it leaves, and the record is what an auditor reads a quarter or a year later. Six fields carry the weight.
| Field | What it establishes |
|---|---|
| The attester | Who made the call, by name rather than by role |
| The scope | What was covered, and by implication what was not |
| The decision | Keep or remove, recorded per entitlement |
| The timestamp | When the call was made, against the schedule the policy commits to |
| The context shown | What the attester was looking at when they decided |
| The enforcement result | What happened in the application to the items marked for removal |
Why the context snapshot matters
The fifth field is the one most records omit, and it is the one that makes the others meaningful. An attestation says a person judged this access correct. Without a record of what they saw, there is no way to tell later whether the judgement was informed or a click. The snapshot also protects the attester, because access that looked reasonable on the evidence available is a different finding from access nobody examined.
How long the record has to survive
An audit examines a period, and the sample is drawn from inside it. That means the record has to outlive the review by longer than most teams plan for: through the audit that covers the period, and through the following one, which will test whether the practice was consistent rather than one-off. Records held in a spreadsheet on someone's drive tend not to survive a reorganisation, let alone two audit cycles.
What makes an attestation defensible?
Three things separate a real attestation from a signature.
1Context
The attester saw what the access does, whether it has been used, how it was granted and whether the person is still in the role that justified it. The decision was informed rather than guessed.
2Granularity and record
The sign-off was per entitlement rather than a single approval covering everything, and it was recorded with who, what and when. A single signature over a spreadsheet attests to nothing in particular.
3Enforcement
Whatever the attester rejected was actually removed, in the application where it lived. An attestation that confirms some access should go, followed by that access staying, is a contradiction an auditor will find.
| A signature | An attestation | |
|---|---|---|
| What the attester saw | A list of entitlement strings | What each grants, last use, how it was granted, current role |
| Granularity | One approval for the sheet | One decision per row |
| Record | A completed campaign | Reviewer, timestamp and decision per row |
| Rejections | Noted | Executed |
| Value to an auditor | A liability that looks like a control | Evidence that can be relied on |
Every decision in an Iden access review is recorded per row with the reviewer, the timestamp and the context they saw: employment status, department, role and groups beside the entitlement. A rejection executes the revocation in the application, so the attestation and the enforcement are the same click and the evidence cannot say one thing while the system says another. The feature behind it is Access reviews with a decision on every row.
A SOC 2 review of one app. Two rows are flagged because the employee is Inactive in HR and still holds access, and three of the rows are not people.
An attestation with all three is evidence an auditor can rely on. An attestation with none of them is a liability, because it looks like a control while providing none of the protection a control is supposed to give.