The user access review template, column by column
The review record itself, header first, then eleven columns, then a worked row for the account that should not have been there.
A user access review template is one row per account in one named system, under a header that says where the account list came from. Each row carries the person, the access held, a decision of keep, reduce or remove, and the ticket that carried it out.
The whole record is below. Header, eleven columns, then a worked row. No form and no email.
The header that fixes the population
Six fields sit above the rows. They settle the question a reader asks before reading a single decision: which accounts were in front of the reviewer, and how anyone knows that was all of them.
| Header field | What it settles |
|---|---|
| System reviewed | One application or environment, named as your inventory names it |
| Review period | Start and end dates. Coverage is decided by date |
| Population source | The report that produced the list, the tool, the timestamp |
| Row count | Accounts the export returned, so none fall out unnoticed |
| Reviewer | The person deciding, by name and role. Not a team |
| Completed and approved | When the last row was decided, and who accepted it |
The eleven columns
One row per account. The third column is the one your sheet will not have: the defect that makes a filled cell useless.
| Column | What it is for | What fails the row |
|---|---|---|
| Account identifier | One row, one identity, as the export writes it | A display name. Two people called Chris Martin merge |
| Person and status | Employee, contractor, terminated, or service account | A blank. Status decides which rule applies |
| Access held | The role as the system names it, say AdministratorAccess | A paraphrase like normal access. Nothing gets decided |
| Privileged | Yes or no, by the definition in your policy | Every row no. Then the definition is wrong |
| Granted on, granted by | When the access was given, and who approved | An empty cell. Unknown is a value; blank is not |
| Business justification | The work this access exists to do | Needs access. A reason fitting everyone justifies no one |
| Decision | Keep, reduce or remove. One per row | A checkmark. It records attention, not a decision |
| Reason | Why, for every reduce, remove and privileged keep | Blank on a removal. The next reviewer inherits nothing |
| Action ticket | The ticket that carries out the decision | The word done. A status references nothing |
| Completed on | The date the change landed in the system | The day you closed the ticket, not the day access went |
| Verified by | Who confirmed the change, and the record read | The reviewer name again, where policy wanted two people |
A worked row
A contractor whose production access outlived the engagement, as the row would sit in the sheet.
| Column | Value |
|---|---|
| Header | aws-prod-payments, 2026-04-01 to 2026-06-30. IAM credential report exported 2026-07-08 09:14 UTC, 41 rows. Reviewer Priya Raman, VP Engineering |
| Account identifier | dana.okafor@acme.io |
| Person and status | Dana Okafor, contractor, terminated 2026-05-02 |
| Access held | AdministratorAccess, via the sso-engineering group |
| Privileged | Yes |
| Granted on, granted by | 2025-11-14, approved by Priya Raman in TICKET-2291 |
| Business justification | Payments migration, statement of work closed 2026-05-02 |
| Decision | Remove |
| Reason | Access survived offboarding by 67 days. Offboarding covered the identity provider, not the group |
| Action ticket | SEC-412, opened 2026-07-08 |
| Completed on | 2026-07-08, group membership removed 16:12 UTC |
| Verified by | Marcus Lee, from the RemoveUserFromGroup event in the audit log |
Do not delete the account quietly and file the review as clean. Catching a 67 day gap and saying so is the control working. A year of reviews that found nothing describes a company nobody joined or left.
Where the account list comes from
A review of a list you typed proves you typed a list. The population has to come out of the system, at a stated moment, from a named report you can run again.
Keep the raw export beside the record and carry its row count across. If the export has 41 rows and the sheet has 38, the missing three are the review. The same rule runs through the evidence request list, which asks for whole populations.
The reviewer is not the person who granted the access
An administrator reviewing their own grants is making the same judgment twice. Nothing new gets tested. The control wants a second opinion from someone who knows what the job needs, not what the console allows.1
At five people the pool is small and the reviewer may be a founder. Fine, and testable, as long as the record names both people and the names differ. What a small team actually has to do takes that substitution through the rest of the controls that assume more staff than you have.
What reviewed has to mean in writing
A decision, a reason, a name and a date, per row. Blank means not reviewed. Where a privileged account is kept, the reason column answers why an ex-migration contractor still held it.
A clean quarter is a legitimate outcome and gets written the same way. State the population and say that all 41 accounts were kept.
Silence is not a decision.
Terminated users, service accounts, shared credentials
Three row types break the pattern. The person the row is about is not the person holding the account.
- Terminated users
- They should not be in the active export at all, and this review is what catches them when they are. Check it against your leaver list. A leaver who appears gets a row carrying the termination date, the removal date and the gap in days.
- Service accounts
- Each needs a named human owner, the system it serves, and the dates its credential was last rotated and last used. No owner means nobody to ask. No recent use makes it a removal candidate, and saying so tells the next reviewer it was considered.
- Shared credentials
- List everyone holding it and say whether the system can attribute an action to one of them. If it cannot, put that in the reason column. A shared login with named holders and a written blind spot is a smaller finding than one nobody counted.
The evidence the review leaves behind
Five artifacts, dated in this order. Rebuilt from memory afterwards they carry the date of the rebuild, and the dates carry the test.
- The source export, unedited, tool and timestamp visible.
- The completed record, every row decided, reviewer named, dated.
- One ticket per action, referenced by identifier from its row.
- A system record per change: the log line showing access went.
- A dated approval, signed after the last row was decided.
One habit protects all five. Do not re-save the record after the approval date. A sheet modified three months after the sign off invites a question the document cannot answer.
Which criteria this maps to
The logical access common criteria.1 CC6.1 covers the access controls protecting the system. CC6.2 covers registering and authorizing users before credentials are issued, and removing access when it is no longer appropriate. CC6.3 covers authorizing, modifying and removing access by role, with least privilege and segregation of duties considered.
Your engagement fixes the exact mapping in its control matrix. Cadence is your choice, and your approved policy becomes the standard you are tested against.2 The policy list covers how a promise inherited from a template turns into a deviation you never needed.
Polara G.R.C. takes this record as evidence against the access control criteria and indexes it into the package your independent partner auditor reviews. Scope is Security only, fixed rather than a setting. Type 1 is $4,000 one time, first examination and auditor engagement fee included. Type 2 is $600 per month on a 12-month term, and an examination is $5,000 once the 3-month observation window completes on an active subscription.
Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.
Questions
What is a user access review?
What columns does a user access review template need?
Who should perform a user access review?
How often should user access reviews happen?
What evidence does a user access review have to leave behind?
Sources
Get audit-ready without a compliance team.
$4,000 one time for SOC 2 Type 1, with the first examination and the auditor engagement fee included. audit-ready starting at about a week.
Get startedPolara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.