Access reviews and the joiner-mover-leaver lifecycle

Access that was correct when granted drifts out of date as people change jobs, projects end, contractors leave and service accounts outlive their applications. Account lifecycle management keeps access aligned with reality as it happens. Periodic access reviews (also called certifications or attestations) catch what lifecycle automation missed. This page maps both to SP 800-53 Rev. 5 AC-2 and AC-6(7), then covers how reviews fail and what evidence to keep.

The account lifecycle: joiner, mover, leaver

Lifecycle events should drive most access changes. Reviews are the safety net, not the primary mechanism.

AC-2 is a long control. The parts that define the lifecycle:

AC-2 item	Requirement (paraphrased)	Lifecycle stage
AC-2 a, b, c	Define allowed and prohibited account types; assign account managers; set prerequisites for group and role membership.	Design
AC-2 d, e	Specify authorized users, memberships and privileges for each account; require approvals to create accounts.	Joiner
AC-2 f	Create, enable, modify, disable and remove accounts according to defined policy and criteria.	All
AC-2 g	Monitor the use of accounts.	All
AC-2 h	Notify account managers within defined periods when accounts are no longer needed, when users are terminated or transferred, and when need-to-know changes.	Mover, leaver
AC-2 j	Review accounts for compliance with account management requirements at a defined frequency.	Review
AC-2 k	Change shared or group account authenticators when individuals leave the group.	Leaver
AC-2 l	Align account management with personnel termination and transfer processes.	Mover, leaver

The AC-2 enhancements that matter for reviews

Enhancement	What it asks for
AC-2(1) Automated system account management	Support account management with automated mechanisms. The discussion includes creating and removing accounts, notifying managers, and reporting atypical usage.
AC-2(2) Automated temporary and emergency account management	Automatically remove or disable temporary and emergency accounts after a defined period.
AC-2(3) Disable accounts	Disable accounts within a defined period when they (a) have expired, (b) are no longer associated with a user or individual, (c) violate policy, or (d) have been inactive for a defined period.
AC-2(4) Automated audit actions	Automatically audit account creation, modification, enabling, disabling and removal.
AC-2(5) Inactivity logout	Require users to log out after a defined period of expected inactivity.
AC-2(7) Privileged user accounts	Administer privileged accounts under a role-based or attribute-based scheme; monitor privileged role or attribute assignments and changes to them; revoke access when no longer appropriate.
AC-2(9) Restrictions on use of shared and group accounts	Permit shared and group accounts only under defined conditions.
AC-2(11) Usage conditions	Enforce defined circumstances or usage conditions (for example, days, times, durations) for defined accounts.
AC-2(12) Account monitoring for atypical usage	Monitor accounts for defined atypical usage and report it to defined people.
AC-2(13) Disable accounts for high-risk individuals	Disable accounts within a defined period of discovering defined significant risks.

AC-2(10) was withdrawn and folded into AC-2 k. Alongside these, AC-6(7) asks you to review assigned privileges at a defined frequency "to validate the need for such privileges", then reassign or remove them. SP 800-53 sets no frequency for any of these. Every period is organization-defined.

Running a periodic access review

Scope. Choose systems and entitlements by risk: privileged roles, access to regulated data, financial approval rights, external users and service accounts first.
Snapshot. Export who has what, as of a date, from the system itself rather than from a spreadsheet someone maintains.
Assign reviewers. Managers know the person. Resource owners know the system. For privileged access, involve both.
Decide. Each entitlement is kept or removed, with a reason for every "keep" on privileged access.
Remediate. Removals are carried out, ideally automatically, and verified against a second snapshot.
Close. Record exceptions with an owner and an expiry date. Report completion and the removal rate.

Frequency is your decision. A common practice is quarterly for privileged and high-risk access and semi-annual or annual for the rest. Tie the cadence to how fast your organization changes, not to a number copied from elsewhere.

Rubber-stamping and how to prevent it

The most common failure is the reviewer who approves everything because the list is long, the entitlement names are cryptic and saying "keep" has no consequences. Signs: near-100% approval rates, reviews completed in seconds, identical decisions across hundreds of lines. Countermeasures that work (common practice):

Show usage. "Last used 14 months ago" changes decisions. So does "used daily".
Translate entitlements. "FIN_AP_APPROVER_L3" means nothing. "Can approve vendor payments up to the department limit" does.
Highlight outliers. Access held by this person but by few of their peers, and toxic combinations (see separation of duties).
Keep batches small and send them to the person who can actually judge them.
Require a reason for keeping privileged entitlements.
Audit the reviewers: sample decisions and follow up on obvious misses.

Some organizations remove access automatically when a reviewer does not respond. That forces engagement but can break production if the reviewer was simply away. If you use it, apply it to low-risk entitlements first and give a clear warning period.

Orphaned and dormant accounts

An orphaned account is one no longer tied to a current person or owner: a leaver's account the HR feed never reached, a local account on an appliance, a service account whose owner left. AC-2(3)(b) covers this ("no longer associated with a user or individual"), and AC-2(3)(d) covers dormant accounts. Find them by joining account lists from each system against the authoritative person and owner records:

Accounts whose user ID matches no current person or approved non-person entity.
Accounts with no sign-in for longer than your inactivity threshold.
Local accounts on systems that should only use central identity.
Service accounts with no recorded owner. See service accounts and secrets.

What evidence to keep

An auditor (or an incident responder) will want to reconstruct who had access, who decided it was appropriate, and whether removals happened. Keep:

Evidence	Why
Review definition: scope, reviewers, deadline, frequency	Shows the review was designed, not improvised (AC-2 j, AC-6(7)).
Population snapshot with timestamp and source system	Proves what was reviewed.
Each decision: reviewer, decision, reason, time	Accountability, and the raw material for spotting rubber-stamping.
Remediation tickets and a post-remediation snapshot	Proves removals happened, not just that they were requested.
Exceptions with owner and expiry	Shows accepted risk was deliberate and time-limited.
Account management audit records	AC-2(4) audit records for creation, modification, enabling, disabling and removal, retained under AU-11 for your defined period.

Checklist

An authoritative source (HR, contractor and vendor records) drives joiner, mover and leaver events (AC-2 l).
Transfers remove old access by default, not just add new access.
Leaver disablement happens within a defined period, and shared credentials the leaver knew are changed (AC-2 h, AC-2 k).
Inactive and orphaned accounts are disabled automatically after defined periods (AC-2(3)).
Privileged role assignments are monitored and reviewed more often than ordinary access (AC-2(7), AC-6(7)).
Reviews show usage data and plain-language entitlement descriptions.
Remediation is verified, and evidence is retained for your defined period.

Sources

NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, NIST. Public domain (U.S. government work).