Skip to main content

Free template · no signup

The user access review, built the way an auditor tests it.

A working review workbook, and the 40 questions an auditor or examiner will ask about your review — each mapped to the clause that asks it in 15 US, Canadian and international frameworks.

Ready to run your own review? Download the free workbook ↓

Two tools, one set of questions

A user access review is the periodic check that every account’s access to a system is still needed, decided by someone qualified to judge it, with the removals carried out and evidenced. Auditors test whether it happened, and whether it could have caught anything.

On this page

Audit readiness checklist

Am I ready for the auditor? The 40 questions auditors and examiners ask about an access review. Pick who audits you and it shows what your frameworks require, then exports your answers as a report.

In the download

Review workbook

Run the review itself. Paste your user listing, record decisions, verify removals. It flags self-review, rubber-stamping and unproven populations as you go, and includes the same checklist as its own sheet.

Step 1 · Who audits you?

Banking & financial services

Healthcare

General

Or choose frameworks one by one (none selected: showing every question)
United States
Canada
International

Area 1 of 11

Scope

Which systems and which accounts, and why those.

  1. S1 Show me the list of systems in scope for this review, and why each one is on it.

    Status for S1
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether scope was derived from something — financial significance, cardholder data, ePHI, nonpublic information — or inherited from last year.
    Evidence that closes it
    A systems register naming, per system, the reason it is in scope, the business owner, the risk tier and the review cadence that tier carries.
    The finding if not
    A financially significant or regulated-data system that is missing from the review scope entirely, usually one added since the scope was last set.
    • SOX / ICFR AS 2201 — ITGCs over systems relevant to financial reporting supporting
    • SOC 2 CC6.1 (identifies and manages the inventory of information assets) supporting
    • PCI DSS 12.5.1 (inventory of system components in scope) required
    • NYDFS Part 500 500.13(a) (asset inventory) required
    • HIPAA 164.308(a)(1)(ii)(A) (risk analysis identifies where ePHI lives) supporting
    • NIST 800-53 / CSF CM-8 (system component inventory) required
    • NI 52-109 s. 3.1 and 3.4, via COSO 2013 Principle 11 (general controls over technology) supporting
    • OSFI B-13 2.2.2 (inventory maintained and assets categorized) required
    • ISO 27001 A.5.9 (inventory of information and associated assets) required

  2. S2 Does the review cover every account type on those systems — local, shared, emergency, service and vendor — or only accounts that come through SSO?

    Status for S2
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether the population is the application's own account table or the identity provider's view of it. Local accounts bypass SSO and are where auditors look first.
    Evidence that closes it
    Per system, a count of accounts by type from the application itself, reconciled to what the review covered.
    The finding if not
    Local administrator and break-glass accounts absent from the review because the extract came from the IdP.
    • SOX / ICFR AS 2201 — access to programs and data supporting
    • SOC 2 CC6.1, CC6.2 supporting
    • PCI DSS 7.2.4 (all user accounts, including third-party/vendor accounts) required
    • FFIEC II.C.15 (identify and restrict logical access to all system resources) supporting
    • HITRUST 01.b (user registration) supporting
    • NIST 800-53 / CSF AC-2(a) (define and document account types) required
    • OSFI B-13 3.2.7 supporting
    • ISO 27001 A.5.16 (identity management, full life cycle) supporting

  3. S3 Are you reviewing entitlements, or just confirming that accounts exist?

    Status for S3
    Why it is asked, what closes it, and the clauses
    What they are testing
    Precision. A review that asks 'should Jane have an account in the ledger?' cannot catch Jane holding the journal-approval role.
    Evidence that closes it
    Review lines at the level access is granted — role, group, permission set — with the entitlement named, not the account alone.
    The finding if not
    An account-level review that approved users holding access far beyond their role, because the role was never shown.
    • SOX / ICFR AS 2201; PCAOB Staff Audit Practice Alert No. 11 (precision of review controls) supporting
    • SOC 2 CC6.3 (reviews access roles and rules) supporting
    • PCI DSS 7.2.4 (user accounts and related access privileges) required
    • NYDFS Part 500 500.7(a)(4) (review all user access privileges) required
    • HIPAA 164.308(a)(4)(ii)(C) (review and modify a user's right of access) required
    • HITRUST 01.e (review of user access rights) required
    • NIST 800-53 / CSF AC-6(7) (review of user privileges) required
    • NI 52-109 via COSO 2013 Principle 11 (general controls over technology) supporting
    • PIPEDA Principle 4.7.3(b) (need-to-know access) supporting
    • Québec Law 25 s. 20 (access only to information needed for duties) supporting
    • Ontario PHIPA s. 12(1) (reasonable steps against unauthorized use) supporting
    • ISO 27001 A.5.18 (access rights reviewed) required

  4. S4 How did you decide how often each system is reviewed?

    Status for S4
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether the cadence is tied to risk and written down, or chosen for convenience. Where a framework prescribes a floor, whether you meet it.
    Evidence that closes it
    A cadence per risk tier in the access control procedure, citing any prescribed floor — six months under PCI DSS 7.2.4, annual under NYDFS 500.7(a)(4).
    The finding if not
    A single annual cadence applied to systems where PCI DSS requires six months, or no stated cadence at all.
    • PCI DSS 7.2.4 (at least every six months); 7.2.5.1 and 12.3.1 (targeted risk analysis) required
    • NYDFS Part 500 500.7(a)(4) (at a minimum annually) required
    • FFIEC II.C.15 (schedule commensurate with risk) required
    • GLBA Safeguards 314.4(c)(1) (periodically reviewing access controls) required
    • HITRUST 01.e required
    • NIST 800-53 / CSF AC-2(j) (organization-defined frequency) required
    • OSFI B-13 3.2.7 (regular attestation of access) required
    • ISO 27001 A.5.18 (at regular intervals) required

Area 2 of 11

Population

Proving the list you reviewed was the whole list.

  1. P1 How do you know the user listing you reviewed was complete and accurate? frequent finding

    Status for P1
    Why it is asked, what closes it, and the clauses
    What they are testing
    Information produced by the entity. If the report is wrong, the review is worthless however carefully it was done — and untested populations for access controls are a deficiency PCAOB inspection reports keep repeating.
    Evidence that closes it
    For each extract: the report or query and its parameters, who ran it, when, a screenshot of the run, and the record count reconciled to an independent count taken in the system.
    The finding if not
    No evidence that the population was complete. The review is treated as not performed.
    • SOX / ICFR AS 1105.10 (test the accuracy and completeness of information produced by the company) required
    • SOC 2 CC6.1; the service auditor tests the listing under AT-C 205 required
    • PCI DSS 7.2.4 (all user accounts) supporting
    • HITRUST 01.e supporting
    • NIST 800-53 / CSF AC-2(j) supporting
    • NI 52-109 via COSO 2013 Principle 11 (general controls over technology) supporting
    • ISO 27001 A.5.18 supporting

  2. P2 When was the extract taken, relative to when the review ran?

    Status for P2
    Why it is asked, what closes it, and the clauses
    What they are testing
    Staleness. Accounts created between extract and review are unreviewed; a weeks-old extract makes 'current' a fiction.
    Evidence that closes it
    Extract timestamp and review window on the campaign record, with a stated maximum gap.
    The finding if not
    Extract taken weeks before reviewers opened it; joiners in the gap never reviewed.
    • SOX / ICFR AS 1105.10 required
    • SOC 2 CC6.2 supporting
    • PCI DSS 7.2.4 supporting
    • ISO 27001 A.5.18 supporting

  3. P3 Could anyone have edited the listing between the system and the reviewer?

    Status for P3
    Why it is asked, what closes it, and the clauses
    What they are testing
    Integrity of the evidence chain. A spreadsheet that passed through an administrator's hands can have rows removed.
    Evidence that closes it
    Extract produced by the system or IGA tool and delivered read-only, or a hash or record count re-checked at review time.
    The finding if not
    The listing was manipulated before review by someone whose own access was on it.
    • SOX / ICFR AS 1105.10 supporting
    • SOC 2 CC6.1 supporting
    • NIST 800-53 / CSF AU-9 (protection of audit information) supporting
    • ISO 27001 A.5.33 (protection of records) supporting

Area 3 of 11

Reviewers

Who decided, and why they were entitled to.

  1. R1 Can any reviewer approve their own access? frequent finding

    Status for R1
    Why it is asked, what closes it, and the clauses
    What they are testing
    Self-review. The auditor will search the decisions for rows where reviewer and account holder are the same person, and they usually find one.
    Evidence that closes it
    A rule in the tool or template that routes self-owned lines to the reviewer's manager, and a report showing zero self-certified lines.
    The finding if not
    Administrators certifying their own administrative rights.
    • SOX / ICFR AS 2201 — segregation of duties within the control; COSO 2013 Principle 10 required
    • SOC 2 CC6.3 (segregation of duties) required
    • FFIEC II.C.15 (privileged access reviewed by an independent party) required
    • HITRUST 09.c (segregation of duties) required
    • NIST 800-53 / CSF AC-5 (separation of duties) required
    • NI 52-109 via COSO 2013 Principle 10 supporting
    • OSFI B-13 2.5.2 (segregation of duties) supporting
    • ISO 27001 A.5.3 (segregation of duties) required

  2. R2 Why is this person qualified to decide on this access?

    Status for R2
    Why it is asked, what closes it, and the clauses
    What they are testing
    Competence. A line manager can say whether someone still works for them; they usually cannot say whether a database role is appropriate.
    Evidence that closes it
    A reviewer model that pairs the manager (is the person still in role?) with the application or data owner (is this entitlement appropriate?) for sensitive entitlements.
    The finding if not
    Managers approving technical entitlements they could not interpret, so every line was kept.
    • SOX / ICFR COSO 2013 Principle 12 (policies and procedures, performed timely, corrective action) — performed by competent personnel supporting
    • SOC 2 CC6.3 supporting
    • FFIEC II.C.15 (manager and application or data owners authorize access) required
    • HITRUST 01.e supporting
    • NIST 800-53 / CSF AC-2(b) (assign account managers) required
    • ISO 27001 A.5.18 supporting

  3. R3 When a review was reassigned or delegated, who approved that and why?

    Status for R3
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether delegation quietly moved decisions to someone less qualified, or back to the account holder.
    Evidence that closes it
    Delegation log with original reviewer, delegate, reason and date.
    The finding if not
    Reviews bulk-delegated to an administrator who then reviewed their own team's privileged access.
    • SOX / ICFR AS 2201 supporting
    • SOC 2 CC6.3 supporting
    • NIST 800-53 / CSF AC-5 supporting
    • ISO 27001 A.5.3 supporting

  4. R4 Who reviews the reviewers' own access?

    Status for R4
    Why it is asked, what closes it, and the clauses
    What they are testing
    Coverage at the top. Reviewers, administrators and the IAM team are the accounts most often left out.
    Evidence that closes it
    Reviewer and administrator access appearing as lines in the same campaign, assigned upward.
    The finding if not
    The IAM team's own privileged access outside every review.
    • SOC 2 CC6.3 supporting
    • FFIEC II.C.15 supporting
    • NIST 800-53 / CSF AC-6(7) supporting
    • ISO 27001 A.8.2 (privileged access rights) supporting

Area 4 of 11

What reviewers see

Whether a decision was even possible from the screen.

  1. C1 What did the reviewer actually see on the screen when they approved this?

    Status for C1
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether a decision was possible. 'APP_FIN_RW_07' approved 400 times is evidence of a click, not a review.
    Evidence that closes it
    A plain-language description per entitlement, visible at the point of decision.
    The finding if not
    Entitlements presented as raw technical names; reviewers could not tell a read role from an approval role.
    • SOX / ICFR PCAOB Staff Audit Practice Alert No. 11 (precision of review controls) required
    • SOC 2 CC6.3 supporting
    • HITRUST 01.e supporting
    • NIST 800-53 / CSF AC-6(7) supporting
    • ISO 27001 A.5.18 supporting

  2. C2 Did the reviewer know whether this access had been used?

    Status for C2
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether the easiest revocations were visible. Unused access is the lowest-risk removal and the one reviewers keep by default when they cannot see usage.
    Evidence that closes it
    Last-used or last-login date on each line, and a flag past a stated dormancy threshold.
    The finding if not
    Accounts dormant for a year approved as appropriate.
    • SOC 2 CC6.2 supporting
    • PCI DSS 8.2.6 (inactive accounts removed or disabled within 90 days) supporting
    • NIST 800-53 / CSF AC-2(3) (disable inactive accounts) supporting
    • ISO 27001 A.5.18 supporting

  3. C3 Were movers flagged, so the reviewer knew the person had changed role?

    Status for C3
    Why it is asked, what closes it, and the clauses
    What they are testing
    Mover accumulation, the least-controlled part of the lifecycle. Without a flag the reviewer sees a current employee and approves.
    Evidence that closes it
    HR job-change date on each line, and old-role entitlements highlighted for anyone who moved during the period.
    The finding if not
    Transferred staff retaining the previous role's access, approved because they were still employed.
    • SOC 2 CC6.2 supporting
    • FFIEC II.C.15 (promptly review access for users with job changes) required
    • HIPAA 164.308(a)(4)(ii)(C) (modify a user's right of access) supporting
    • NIST 800-53 / CSF PS-5 (personnel transfer) required
    • ISO 27001 A.5.18 supporting

  4. C4 Did the review show segregation-of-duties conflicts?

    Status for C4
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether a toxic combination could be approved one entitlement at a time, by two reviewers who each saw half of it.
    Evidence that closes it
    A conflict matrix, and conflicting pairs shown together on the line with the conflict named.
    The finding if not
    A user holding both payment initiation and approval, each approved separately.
    • SOX / ICFR COSO 2013 Principle 10 (segregation of duties) required
    • SOC 2 CC6.3 (segregation of duties) required
    • HITRUST 09.c required
    • NIST 800-53 / CSF AC-5 required
    • NI 52-109 via COSO 2013 Principle 10 supporting
    • OSFI B-13 2.5.2 supporting
    • ISO 27001 A.5.3 required

Area 5 of 11

Decisions

Whether anything was actually reviewed.

  1. D1 How many lines did each reviewer revoke, and how long did they spend? frequent finding

    Status for D1
    Why it is asked, what closes it, and the clauses
    What they are testing
    Rubber-stamping. A 100 percent approval rate on hundreds of lines, completed in minutes, tells the auditor no review occurred.
    Evidence that closes it
    Per-reviewer counts of lines, revocations and time to complete, with outliers followed up.
    The finding if not
    Bulk approval with no evidence of consideration. The control is judged not to operate at the level of precision claimed.
    • SOX / ICFR AS 2201; PCAOB Staff Audit Practice Alert No. 11 (precision of review controls) required
    • SOC 2 CC6.3 supporting
    • PCI DSS 7.2.4 (management acknowledges access remains appropriate) required
    • HITRUST 01.e supporting
    • NI 52-109 via COSO 2013 Principle 12 (policies and procedures, performed timely, corrective action) supporting
    • ISO 27001 A.5.18 supporting

  2. D2 Where a reviewer kept privileged or flagged access, where is the reason?

    Status for D2
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether retention of risky access was a decision or a default.
    Evidence that closes it
    A mandatory rationale field for keep decisions on privileged, dormant or conflicting lines.
    The finding if not
    Privileged access retained with no documented justification.
    • SOC 2 CC6.3 supporting
    • PCI DSS 7.2.3 (required privileges approved by authorized personnel) supporting
    • FFIEC II.C.15 (document the granting and extent of privileged access) supporting
    • NIST 800-53 / CSF AC-6(5) supporting
    • ISO 27001 A.8.2 supporting

  3. D3 Which access did you knowingly keep that breaks policy, and until when?

    Status for D3
    Why it is asked, what closes it, and the clauses
    What they are testing
    Exceptions. An exception with no owner and no expiry is a permanent control failure with paperwork.
    Evidence that closes it
    An exception register with approver, compensating control and expiry date, re-reviewed at expiry.
    The finding if not
    Open-ended exceptions renewed by nobody, including ones for people who have left.
    • SOX / ICFR COSO 2013 Principle 12 (policies and procedures, performed timely, corrective action) supporting
    • SOC 2 CC6.3 supporting
    • PCI DSS 12.3.1 (targeted risk analysis where flexibility is used) required
    • HIPAA 164.306(d)(3) (document why an addressable specification is not reasonable and appropriate) required
    • ISO 27001 A.5.18 supporting

Area 6 of 11

Remediation

Whether a revoke decision removed anything.

  1. M1 For this revoke decision, show me that the access is gone. frequent finding

    Status for M1
    Why it is asked, what closes it, and the clauses
    What they are testing
    Closed loop. A closed ticket is not evidence; the auditor wants the system itself to show the entitlement absent.
    Evidence that closes it
    Per revocation: ticket, removal timestamp and a re-extract or screenshot from the target system confirming removal.
    The finding if not
    Access marked for removal still present at year end. The review happened; the control did not.
    • SOX / ICFR COSO 2013 Principle 12 (policies and procedures, performed timely, corrective action) — takes corrective action required
    • SOC 2 CC6.2 (removes access when appropriate) required
    • PCI DSS 7.2.4 (any inappropriate access is addressed) required
    • NYDFS Part 500 500.7(a)(4) (remove or disable accounts and access no longer necessary) required
    • HIPAA 164.308(a)(4)(ii)(C) required
    • HITRUST 01.e required
    • NIST 800-53 / CSF AC-2(j) required
    • NI 52-109 via COSO 2013 Principle 12 (policies and procedures, performed timely, corrective action) supporting
    • Québec Law 25 s. 10 (security measures reasonable given sensitivity) supporting
    • ISO 27001 A.5.18 required

  2. M2 How long after the decision was the access actually removed?

    Status for M2
    Why it is asked, what closes it, and the clauses
    What they are testing
    Timeliness against a stated standard, measured by the tail rather than the average.
    Evidence that closes it
    A remediation SLA in the procedure, and decision-to-removal elapsed time per revocation.
    The finding if not
    Revocations completed months after sign-off, outside any stated SLA.
    • SOX / ICFR COSO 2013 Principle 12 (policies and procedures, performed timely, corrective action) — performs in a timely manner required
    • SOC 2 CC6.2 supporting
    • PCI DSS 7.2.4 supporting
    • ISO 27001 A.5.18 supporting

  3. M3 Did anyone use the access between the decision and its removal — or before the review found it?

    Status for M3
    Why it is asked, what closes it, and the clauses
    What they are testing
    Consequence. For a financial system, inappropriate access that was exercised can reach the financial statements.
    Evidence that closes it
    Activity logs for revoked entitlements covering the exposure window, reviewed, and the conclusion recorded.
    The finding if not
    Inappropriate access found and removed with no look-back at what it was used for.
    • SOX / ICFR AS 2201 — evaluating the severity of a control deficiency supporting
    • SOC 2 CC7.2 (monitors system components for anomalies) supporting
    • GLBA Safeguards 314.4(c)(8) (monitor and log activity of authorized users) required
    • HIPAA 164.308(a)(1)(ii)(D) (information system activity review) required
    • NIST 800-53 / CSF AU-6 (audit record review) required
    • OSFI B-13 3.3.1 (centralized logging to support investigations) supporting
    • Ontario PHIPA s. 12(1) (reasonable steps against unauthorized use) supporting

Area 7 of 11

Privileged access

The accounts every framework reviews hardest.

  1. V1 Is privileged access reviewed more often, and by someone other than the administrators?

    Status for V1
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether the highest-risk population gets more scrutiny than the rest, and whether the reviewer is independent of it.
    Evidence that closes it
    A privileged-access review at a shorter cadence than the general review, performed by a party independent of the administrators.
    The finding if not
    Domain and cloud administrator rights reviewed annually, by the infrastructure lead who holds them.
    • SOC 2 CC6.1, CC6.3 supporting
    • PCI DSS 7.2.4 supporting
    • NYDFS Part 500 500.7(a)(2)–(3) (limit privileged accounts and their use); 500.7(c) (Class A: monitor privileged access, PAM solution) required
    • FFIEC II.C.15 (review, by an independent party, privileged access rights and allocations) required
    • HITRUST 01.c (privilege management) required
    • NIST 800-53 / CSF AC-6(7), AC-2(7) (privileged user accounts) required
    • OSFI B-13 3.2.7 (privileged access management) required
    • ISO 27001 A.8.2 (privileged access rights) required

  2. V2 Do administrators use a separate account for privileged work?

    Status for V2
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether a phished everyday session is also an administrative one.
    Evidence that closes it
    A register of privileged accounts showing each is distinct from the holder's daily account, with no mailbox or browsing on the privileged one.
    The finding if not
    Global administrator rights on the same account used for email.
    • NYDFS Part 500 500.7(a)(3) (use privileged accounts only when performing functions requiring them) required
    • FFIEC II.C.15 (privileges assigned to a unique user ID apart from normal business use) required
    • HITRUST 01.c supporting
    • NIST 800-53 / CSF AC-6(2) (non-privileged access for nonsecurity functions) required
    • OSFI B-13 3.2.7 supporting
    • ISO 27001 A.8.2 supporting

  3. V3 Show me the emergency accounts, who can use them, and every time they were used.

    Status for V3
    Why it is asked, what closes it, and the clauses
    What they are testing
    Break-glass accounts are privileged, rarely used and rarely reviewed. The auditor checks that each use was expected and investigated.
    Evidence that closes it
    Emergency account register, access to the credential restricted and logged, each use reconciled to an incident, and a dated test.
    The finding if not
    Break-glass accounts with unknown custodians, used without any record of why.
    • SOC 2 CC6.1 supporting
    • FFIEC II.C.15 (logging and independent monitoring of privileged access) required
    • HIPAA 164.312(a)(2)(i)–(ii) (unique user identification; emergency access procedure, both required) required
    • NIST 800-53 / CSF AC-2(2) (automated temporary and emergency account management) supporting
    • OSFI B-13 3.2.7 (privileged credentials in a secure vault) supporting
    • ISO 27001 A.8.2 supporting

  4. V4 Are default and built-in accounts disabled, renamed or monitored?

    Status for V4
    Why it is asked, what closes it, and the clauses
    What they are testing
    Vendor defaults with published credentials are privileged accounts nobody requested.
    Evidence that closes it
    Per in-scope system, the list of default accounts and whether each is disabled, rotated or monitored.
    The finding if not
    An enabled vendor default administrator on a production database.
    • SOC 2 CC6.1 supporting
    • PCI DSS 2.2.2 (vendor default accounts managed) required
    • FFIEC II.C.15 (default accounts changed, disabled or closely monitored) required
    • NIST 800-53 / CSF CM-6 (configuration settings) supporting

Area 8 of 11

Non-human accounts

Service accounts, keys and integrations.

  1. N1 Who owns this service account, and what is it for? frequent finding

    Status for N1
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether machine identities are in the review at all. Most template reviews cover people only, so service accounts with standing administrative rights go years unexamined.
    Evidence that closes it
    Every service account, API key and integration credential in scope with a named human owner and a stated purpose, and each reviewed at the cadence your risk analysis sets.
    The finding if not
    Service accounts excluded from the review, or included with no owner who could make a decision.
    • SOX / ICFR AS 2201 — access to programs and data supporting
    • SOC 2 CC6.1, CC6.2 supporting
    • PCI DSS 7.2.5 (least privilege for application and system accounts); 7.2.5.1 (periodic review per targeted risk analysis) required
    • HIPAA 164.312(a)(1) (access for persons or software programs granted access rights) required
    • HITRUST 01.b supporting
    • NIST 800-53 / CSF AC-2(a), IA-9 (service identification and authentication) supporting
    • OSFI B-13 3.2.7 (system and service accounts securely authenticated, managed and monitored) required
    • ISO 27001 A.5.16 supporting

  2. N2 Can anyone log in interactively as this service account?

    Status for N2
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether a shared credential is also a human back door with no attributable user.
    Evidence that closes it
    Interactive sign-in disabled for service accounts, or each exception justified, approved, time-bound and attributable to a person.
    The finding if not
    Engineers signing in as a service account because it had the rights they needed.
    • SOC 2 CC6.1 supporting
    • PCI DSS 8.6.1 (interactive use of system accounts only by exception, attributable) required
    • NIST 800-53 / CSF AC-2(9) (restrictions on use of shared and group accounts) supporting
    • ISO 27001 A.5.16 supporting

  3. N3 When were this account's credentials last rotated?

    Status for N3
    Why it is asked, what closes it, and the clauses
    What they are testing
    Credential age. A key older than everyone who has left the team is a leaver risk nobody can revoke.
    Evidence that closes it
    Credential age per service account against a rotation standard, with secrets held in a vault rather than in code or config.
    The finding if not
    Hard-coded credentials unchanged since creation, known to former staff.
    • SOC 2 CC6.1 supporting
    • PCI DSS 8.6.3 (application and system account passwords changed periodically per risk analysis) required
    • NIST 800-53 / CSF IA-5 (authenticator management) required
    • OSFI B-13 3.2.7 supporting
    • ISO 27001 A.5.17 (authentication information) supporting

Area 9 of 11

Third parties

Vendors, contractors and service providers.

  1. T1 For each vendor or contractor account, what contract, sponsor and end date is it tied to?

    Status for T1
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether external access outlives the relationship. Vendor accounts are created by someone who is not the vendor's manager and removed by no one.
    Evidence that closes it
    External identities mapped to a contract, an internal sponsor and an expiry date, with expired ones disabled automatically.
    The finding if not
    Contractor accounts active months after the engagement ended.
    • SOC 2 CC9.2 (vendor and business partner risk) required
    • PCI DSS 7.2.4 (including third-party/vendor accounts) required
    • NYDFS Part 500 500.11 (third-party service provider security policy) required
    • GLBA Safeguards 314.4(f) (oversee service providers) required
    • HIPAA 164.308(b)(1) (business associate arrangements) required
    • HITRUST 05.i (identification of risks related to external parties) required
    • NIST 800-53 / CSF PS-7 (external personnel security) required
    • OSFI B-13 B-10 (third-party risk management); B-13 3.2.7 (third-party access) required
    • PIPEDA Principle 4.1.3 (accountability for information transferred to third parties) required
    • ISO 27001 A.5.19, A.5.20 (supplier relationships and agreements) required

  2. T2 Is vendor remote access switched on only when it is needed?

    Status for T2
    Why it is asked, what closes it, and the clauses
    What they are testing
    Standing vendor access. An always-on support account is an always-on entry point.
    Evidence that closes it
    Vendor remote access enabled per request, disabled after, and monitored while in use.
    The finding if not
    A vendor support account permanently enabled with no record of when it was used.
    • PCI DSS 8.2.7 (third-party remote access enabled only when needed, monitored) required
    • NYDFS Part 500 500.12 (MFA for remote access) supporting
    • FFIEC II.C.15(c) (remote access) supporting
    • NIST 800-53 / CSF AC-17 (remote access) supporting
    • OSFI B-13 3.2.7 supporting
    • ISO 27001 A.5.20 supporting

  3. T3 For systems a provider runs for you, which access controls are theirs and which are yours?

    Status for T3
    Why it is asked, what closes it, and the clauses
    What they are testing
    Complementary user entity controls. A provider's SOC report assumes you review your own users on their platform; auditors check that you do.
    Evidence that closes it
    For each relevant SOC 1 or SOC 2 report, the CUECs on access mapped to the control you operate for each.
    The finding if not
    A SaaS provider's clean report relied on, while the customer-side access review it assumed was never performed.
    • SOX / ICFR AS 2601 (consideration of an entity's use of a service organization) required
    • SOC 2 CC9.2 supporting
    • NYDFS Part 500 500.11 supporting
    • GLBA Safeguards 314.4(f) supporting
    • OSFI B-13 B-10 supporting
    • ISO 27001 A.5.22 (monitoring of supplier services) supporting

Area 10 of 11

Between reviews

Leavers, movers and dormancy — what the review should never be the first to catch.

  1. L1 For this sample of leavers, show me the termination date and when each account was disabled. frequent finding

    Status for L1
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether the review is the first control to find a leaver. If it is, the leaver control has already failed.
    Evidence that closes it
    For each sampled leaver, HR termination timestamp against disable timestamp in every in-scope system, including those outside SSO.
    The finding if not
    Terminated users with active accounts, some used after departure.
    • SOX / ICFR AS 2201 — access to programs and data required
    • SOC 2 CC6.2 (removes access when no longer authorized) required
    • PCI DSS 8.2.5 (access for terminated users immediately revoked) required
    • NYDFS Part 500 500.7(a)(6) (promptly terminate access following departures) required
    • FFIEC II.C.15 required
    • HIPAA 164.308(a)(3)(ii)(C) (termination procedures, addressable) required
    • HITRUST 02.i (removal of access rights) required
    • NIST 800-53 / CSF PS-4 (personnel termination), AC-2(h) required
    • NI 52-109 via COSO 2013 Principle 11 (general controls over technology) supporting
    • ISO 27001 A.5.18, A.6.5 (responsibilities after termination) required

  2. L2 When someone changes role, what happens to the old role's access?

    Status for L2
    Why it is asked, what closes it, and the clauses
    What they are testing
    Mover control. Most joiner and leaver processes are automated; movers usually keep everything.
    Evidence that closes it
    Transfers triggering a re-certification or removal of prior-role entitlements, with a sample traced.
    The finding if not
    Access accumulated across three roles, none of it removed.
    • SOC 2 CC6.2 supporting
    • FFIEC II.C.15 (promptly review and modify access on job change) required
    • HIPAA 164.308(a)(4)(ii)(C) supporting
    • NIST 800-53 / CSF PS-5 (personnel transfer), AC-2(h) required
    • PIPEDA Principle 4.7.3(b) (need-to-know access) supporting
    • Québec Law 25 s. 20 (access only to information needed for duties) supporting
    • ISO 27001 A.5.18 supporting

  3. L3 What happens to an account nobody has used for 90 days?

    Status for L3
    Why it is asked, what closes it, and the clauses
    What they are testing
    Dormancy. Unused accounts are attack surface with no one watching.
    Evidence that closes it
    An automated disable at a stated inactivity threshold, and a report of accounts past it.
    The finding if not
    Hundreds of accounts inactive for more than a year and still enabled.
    • SOC 2 CC6.2 supporting
    • PCI DSS 8.2.6 (inactive accounts removed or disabled within 90 days) required
    • NIST 800-53 / CSF AC-2(3) (disable accounts) required
    • ISO 27001 A.5.18 supporting

  4. L4 How was this access granted in the first place?

    Status for L4
    Why it is asked, what closes it, and the clauses
    What they are testing
    Provisioning. If the request and approval cannot be shown, the review is certifying access nobody authorized.
    Evidence that closes it
    For a sample of grants, the request, the approver and the provisioning record.
    The finding if not
    Access with no request or approval on record.
    • SOX / ICFR AS 2201 — access to programs and data required
    • SOC 2 CC6.2 (registers and authorizes new users) required
    • PCI DSS 7.2.3 (privileges approved); 8.2.4 (additions and modifications authorized) required
    • HIPAA 164.308(a)(4)(ii)(B) (access authorization) required
    • HITRUST 01.b required
    • NIST 800-53 / CSF AC-2(e) (approvals for account creation) required
    • ISO 27001 A.5.18 supporting

Area 11 of 11

Governance and evidence

Whether the control exists on paper and in the file.

  1. G1 Show me the written procedure this review follows.

    Status for G1
    Why it is asked, what closes it, and the clauses
    What they are testing
    Design. Auditors test the control you described; without a description there is nothing to test against.
    Evidence that closes it
    A procedure stating scope, cadence per tier, reviewer model, decision options, remediation SLA, exception handling and evidence retained.
    The finding if not
    Reviews performed, but inconsistently, because nothing defines them.
    • SOX / ICFR COSO 2013 Principle 12 (policies and procedures, performed timely, corrective action) required
    • SOC 2 CC5.3 (policies and procedures) required
    • NYDFS Part 500 500.3 (cybersecurity policy: access controls) required
    • GLBA Safeguards 314.4(c)(1) supporting
    • HIPAA 164.316(a) (policies and procedures) required
    • NIST 800-53 / CSF AC-1 (policy and procedures) required
    • NI 52-109 s. 3.4 (control framework used to design ICFR) required
    • Québec Law 25 s. 3.2 (governance policies) required
    • Ontario PHIPA s. 10(1) (information practices) required
    • ISO 27001 A.5.15 (access control policy) required

  2. G2 Who signed off that the review was complete, and when?

    Status for G2
    Why it is asked, what closes it, and the clauses
    What they are testing
    Accountability. The sign-off is the operating evidence the auditor samples.
    Evidence that closes it
    A dated sign-off by each reviewer and by the control owner, recorded in the system or template.
    The finding if not
    Reviews with no evidence of completion, or signed off before remediation finished.
    • SOX / ICFR COSO 2013 Principle 12 (policies and procedures, performed timely, corrective action) supporting
    • SOC 2 CC6.3 supporting
    • PCI DSS 7.2.4 (management acknowledges access remains appropriate) required
    • HITRUST 01.e supporting
    • ISO 27001 A.5.18 supporting

  3. G3 Can you produce every review from the period, as it was at the time?

    Status for G3
    Why it is asked, what closes it, and the clauses
    What they are testing
    Retention and integrity. Evidence rebuilt after the fact is not evidence.
    Evidence that closes it
    Each cycle's population, decisions, remediation and sign-off retained unaltered for the required period and retrievable on request.
    The finding if not
    A quarter's review missing, or overwritten by the next cycle's spreadsheet.
    • SOX / ICFR AS 2201 — evidence of operating effectiveness supporting
    • SOC 2 CC6.3 (every occurrence in the period) required
    • NYDFS Part 500 500.17(b) (maintain supporting records five years) required
    • HIPAA 164.316(b)(2)(i) (retain documentation six years) required
    • NIST 800-53 / CSF AU-11 (audit record retention) supporting
    • ISO 27001 Clause 7.5 (documented information) required

  4. G4 Did every scheduled review actually happen, on time?

    Status for G4
    Why it is asked, what closes it, and the clauses
    What they are testing
    Operating effectiveness over the period. One missed or late cycle is an exception in a Type 2 report and a deficiency in an ICFR audit.
    Evidence that closes it
    A cycle log of planned against completed dates for every system.
    The finding if not
    A cycle skipped during a system migration, discovered by the auditor.
    • SOX / ICFR AS 2201 — operating effectiveness throughout the period required
    • SOC 2 CC4.1 (ongoing and separate evaluations) required
    • PCI DSS 7.2.4 (at least once every six months) required
    • NYDFS Part 500 500.7(a)(4) (at a minimum annually) required
    • HITRUST 01.e supporting
    • NI 52-109 via COSO 2013 Principle 12 (policies and procedures, performed timely, corrective action) supporting
    • ISO 27001 A.5.18 supporting

  5. G5 What did the last review find, and who above the control owner saw it?

    Status for G5
    Why it is asked, what closes it, and the clauses
    What they are testing
    Whether findings are escalated and trended, or absorbed.
    Evidence that closes it
    Review results — revocation counts, exceptions, repeat findings — reported to management with actions tracked.
    The finding if not
    The same inappropriate access found and 'removed' in consecutive cycles.
    • SOX / ICFR COSO 2013 Principle 17 (evaluates and communicates deficiencies) required
    • SOC 2 CC4.2 (communicates deficiencies) required
    • NYDFS Part 500 500.4 (CISO reporting to the senior governing body) required
    • HIPAA 164.308(a)(8) (evaluation) supporting
    • OSFI B-13 3.1.8 (cyber risk profile monitored and reported) required
    • PIPEDA Principle 4.7 supporting
    • Ontario PHIPA s. 12(1) supporting
    • ISO 27001 Clause 9.3 (management review) required

Answers and notes stay in this browser. Nothing is transmitted. “Required” means the framework’s own clause asks for it; “good practice” means it supports a broader clause without naming it.

How often are access reviews required, and how long is evidence kept?

Only 3 of these 15 instruments put a number on the review interval: PCI DSS, NYDFS Part 500 and HITRUST. Everywhere else the interval is yours to set — and once your procedure names one, that is the interval you are tested against. Blog posts that quote a quarterly requirement for OSFI or HIPAA are quoting somebody’s policy, not the instrument.

All 15 frameworks.

SOX / ICFR

United States · Risk-based

Sarbanes-Oxley Section 404, audited under PCAOB AS 2201. AS 2201 and AS 1105 as in force; COSO Internal Control – Integrated Framework (2013).

Interval.
Not set. Auditors test whatever cadence your control description states, so the control description is the commitment. Quarterly is common for financially significant systems.
Retention.
No SOX rule sets how long the company keeps review evidence. The often-quoted seven years is Regulation S-X Rule 2-06, which binds the auditor's workpapers. Seven years is a reasonable policy, but it is your policy.
Primary source

SOC 2

United States · Risk-based

AICPA Trust Services Criteria (Common Criteria CC6). 2017 criteria with revised points of focus (2022).

Interval.
Not set. A Type 2 practitioner establishes the complete population of occurrences and samples from it, so an occurrence that never happened is an exception whether or not it lands in the sample.
Retention.
Evidence for every occurrence inside the report period, retrievable for the examination.

PCI DSS

United States · Sets an interval

Payment Card Industry Data Security Standard. v4.0.1 (June 2024); future-dated requirements mandatory since 31 March 2025.

Interval.
User accounts: at least once every six months (7.2.4). Application and system accounts: at the frequency your targeted risk analysis sets (7.2.5.1, 12.3.1).
Retention.
No period set for review records; the assessor asks for every review in the assessment period. Audit log history: 12 months, the latest three immediately available (10.5.1).
Primary source

NYDFS Part 500

United States · Sets an interval

23 NYCRR Part 500, Cybersecurity Requirements for Financial Services Companies. Second Amendment (November 2023); final tranche in force 1 November 2025.

Interval.
All user access privileges: periodically, but at a minimum annually (500.7(a)(4)).
Retention.
Records supporting the annual compliance certification: five years (500.17(b)).
Primary source

FFIEC

United States · Risk-based

FFIEC IT Examination Handbook, Information Security booklet. Section II.C.15 Logical Security, as published in the InfoBase.

Interval.
On a schedule commensurate with risk (II.C.15). Privileged access reviewed by an independent party at appropriate intervals.
Retention.
Not set by the handbook. Examiners expect evidence back to the previous examination.
Primary source

GLBA Safeguards

United States · Risk-based

FTC Standards for Safeguarding Customer Information, 16 CFR Part 314. As amended December 2021; in force 9 June 2023.

Interval.
Access controls must be periodically reviewed (314.4(c)(1)). No interval set.
Retention.
Not set by the rule.
Primary source

HIPAA

United States · Risk-based

HIPAA Security Rule, 45 CFR Part 164 Subpart C. Rule in force. The January 2025 proposed update is not final.

Interval.
Not set. Access review sits under access establishment and modification, which is addressable (164.308(a)(4)(ii)(C)). Activity review is required and must be regular (164.308(a)(1)(ii)(D)).
Retention.
Six years from creation or last effective date (164.316(b)(2)(i)). This one is required.
Primary source

HITRUST

United States · Sets an interval (licensed)

HITRUST CSF. v11.x.

Interval.
Set in the requirement statements for your assessment type. The CSF text is licensed, so confirm the interval in MyCSF rather than from a secondary source.
Retention.
Set by the assessment's evidence requirements.
Primary source

NIST 800-53 / CSF

United States · Risk-based

NIST SP 800-53 Rev. 5 and the Cybersecurity Framework 2.0. SP 800-53 Rev. 5 (release 5.1.1); CSF 2.0 (February 2024).

Interval.
Organization-defined (AC-2(j), AC-6(7)). You set the number, then you are held to it.
Retention.
Organization-defined.
Primary source

NI 52-109

Canada · Risk-based

National Instrument 52-109, Certification of Disclosure in Issuers' Annual and Interim Filings. As consolidated; read on the OSC site.

Interval.
Not set. Most issuers design ICFR on COSO 2013, so IT general controls are tested much as they are under SOX.
Retention.
Not set by the instrument.
Primary source

OSFI B-13

Canada · Risk-based

OSFI Guideline B-13, Technology and Cyber Risk Management. Final July 2022; in force 1 January 2024. Third parties under B-10, in force 1 May 2024.

Interval.
"Regular attestation of access" (3.2.7). No interval set. Claims that B-13 requires quarterly privileged reviews are not in the guideline.
Retention.
Not set by the guideline.
Primary source

PIPEDA

Canada · Risk-based

Personal Information Protection and Electronic Documents Act, Schedule 1. In force; breach reporting since 1 November 2018.

Interval.
Not set. Principle 4.7 requires safeguards proportionate to sensitivity, including need-to-know access (4.7.3(b)).
Retention.
Not set for access reviews.
Primary source

Québec Law 25

Canada · Risk-based

Act respecting the protection of personal information in the private sector (as amended by Law 25). Amended in three tranches, September 2022 to September 2024.

Interval.
Not set. Section 20 limits staff access to information needed for their duties, which is an access review's premise written into statute.
Retention.
Not set for access reviews.
Primary source

Ontario PHIPA

Canada · Risk-based

Personal Health Information Protection Act, 2004 (Ontario). As amended. Section 10.1 (electronic audit log) is enacted but not yet proclaimed in force.

Interval.
Not set. Section 12(1) requires reasonable steps against unauthorized use; the IPC has repeatedly found snooping where access was never reviewed.
Retention.
Not set for access reviews.
Primary source

ISO 27001

International · Risk-based

ISO/IEC 27001:2022, Annex A. 2022 edition, with Amendment 1 (2024).

Interval.
At regular intervals (A.5.18), which the certification auditor holds you to once your policy names one.
Retention.
As your documented-information controls set (clause 7.5).
Primary source

Clause-level

Every mapping names the clause, not the framework. “HIPAA” is not a reference; 164.308(a)(4)(ii)(C) is.

Checked at source

Each clause was read against the primary text in Sep '26. HITRUST’s requirement statements are licensed, so we point you to MyCSF instead of quoting a number we cannot show you.

Not an attestation

This is not legal advice and vaultIAM is not your auditor. It tells you what you will be asked, so the answer exists before fieldwork starts.

The review workbook · XLSX

Run the review itself

Most templates are a sign-off sheet. This one starts where reviews fail: it makes you prove the population before anyone reviews it, and flags the rest as you fill it in.

  1. 01 Start here. How to run it, the colour key, and what it is not.
  2. 02 Campaign. Dates, thresholds, frameworks in scope — and the numbers an auditor looks at first, computed.
  3. 03 Systems. What is in scope, why, who owns it, and when it is next due.
  4. 04 Population. The extract log: query, run time, row count reconciled to the system.
  5. 05 Review. One row per account per entitlement, with dormancy, self-review and missing-reason flags.
  6. 06 Remediation. Every revocation, verified in the system, timed against your SLA, with a look-back.
  7. 07 Exceptions. Access kept against policy, each with a compensating control and an expiry.
  8. 08 Sign-off. Per-reviewer counts, revocation rate and a rubber-stamp check.
  9. 09 Auditor questions. Every question, with a column per framework, and a status to mark.
  10. 10 Frequency & retention. What each instrument actually says about interval and evidence retention.
  11. 11 Sources. Where every claim was checked, and when.

Version 1.0 · clauses checked Sep '26

Download the workbook

XLSX · 376 KB · 11 sheets · no form, no email

The reasoning behind it: what auditors actually test in a user access review.

Get told when a clause changes

Regulations move by amendment. When one changes a clause in this template, we email the change and the updated file. Nothing else.

Work email only. Unsubscribe from any alert. Processed per our Privacy Policy.

Want a second pair of eyes before the auditor's?

A 30-minute Identity Risk Review walks your last access review against these questions and names the two or three an auditor would write up.

Book an Identity Risk Review