User access review template (CSV + checklist)

The columns your template needs

One row per person per system. Six columns, no more:

• User — name and email, exactly as the system shows it.
• Entitlement — the role, group or permission being reviewed, not just "has access."
• Reviewer — the one person accountable for this row, usually the user's manager or the system owner.
• Description — one plain sentence explaining what the entitlement lets someone do. This column is the one most templates skip, and it is the one that decides whether a review is real.
• Decision — approve, revoke, or don't know. All three are valid answers.
• Last login — pulled from the system, not guessed. An account with no login in 90 days is a decision waiting to happen, before the reviewer even reads the description.

Why "don't know" is a required answer

A review form with only two buttons — approve or revoke — trains reviewers to click approve on everything, because revoking is a decision and approving feels like no decision at all. A quarterly review with 140 reviewers and a completion rate of 34%, where the ones who did finish "approve every single row," is not a hypothetical: it is the state of the practice reported by a sysadmin describing their own company's review (r/sysadmin).

Adding "don't know" as a third, equally valid button changes the incentive. A reviewer who genuinely cannot tell what an entitlement does is not supposed to approve it by default; they are supposed to say so, and the row gets escalated to someone who can answer it — usually whoever owns the system. That single change, more than any tooling, is what turns a rubber stamp into a review.

Running the review with the template

1. Export the user list from each system you are reviewing, one CSV per system, with a real last-login timestamp.

2. Merge into the template, fill in the description column once per unique entitlement (not once per row — most systems have far fewer entitlements than users), and assign a reviewer to every row.

3. Split the sheet by reviewer and send each person only their own rows. A 9,800-row file emailed to 140 managers gets ignored; a 40-row file addressed to one manager gets opened.

4. Set a deadline and a reminder before it, not after it.

Closing out: lock, record, store

Once every row has a decision, the review is not finished until three more things happen:

• Lock the sheet. A spreadsheet anyone can still edit after the fact is not evidence of anything that happened on a given date.
• Record revocations with dates. "Revoke" on a spreadsheet row is not the same as the access being removed. Note when the removal actually happened, and by whom.
• Store it somewhere findable. A copy on one person's laptop is not a record; a shared, dated, locked file that the next reviewer or the next auditor can find in under a minute is.

When a spreadsheet stops being enough

A spreadsheet works well for one system, one quarter, and a handful of reviewers. It gets harder to run honestly once you are splitting rows by hand every quarter, chasing reminders manually, and reconstructing what happened three reviews ago because the old file got overwritten. At that point the columns above are still the right columns — what changes is who tracks the deadlines, sends the reminders, and keeps every past review intact instead of overwriting it.

Common mistakes, and how they show up later

• Leaving the description column blank. A row that just says "Admin — Finance system" gives a reviewer nothing to decide on. Write the description once per entitlement, not once per row, so filling it in for a whole system takes minutes rather than hours.
• Sending the full sheet to every reviewer. A manager who has to scroll past 9,000 rows that are not theirs to find their own forty will not do it twice.
• Reusing one file across quarters. Overwriting last quarter's review with this quarter's answers destroys the one thing an auditor asks for most: the cadence. Save each review as its own dated file.
• Treating "revoke" as done the moment it is typed. The row is a decision, not an action. Someone still has to go remove the access and note when that happened.

Choosing reviewers before you choose a tool

The template only works if every row has exactly one person who is accountable for the answer. For most entitlements that is the user's manager; for anything tied to a specific system — a finance tool, a production database, a codebase — it should be the person who owns that system, because a manager outside the team usually cannot tell what the entitlement does any better than the checklist description can. Deciding this mapping once, before the first review goes out, saves the far more painful process of reassigning rows mid-review because the wrong person got them.

Questions

Can I just use this template forever instead of a tool?

Yes, for as long as it stays manageable. The template above is the same shape of data AttestProof imports, so nothing you build with it is wasted if you outgrow the spreadsheet later.

What if a system has no "last login" field?

Leave the column blank rather than guessing. A blank last-login is still more honest than an invented one, and it tells the reviewer to check the account another way.

Who should be the reviewer for a shared or service account?

Whoever owns the system it touches, not whoever happens to be listed as the account holder. Name that person explicitly in the reviewer column rather than leaving it to be worked out later.

Next step

The columns above are the exact import format AttestProof reads. Fill in the template, and you can bring the same file into AttestProof later to split it by reviewer automatically, send the reminders, and generate a timestamped evidence pack when the review closes — without re-entering anything.