NIST SP 800-53 Guide

NIST SP 800-53 is the most detailed public catalogue of security and privacy controls, and most teams use it badly: they copy a baseline, leave the parameters blank and call the result a programme. It underpins the US federal Risk Management Framework, FedRAMP, the CUI requirements in SP 800-171 and many private sector control sets. This guide explains the current release, the 20 control families, how a control is built, how the SP 800-53B baselines and tailoring work, how SP 800-53A assessments run and where OSCAL fits. It is written for security architects, GRC leads, control owners and assessors who need to apply the catalogue, not just cite it.

Key takeaways

• Rev. 5 is current, and the release number matters. As of 16 October 2026 the current release is SP 800-53 Release 5.2.0 (27 August 2025), which added SA-15(13), SA-24 and SI-2(7) and left the SP 800-53B baselines unchanged.
• The catalogue and the selection are separate documents. SP 800-53 holds the controls, SP 800-53B holds the low, moderate, high and privacy baselines, and SP 800-53A holds the assessment procedures.
• Parameters make a control yours. Organisation-defined parameters (ODPs), such as the AC-7 lockout threshold, must be assigned values or the control cannot be tested.
• Tailoring is expected, not a deviation. Scoping, compensating controls, overlays and supplementation fit a baseline to a system; record every decision in the security plan.
• Machine identities are in scope by name. AC-2 lists service accounts as an account type, IA-5 covers authenticators issued to services and devices, IA-9 requires services to authenticate, and IA-13 covers non-person entity identities.

What SP 800-53 is, and the current release

SP 800-53 Rev. 5 was published in September 2020, with updates as of 10 December 2020. Three design changes still define how it is used:

• Outcome-based statements: the responsible entity was removed from control text, so a control reads the same whoever delivers it.
• Integrated privacy: privacy controls sit in the main catalogue, including the PT family, instead of an appendix.
• Selection moved out: baselines were relocated to SP 800-53B, so the catalogue serves organisations outside the federal baselines.

Since Rev. 5, NIST has issued numbered releases through the SP 800-53 public comment site instead of new revisions. As of 16 October 2026, the current release is 5.2.0, finalised on 27 August 2025 after an expedited comment period that closed on 5 August 2025. It followed Executive Order 14306 and added guidance on deploying patches and updates securely:

• New: SA-15(13) Logging Syntax, SA-24 Design For Cyber Resiliency, SI-2(7) Root Cause Analysis.
• Revised: SI-7(12) Integrity Verification.
• Discussion and related-control updates: SA-4, SA-5, SA-8, SI-2, all "-1" policy controls, AU-2, AU-3, CA-7 and IR-4, among others.
• SP 800-53A gained matching assessment procedures; SP 800-53B baselines did not change.

Counted from NIST's official OSCAL catalogue for Release 5.2.0, the catalogue holds 300 active base controls and 714 active control enhancements, plus 24 base controls and 158 enhancements kept as withdrawn entries (for example SA-12 Supply Chain Protection, whose content moved to the SR family). NIST publishes the controls in the Cybersecurity and Privacy Reference Tool (CPRT), as spreadsheets and as OSCAL. OSCAL and CPRT use zero-padded labels (SI-02(07)) where the publication uses SI-2(7), so normalise IDs before joining datasets.

The 20 control families

Counts are active base controls and enhancements in Release 5.2.0. PM controls apply across the organisation, and none is allocated to the low, moderate or high baselines.

Several controls people search for by name sit outside every baseline and are chosen only when risk calls for them: SC-30 Concealment and Misdirection, SC-32 System Partitioning, SC-34 Non-modifiable Executable Programs, SC-35 External Malicious Code Identification, SI-13 Predictable Failure Prevention, SI-15 Information Output Filtering and PM-25 Minimization of Personally Identifiable Information Used in Testing, Training, and Research (privacy baseline only).

How a control is built

• Base control: the requirement statement, often with lettered items. IA-5 has nine, from verifying the identity of "the individual, group, role, service, or device receiving the authenticator" to changing authenticators for group accounts when membership changes.
• Control enhancements: numbered in brackets, for example IA-5(1) Password-based Authentication. NIST says enhancements "add functionality or specificity to a base control". An enhancement is never selected without its base.
• Discussion: explanatory text, not a requirement, telling implementers and assessors what was meant.
• Related controls: cross-references (IA-5 lists AC-3, AC-6, CM-6, IA-2, IA-9, SC-12 and SC-13, among others). Use them to find dependencies when scoping.
• Organisation-defined parameters: assignment and selection statements. AC-7 has an assignment for the number of consecutive invalid logon attempts and the time period, and a selection between locking the account or node for a set time, locking it until an administrator releases it, delaying the next logon prompt, notifying the administrator or another action. SP 800-53A labels these AC-07_ODP[01] onwards.

Common, hybrid and system-specific controls

Every selected control also has an implementation designation. A common control is provided once and inherited by many systems (an enterprise SIEM meeting AU-6, a data centre meeting PE-3). A hybrid control is partly inherited and partly system-specific, typically IA-2 where the enterprise identity provider supplies MFA but each application must enforce it. A system-specific control is owned by one system. Inheritance only works when the common control provider publishes its scope, assessment results and POA&M items.

Categorisation, baselines and selection

Selection starts with categorisation. FIPS 199 categorises information and systems by the potential impact of a loss of confidentiality, integrity or availability, at low, moderate or high. FIPS 200 sets minimum requirements and uses the highest impact value across the three objectives (the high-water mark) to choose the system baseline, recorded under RA-2 Security Categorization and PL-10 Baseline Selection.

Counts come from NIST's OSCAL baseline profiles. The jump from moderate to high is mostly enhancements, so a high system costs far more to assess than its base count suggests. Allocation of individual controls shows the logic:

• In all three security baselines: AC-7, AC-8, AT-2, AU-5, CP-3, IA-4, SA-22, SC-15 Collaborative Computing Devices and Applications, SI-3, SI-5 Security Alerts, Advisories, and Directives.
• Moderate and high only: AC-6, SA-10, SC-2 Separation of System and User Functionality, SC-8, SI-7 Software, Firmware, and Information Integrity, SI-10, PE-9, PE-10.
• High only: CA-8 Penetration Testing, SA-17, SC-3 Security Function Isolation.
• Privacy baseline: PT-2, PT-3, PM-22, PM-25, RA-8 Privacy Impact Assessments, SI-18, SI-19 De-identification.
• No baseline: AC-9, AU-16, CM-13, IA-9, IA-13, IR-9, MP-8, PE-21, RA-6, SA-20, SC-31, SC-49 Hardware-enforced Separation and Policy Enforcement, SC-50 Software-enforced Separation and Policy Enforcement.

Tailoring and overlays

SP 800-53B treats the baseline as a starting point and PL-11 Baseline Tailoring makes tailoring a control in its own right. The tailoring actions are:

• Identify and designate common controls: decide what the system inherits.
• Apply scoping considerations: remove or narrow controls that do not apply, for example AC-18 Wireless Access for a system with no wireless capability.
• Select compensating controls: when a baseline control cannot be implemented, use an alternative that gives equivalent protection and record why.
• Assign ODP values: for example AC-7 at 5 attempts in 15 minutes with a 30-minute lock, IA-5 password refresh only on evidence of compromise.
• Supplement: add controls the threat model needs, such as AC-2(12) Account Monitoring for Atypical Usage on a moderate system holding cloud administrator credentials.

An overlay is a reusable, published tailoring for a community, technology or environment. NIST's Control Overlay Repository lists government-wide, public and NIST-developed overlays. NIST's own include Operational Technology (SP 800-82r3 Appendix F), Cybersecurity Supply Chain Risk Management (SP 800-161r1 Appendix A), Controlled Unclassified Information (a supplement to SP 800-171 Rev. 3) and the Control Overlays for Securing AI Systems (COSAIS) project. Apply overlays after baseline selection and before system-specific tailoring, resolving any conflicts between them in the plan.

Assessment with SP 800-53A

SP 800-53A Rev. 5 (January 2022, now aligned to Release 5.2.0) turns each control into assessment procedures. Each procedure has determination statements (assessment objectives), and each objective is tested by three methods against named objects:

• Examine: documents and configurations. For IA-5 the listed objects include the identification and authentication policy, the security plan, system configuration settings, the list of authenticator types and change control records.
• Interview: responsible people, for IA-5 authenticator managers and system administrators.
• Test: mechanisms, for IA-5 the "mechanisms supporting and/or implementing authenticator management capability".

Results feed CA-2 Control Assessments, open weaknesses go into the CA-5 Plan of Action and Milestones, the authorizing official (NIST's role title) accepts residual risk under CA-6, and CA-7 sets the continuous monitoring frequency. CA-2(1) Independent Assessors is in the moderate and high baselines, so for those systems the control assessor should sit outside the team that built and runs the system. A control with an unassigned parameter cannot be determined satisfied, the commonest reason assessments stall.

Where SP 800-53 sits: RMF, CSF 2.0 and FedRAMP

• CSF 2.0: CSF states outcomes and SP 800-53 states controls that achieve them; NIST publishes the informative reference CSFv2.0-to-SP-800-53-Rev-5-2-0. Report with CSF, implement and test with SP 800-53.
• FedRAMP: FedRAMP builds on SP 800-53 baselines with its own parameter values and requirements. Its new certification classes "loosely align" with SP 800-53B impact levels, and FedRAMP states "There is not a direct correlation between FedRAMP Certification Class and Impact Level".
• SP 800-171: the CUI requirements are derived from the moderate baseline, which is why SP 800-53 knowledge transfers directly. See the CUI Guide.

OSCAL and machine-readable controls

OSCAL (Open Security Controls Assessment Language) expresses controls and compliance artefacts in XML, JSON and YAML. Its control layer has the catalog model (the controls) and the profile model, which "selects and tailors" controls to form a baseline; the implementation layer has component definitions and the system security plan; the assessment layer has the assessment plan, assessment results and POA&M. NIST publishes the Rev. 5 catalogue, which embeds the SP 800-53A objectives and methods, and the four baselines as profiles in the usnistgov/oscal-content repository. Use it to diff releases, resolve your tailored profile with your ODP values, generate the SSP from component definitions and feed assessment results into POA&M tracking.

Where identity fits

• AC-2 Account Management: the discussion lists "system" and "service" accounts as account types. Inventory them, assign account managers and tie them to an owner. See the Service Account Security Guide.
• AC-6 Least Privilege: applies to "system processes" as well as users, with AC-6(5) Privileged Accounts and AC-6(9) Log Use of Privileged Functions for automation that holds admin rights. See the Privileged Access Management Guide.
• IA-5 Authenticator Management: covers keys, certificates and tokens issued to services and devices, including changing defaults before first use; IA-5(2) Public Key-based Authentication and IA-5(7) No Embedded Unencrypted Static Authenticators address code-borne secrets. See the Secrets Management Guide.
• IA-9 Service Identification and Authentication: services must be uniquely identified and authenticated "before establishing communications with devices, users, or other services or applications". It is in no baseline, so add it when workloads call each other. See the NHI Authentication Guide.
• IA-13 Identity Providers and Authorization Servers: covers "user, device, and non-person entity (NPE) identities", with IA-13(1) to IA-13(3) on token signing keys, assertion verification and token management. See the Token and Session Security Guide.

Implementing SP 800-53: a phased approach

1. Pin the release: record Release 5.2.0 as your reference and download the OSCAL catalogue and baselines.
2. Categorise: run FIPS 199 for each system; outside government, still record the three impact values so the baseline choice is defensible.
3. Build common controls first: identity provider, logging, vulnerability scanning, backup and physical controls, each with a named provider and published inheritance statement.
4. Select and tailor: baseline plus overlays plus supplements, with every ODP assigned. Pilot on two systems of different impact before scaling.
5. Implement and document: generate the SSP from component definitions where possible.
6. Assess: run 800-53A procedures on the pilot, starting with examine and interview and adding automated tests for technical controls.
7. Authorise and monitor: set a CA-7 frequency per control and automate evidence for technical controls.
8. Roll back safely: when a tightened parameter breaks operations (say an AC-7 lockout locking service accounts), revert through CM-3 change control, open a POA&M item and fix the cause instead of quietly dropping the control.

Decision guidance

• Federal system or supplier: use the baseline categorisation dictates, plus sponsor or FedRAMP parameters.
• Small private sector organisation: use the low or moderate baseline as a checklist for critical systems and report through CSF 2.0; full RMF ceremony rarely pays back.
• Large or regulated organisation: adopt moderate as the enterprise control set, apply high selectively, and invest in OSCAL tooling, because manual SSPs do not scale.
• 800-53 or a lighter set: choose 800-53 for assessable, parameterised controls with inheritance; choose a lighter set for a short prioritised list. Many use both.

Detection and measurement

Under CA-7, monitor configuration drift against CM-2 and CM-6, account changes via AC-2(4) Automated Audit Actions, logging failures under AU-5 and vulnerability status under RA-5. Useful metrics:

• ODP completeness: percentage of selected controls with every parameter assigned (target 100% before assessment).
• Assessment currency: percentage of controls assessed within their CA-7 frequency.
• POA&M ageing: number of open items past their milestone date, split by impact.
• Inheritance coverage: share of controls satisfied fully or partly by common controls, and the number of systems affected when a common control fails.
• Release lag: days from a NIST release to its impact analysis against your profile.
• NHI coverage: percentage of service accounts and workload credentials in the AC-2 inventory with an owner and an IA-5 refresh period.

Common failure patterns

• Baseline copied, parameters blank: the plan says "AC-7 implemented" but defines no threshold, so nobody knows what correct looks like.
• Dormant accounts outside AC-2: the Colonial Pipeline attack began with an unused VPN account without MFA, what AC-2(3) Disable Accounts and IA-2(2) address.
• Least privilege applied to people only: in the Capital One breach a firewall's cloud role held far more access than its function needed, an AC-6 failure for a process, not a person.
• Static secrets in code: the Uber 2016 breach turned on an AWS key in a GitHub repository, the risk IA-5(7) targets but which is in no baseline unless you add it.
• Inheritance assumed, not verified: systems claim a common control whose provider never published scope or results, so gaps sit between owners.
• Supply chain left to procurement: SR-3 and SR-6 are in the moderate baseline but often have no technical owner; the SolarWinds compromise shows why developer build integrity (SA-10, SI-7) needs one.

Practitioner checklist

• Record the SP 800-53 release you use (5.2.0 as of 16 October 2026) and review each new release within 90 days.
• Categorise every system with FIPS 199 and record the baseline under RA-2 and PL-10.
• Assign a value to every organisation-defined parameter before assessment.
• Publish scope, assessment results and POA&M items for each common control provider.
• Document every tailoring decision, overlay and compensating control in the SSP.
• Add IA-9, IA-13 and IA-5(7) where workloads, tokens or embedded secrets exist, even though no baseline requires them.
• Bring service accounts and workload credentials into the AC-2 inventory with owners.
• Manage the catalogue, profiles and SSP as OSCAL to diff releases and reuse evidence.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: SP 800-53B, Control Baselines for Information Systems and Organizations
• NIST: SP 800-53A Rev. 5, Assessing Security and Privacy Controls in Information Systems and Organizations
• NIST: SP 800-53 Public Comment Site and Release 5.2.0 notes
• NIST: SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations
• NIST: FIPS 199, Standards for Security Categorization of Federal Information and Information Systems
• NIST: OSCAL content repository (SP 800-53 Rev. 5 catalogue and baselines)
• NIST: Control Overlay Repository

Related NHI Mgmt Group resources: CUI Guide · Identity Security Regulatory Map · Service Account Security Guide · Cyber Risk Quantification Guide · Access Reviews Guide