NIST SP 800-53: the 20 security and privacy control families, explained

NIST SP 800-53, "Security and Privacy Controls for Information Systems and Organizations," is the US National Institute of Standards and Technology's catalogue of individual security and privacy controls. Its own abstract describes it as providing "a catalog of security and privacy controls for information systems and organizations to protect organizational operations and assets, individuals, other organizations, and the Nation from a diverse set of threats and risks, including hostile attacks, human errors, natural disasters, structural failures, foreign intelligence entities, and privacy risks." The current version, Revision 5, was published in September 2020; NIST keeps it current with dated releases on top of the same revision, most recently Release 5.2.0 on 27 August 2025, which added new controls — including SA-15(13), SA-24 and SI-02(07) — alongside revisions to existing ones. Written to satisfy the Federal Information Security Modernization Act (FISMA) and related federal policy, SP 800-53 has become a de facto reference catalogue well beyond US federal use, including as the technical backbone of the FedRAMP cloud-authorization program.

The catalogue, not the checklist

It helps to be precise about what kind of document SP 800-53 actually is. It is a catalogue: a comprehensive list of possible controls, each with a defined purpose, grouped into families — not a prescription of which specific controls any one system must implement. That selection decision, and the baselines that drive it, live in a separate companion publication, SP 800-53B, covered below. A team that opens SP 800-53 expecting a single checklist to work through top to bottom is working against the document's own design.

The 20 control families

Every control in the catalogue is filed under one of 20 families, each identified by a two-letter code used throughout NIST documentation and tooling:

Code	Family
AC	Access Control
AT	Awareness and Training
AU	Audit and Accountability
CA	Assessment, Authorization, and Monitoring
CM	Configuration Management
CP	Contingency Planning
IA	Identification and Authentication
IR	Incident Response
MA	Maintenance
MP	Media Protection
PE	Physical and Environmental Protection
PL	Planning
PM	Program Management
PS	Personnel Security
PT	PII Processing and Transparency
RA	Risk Assessment
SA	System and Services Acquisition
SC	System and Communications Protection
SI	System and Information Integrity
SR	Supply Chain Risk Management

Within each family, individual controls carry an identifier such as AC-2 (Account Management) or SR-11 (Component Authenticity), and many controls have numbered control enhancements — optional, more stringent additions to the base control, written as AC-2(1), AC-2(2) and so on. NIST describes the controls overall as "flexible and customizable," meant to be "implemented as part of an organization-wide process to manage risk." The exact control and enhancement count changes between releases as NIST adds, retires or revises entries (as the August 2025 Release 5.2.0 did), so any specific total quoted elsewhere should be checked against the current release rather than treated as fixed.

Two families are worth calling out specifically for a device or firmware maker: PT (PII Processing and Transparency), added in Revision 5 to fold in privacy controls that earlier revisions handled as a separate appendix, and SR (Supply Chain Risk Management), also new in Revision 5, which covers controls like supplier assessment, component authenticity and counterfeit prevention — the same territory our SP 800-161 C-SCRM guide covers in more depth for the supply-chain-specific publication built on top of this family.

Baselines: SP 800-53B decides which controls apply

SP 800-53 itself does not say which controls a given system must implement — that is the job of its companion publication, SP 800-53B, "Control Baselines for Information Systems and Organizations." SP 800-53B's own abstract states it "provides security and privacy control baselines for the Federal Government," consisting of "three security control baselines (one for each system impact level—low-impact, moderate-impact, and high-impact), as well as a privacy baseline that is applied to systems irrespective of impact level."

Baseline	Applies to
Low-impact	Systems where loss of confidentiality, integrity or availability would have a limited adverse effect
Moderate-impact	Systems where that loss would have a serious adverse effect
High-impact	Systems where that loss would have a severe or catastrophic adverse effect
Privacy baseline	Applied regardless of impact level, wherever personally identifiable information is processed

A system's impact level is typically determined through a separate categorization step (commonly under FIPS 199), and once the matching baseline is selected, an organization tailors it — adding, removing, or adjusting controls, or applying a NIST- or organization-defined overlay, such as the operational-technology overlay SP 800-82 Rev. 3 adds on top of the SP 800-53 baselines for OT environments (see our SP 800-82 guide). Tailoring is expected, not a deviation to be avoided — a baseline is a documented starting point, not a one-size-fits-all mandate.

Where this sits in NIST's broader risk framework

SP 800-53 does not operate alone. It is the control catalogue consumed by NIST's Risk Management Framework (RMF), described in SP 800-37, at the "Select," "Implement," "Assess" and "Monitor" steps. The risk assessment work that informs which controls matter most for a given system draws on the process SP 800-30 defines (see our SP 800-30 guide), and NIST's own Rev. 5 documentation includes mappings from the SP 800-53 catalogue to the NIST Cybersecurity Framework, the NIST Privacy Framework, and ISO/IEC 27001:2022 — letting an organization that already maintains one of those frameworks cross-reference its existing controls against SP 800-53's more granular catalogue rather than starting a gap assessment from zero.

A workable starting point

1. Pick a baseline before you pick controls. Trying to select individually from 20 families and hundreds of controls without first choosing low/moderate/high (or an equivalent risk-based starting point) from SP 800-53B is the most common way SP 800-53 adoption stalls.
2. Use the two-letter family codes as your evidence index, the same way our IEC 62443-3-3 guide recommends organizing evidence under that standard's seven foundational requirements — most organizations already have documentation that maps cleanly onto AC, AU, CM, IR and SI even before a formal SP 800-53 exercise begins.
3. Treat SR (Supply Chain Risk Management) and PT (PII Processing and Transparency) as the families most likely to be missing if your existing security program predates Revision 5 — both were added or substantially reworked in that revision.
4. Confirm the current release before citing a control ID or count. NIST issues dated releases on top of Revision 5 (most recently 5.2.0 in August 2025) that add or revise individual controls; a control ID quoted from an older summary may not match the current catalogue.

SoftWSP maps the security evidence a device or firmware program already has against the relevant SP 800-53 families and flags where the Supply Chain Risk Management (SR) controls specifically need more than a vendor questionnaire: see device firmware security.

This guide summarises a public NIST publication; it does not constitute legal or compliance advice.