- A current account and access export for the scope under review — pulled the day the review starts
- The privileged account inventory, if the scope includes privileged access
- Line managers' knowledge of current duties, in the room or on the call
ATL-014WORKSHEETEDITORIAL REVIEW COMPLETE
Periodic Access Review Worksheet
A run-and-file worksheet for the recurring question every environment must answer: does everyone who has access still need it? Scope header, per-account keep / reduce / remove decisions, a completion attestation, and the metrics row that shows the review actually removed something.
Using this artifact
Purpose, inputs, and completion
Purpose. Access accumulates: projects end, roles change, contractors leave, and the permissions remain. A periodic access review is the countermeasure — a scoped, attested pass over every account in scope that ends with access removed or reduced, not just observed. This worksheet is the record of one such pass; filed cycle after cycle, the stack of them is the proof the process operates.
When to use it. Complete the header first, pull a same-day export of the accounts in scope, then work the decision table account by account with the relevant managers. Record actions as they are executed, complete the attestation only when every decision has an action date, and fill the metrics row so cycles can be compared. Run quarterly for standard access and monthly for privileged, remote, and vendor access; coordinate any production-system decisions with plant leadership before scheduling removals.
- Fix the scope in the header before opening the export: which systems, which account populations, which review period — a review of 'whatever we got through' is not a review.
- Decide per account with the person's manager, not from IT's memory of what the person does; access follows current duties, not job titles or history.
- Write the decision and the action date separately — 'remove' decided is not 'removed'; the review is complete only when the action-taken column is filled.
- For production-system access, make decisions jointly with plant leadership and schedule removals for maintenance windows; a mid-shift access change on a running line is an operational risk, not a quick win.
- Fill the metrics row last and compare it with the previous cycle; a review that removes nothing, twice in a row, is probably a rubber stamp.
Keeping it honest
Evidence, validation, and failure modes
- A completed, attested review record with per-account decisions and action dates
- A metrics trail (reviewed / removed / reduced) across cycles showing the review operates and bites
- Sample three 'remove' decisions from the last completed review and verify in the identity provider that the access is actually gone.
- Compare the review's account list against a fresh export from the same system; accounts present in the export but absent from the review reveal a scoping gap.
What looks done but is not
- The review is an email that says 'let me know if anything looks wrong' — silence is recorded as approval, and nothing is ever removed.
- Decisions are made but never executed; 'remove' rows sit with empty action-taken cells until the next review re-decides them.
- OT access is skipped because it is inconvenient to review, which leaves the least-monitored systems with the longest-lived access.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain every completed review for at least two years; a reviewer will ask for the last several cycles to see whether reviews recur and whether decisions were executed.
Full document
Preview — exactly what prints
WORKSHEET · IDENTITY & ACCESSv1.0 · REVIEWED 2026-08-06
Periodic Access Review Worksheet
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Access accumulates: projects end, roles change, contractors leave, and the permissions remain. A periodic access review is the countermeasure — a scoped, attested pass over every account in scope that ends with access removed or reduced, not just observed. This worksheet is the record of one such pass; filed cycle after cycle, the stack of them is the proof the process operates.
How to use it
Complete the header first, pull a same-day export of the accounts in scope, then work the decision table account by account with the relevant managers. Record actions as they are executed, complete the attestation only when every decision has an action date, and fill the metrics row so cycles can be compared. Run quarterly for standard access and monthly for privileged, remote, and vendor access; coordinate any production-system decisions with plant leadership before scheduling removals.
Review scope and header
The header turns a pile of decisions into an auditable event: what was reviewed, by whom, over what period.
This review
| Scope (systems and account populations) | Review period covered | Reviewer(s) and roles | Date started | Source of the account export (system, date pulled) |
|---|---|---|---|---|
Production-system scope is reviewed with the plant, not about the plant
When the scope includes OT or production systems, the plant leader or process owner is a co-reviewer, not a courtesy copy. Removals and reductions on production systems are scheduled into maintenance windows with a rollback path — an account change that locks a technician out mid-shift trades a security finding for a downtime incident.
Per-account decisions
One row per account in scope. Every row gets a decision; every remove or reduce gets an action date before the review closes.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Account | Access held | Still required? (Y/N) | Decision (keep / reduce / remove) | Action taken (date) |
|---|---|---|---|---|
| EXAMPLE: j.rivera | CUI project library — read/write | Y | Keep | n/a |
| EXAMPLE: contractor-baker | VPN + file share (project ended 2026-05) | N | Remove | Removed 2026-07-18 |
Reduce is a real decision, not a compromise: an account that needs read access but holds write access is reduced, and the reduction is as much a review outcome as a removal. Record what the access became, not just that it changed.
Completion attestation
The attestation is the difference between a worksheet and a record: a named person states the review covered the whole scope and every decision was executed.
Attestation
| I reviewed every account in the stated scope against current duties (name) | All remove / reduce decisions have been executed and dated (Y / N — if N, list open items) | Date completed | Signature / initials |
|---|---|---|---|
Review metrics
Three numbers, tracked across cycles. They are how leadership — and a reviewer — can tell a working review from a ritual.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Accounts reviewed | Access removed | Access reduced | Cycle completed on |
|---|---|---|---|
| EXAMPLE: 48 | 5 | 3 | 2026-07-18 |
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader |
| Approval authority | Executive sponsor |
| Review frequency | Quarterly for standard access; monthly for privileged, remote, and vendor access |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain every completed review for at least two years; a reviewer will ask for the last several cycles to see whether reviews recur and whether decisions were executed. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.