NIST SP 800-53 Rev 5: what it asks of an approval matrix
The separation of duties and least privilege controls, with account management, audit review and change control for the system lines of the matrix.
Quoted for every matrix.
Approval families anchored here
26NIST SP 800-53 Rev 5: every clause cited, quoted
8 of the 300 heldThe requirement text is our statement of each clause, read against the copy we hold and cited to it; it is not the instrument verbatim.
NIST SP 800-53 AC-2 Account managementRequires accounts to be managed across their full life cycle: permitted and prohibited account types defined, account managers assigned, membership prerequisites and approvals required, accounts created, modified, disabled and removed under documented criteria, usage monitored, and access reauthorized on a defined frequency.
Where matrices usually fall short: Shared and service accounts sit outside the joiner mover leaver process entirely; Recertification is signed off in bulk without any account actually being removed; Contractor and third party accounts outlive the engagement because no end date is held
Source: NIST SP 800-53 Rev 5
NIST SP 800-53 AC-3 Access enforcementRequires the system to technically enforce the access authorizations that policy has approved, so that logical access to information and system resources is permitted only where an approved authorization exists.
Where matrices usually fall short: Enforcement present in the application but absent at the database or storage layer beneath it; Entitlements accumulate through role changes so effective access exceeds what was approved; Emergency or break glass paths bypass enforcement without compensating logging
Source: NIST SP 800-53 Rev 5
NIST SP 800-53 AC-5 Separation of dutiesRequires the organization to identify and document the individual duties that must be kept apart to limit malevolent activity without collusion, and to define system access authorizations so that those duties cannot be exercised by one person.
Where matrices usually fall short: Conflicting duties named for finance processes only and never for system administration; Small teams create unavoidable conflicts that are tolerated rather than documented and compensated; Separation enforced at role definition but broken by direct entitlement grants
Source: NIST SP 800-53 Rev 5
NIST SP 800-53 AC-6 Least privilegeRequires access for users and for processes acting for them to be limited to what their assigned tasks actually need, so that no account, role or process holds privileges beyond the minimum required to do its job.
Where matrices usually fall short: Administrator rights granted as a default to speed up troubleshooting and never revoked; Service accounts run with far more privilege than the application needs; Least privilege applied to people while automation and pipeline identities are unrestricted
Source: NIST SP 800-53 Rev 5
NIST SP 800-53 AU-6 Audit record review, analysis, and reportingRequires audit records to be reviewed and analysed on a defined frequency for indications of organization-defined inappropriate or unusual activity and its likely impact, findings to be reported to defined personnel, and the depth of review to be increased when credible information changes the risk.
Where matrices usually fall short: Review is automated alerting only, with no periodic analytical review for slow patterns; Findings recorded but never reported to anyone able to act; No mechanism to raise review intensity when threat information changes
Source: NIST SP 800-53 Rev 5
NIST SP 800-53 CM-3 Configuration change controlRequires the types of change that fall under configuration control to be defined, proposed changes to be reviewed and approved or rejected with explicit consideration of security and privacy impact, decisions and implemented changes to be documented, change records to be retained for a defined period, and change activity to be monitored and reviewed by the responsible body.
Where matrices usually fall short: Emergency changes bypass approval and are never retrospectively documented; Impact analysis recorded as a tick box with no security reasoning behind it; Infrastructure as code changes merge without passing through the same change control
Source: NIST SP 800-53 Rev 5
NIST SP 800-53 CM-5 Access restrictions for changeRequires physical and logical access restrictions on who may make changes to the system to be defined, documented, approved and actually enforced, so that only authorized personnel can alter the system.
Where matrices usually fall short: Developers hold standing write access to production alongside the pipeline; Restrictions documented but not enforced, so the pipeline can be bypassed manually; Physical access to equipment rooms not treated as a change path
Source: NIST SP 800-53 Rev 5
NIST SP 800-53 PS-5 Personnel transferRequires that when individuals are reassigned or transferred internally their existing logical and physical access is reviewed and confirmed as still needed, defined transfer actions are initiated within a defined period, authorizations are modified to match the new role, and defined personnel are notified within a defined period.
Where matrices usually fall short: Access accumulates across roles because transfer only ever adds entitlements; Transfer treated as a human resources event that never reaches system owners; Notification timeframes undefined, so changes lag the transfer by months
Source: NIST SP 800-53 Rev 5