NIST SP 800-53 Security Controls Catalog: Families and Tailoring

NIST Special Publication 800-53 is the federal government’s master catalog of security controls, containing more than 1,000 individual requirements organized into 20 families. The NIST SP 800-53 security controls apply to any information system that processes, stores, or transmits federal data, whether an agency runs it directly or a contractor operates it on the government’s behalf.¹ The catalog was built to support the Federal Information Security Modernization Act of 2014, and because so many other federal programs draw from it, it is the starting point for nearly every federal cybersecurity conversation.

The Current Version: Revision 5 and Release 5.2.0

Revision 5, published in September 2020, is the edition in force. It merged privacy controls into the main catalog rather than keeping them in a separate appendix, reflecting the reality that security and privacy teams often protect the same data.¹ Revision 5 also added three families that did not exist under the original minimum security requirements in FIPS 200: Program Management, PII Processing and Transparency, and Supply Chain Risk Management.

On August 27, 2025, NIST issued Release 5.2.0, a minor update that introduced new controls in areas like software supply chain integrity and software patching, and revised discussion sections across several existing controls.² Organizations already operating under Revision 5 should review the delta to determine whether their System Security Plans need updating.

How the Catalog Is Structured

The catalog uses a layered structure designed to scale with risk. Controls are grouped into 20 families at the top level, each covering a general function such as Access Control or Incident Response. Every family contains individual base controls that state a required outcome without prescribing a specific technology. A base control might require an agency to lock user accounts after repeated failed login attempts, but leaves the specific number and duration to the agency.

That flexibility comes from organization-defined parameters, or ODPs. Many control statements include bracketed placeholders where the agency fills in its own values, and once specified those values become part of the control.¹ This mechanism keeps the catalog from being either too rigid for large agencies or too vague for small ones.

Control enhancements add depth. Each enhancement builds on its parent control by requiring additional functionality or rigor, and once a baseline assigns an enhancement, it is a distinct requirement rather than an optional suggestion. Every entry in the catalog follows the same format: a control statement describing what the organization must do, a discussion section that explains intent without adding new requirements, and cross-references to related controls.

The 20 Control Families

Each family targets a distinct area of security or privacy. Some are deeply technical, while others address management processes and human behavior.

Access Control (AC): limiting system access to authorized users and what those users can do once logged in.
Awareness and Training (AT): making sure personnel understand their security responsibilities.
Audit and Accountability (AU): recording system activity so actions can be traced back to individuals.
Assessment, Authorization, and Monitoring (CA): testing controls, authorizing systems, and tracking security status.
Configuration Management (CM): maintaining approved system settings and tracking changes.
Contingency Planning (CP): preparing for system recovery during emergencies.
Identification and Authentication (IA): verifying who users and devices are before granting access.
Incident Response (IR): detecting, reporting, and reacting to security breaches.
Maintenance (MA): servicing system components and controlling the tools used for repairs.
Media Protection (MP): safeguarding digital and physical storage.
Physical and Environmental Protection (PE): restricting physical access to facilities and protecting equipment.
Planning (PL): developing security plans that document how the organization manages risk.
Program Management (PM): managing the organization-wide security program at the executive level.
Personnel Security (PS): screening individuals in positions of trust and managing access when employees leave.
PII Processing and Transparency (PT): governing how personally identifiable information is collected, used, and disclosed.
Risk Assessment (RA): identifying threats and evaluating the impact of potential failures.
System and Services Acquisition (SA): building security into procurement and outsourcing decisions.
System and Communications Protection (SC): protecting data as it moves through networks.
System and Information Integrity (SI): detecting unauthorized changes and ensuring system accuracy.
Supply Chain Risk Management (SR): addressing risks tied to global hardware and software components.

Of these 20, 17 map directly to the minimum security requirements established in FIPS 200. The three added later (Program Management, PII Processing and Transparency, and Supply Chain Risk Management) cover enterprise governance, privacy, and supply chain concerns that FIPS 200 did not anticipate.¹

How Controls Get Selected: Categorization and Baselines

Before selecting any controls, an organization has to determine two things: what the system boundary includes, and how much damage a breach would cause. The authorization boundary draws a line around the people, processes, and technologies that make up the system, and NIST SP 800-37 recommends grouping elements that support the same mission, handle similar information, operate at the same impact level, or sit in the same environment.³

Federal Information Processing Standard 199 then provides the framework for evaluating how much harm a breach could cause. Organizations assess potential impact across three dimensions: confidentiality (unauthorized disclosure), integrity (unauthorized modification or destruction), and availability (disrupted access).⁴ Each dimension receives a rating:

Low: a breach would have a limited adverse effect on operations, assets, or individuals.
Moderate: a breach would cause a serious adverse effect.
High: a breach would result in severe or catastrophic consequences.

The highest individual rating drives the baseline selection. A system categorized as moderate for confidentiality and integrity but high for availability uses the high-impact baseline.⁴

NIST SP 800-53B translates those impact levels into actionable starting points by defining three security baselines (low, moderate, and high) plus a separate privacy baseline. The baseline tables list every control and enhancement assigned to each impact level, organized by family.⁵ FIPS 200 makes these security baselines mandatory for federal agencies.⁶

The privacy baseline works differently. It is not tied to impact levels and is not mandated by statute the way security baselines are. It applies to systems that process personally identifiable information, regardless of the security categorization, and organizations conduct privacy risk assessments to determine which of its controls apply.⁵

Tailoring the Baseline

Baselines are starting points, not finish lines. Every organization operates in a different threat environment with different technology, so the catalog builds in a structured tailoring process.

Scoping and Parameter Assignment

Scoping lets the organization remove controls that genuinely do not apply. A system with no wireless capability can scope out wireless-specific controls. After scoping, the organization fills in the ODPs for each remaining control, specifying values like how often audit logs are reviewed, how long accounts stay locked after failed logins, or which roles receive specific training.¹ These values should reflect the organization’s risk tolerance, not arbitrary round numbers.

Common, System-Specific, and Hybrid Controls

Not every control has to be implemented from scratch for every system. Common controls are implemented once at the organizational level and inherited by multiple systems. A centralized identity management service, for example, might satisfy the Identification and Authentication controls for every system that connects to it. System-specific controls apply only to one system, and hybrid controls split responsibility between the organization and the individual system.⁷ Designating controls correctly saves significant effort and prevents the dangerous assumption that someone else is handling something when no one actually is.

Overlays

For communities with shared requirements, NIST supports overlays: pre-built sets of tailoring decisions that customize baselines for specific technologies, environments, or regulatory contexts. An overlay might add controls the standard baseline does not include, remove controls that do not apply to a particular technology, or pre-fill ODP values with community-agreed settings.⁸ The FedRAMP baselines for cloud service providers are essentially government-wide overlays built on top of the SP 800-53 controls.

Authorization and Continuous Monitoring

Selecting and tailoring controls is only half the work. The organization then has to implement them, prove they work, and get formal permission to operate the system.

The System Security Plan and Assessment

The System Security Plan is the central document. It records every selected control, explains how each one is implemented, identifies who is responsible for maintaining it, and specifies the ODP values the organization chose.¹ Auditors compare this document against reality, so vague descriptions are a liability.

Once documented, the controls are assessed using procedures in NIST SP 800-53A. Assessors build a Security Assessment Plan, test whether each control operates as intended, and compile findings into a Security Assessment Report.⁹ Any shortfalls land in a Plan of Action and Milestones, which tracks each weakness, assigns a remediation timeline, and names a responsible party.

Authorization to Operate

The authorizing official, a senior management figure, reviews the full package (the System Security Plan, the assessment results, and the Plan of Action and Milestones) and makes a risk-based decision about whether the residual risk is acceptable. If so, the system receives an Authorization to Operate, and this decision cannot be delegated to lower-level staff.³ Authorizations typically expire after three years or when the system undergoes a major change, whichever comes first.¹⁰

Continuous Monitoring

Authorization is not a one-time event. FISMA requires agencies to assess their security controls at a frequency appropriate to risk, but no less than annually.¹¹ In practice, high-impact systems and volatile controls need monitoring far more often than that. SP 800-137 identifies several factors that should drive monitoring frequency:

Control volatility: settings that change frequently need more frequent checking than static controls like personnel screening policies.
System impact level: high-impact systems warrant tighter monitoring cycles.
Known weaknesses: controls with documented deficiencies get extra scrutiny until remediation is complete.
Emerging threats: new vulnerability disclosures or active exploits should trigger reassessment outside the normal schedule.

Monitoring frequencies are not static. Automation lets organizations collect data more frequently and consistently than manual reviews ever could, and agencies are encouraged to push toward near-real-time awareness wherever feasible.¹¹

Who Else Has to Follow It

SP 800-53 is written for federal agencies, but its reach extends much further. Two major programs translate the catalog’s controls into binding requirements for private-sector organizations that work with the government.

FedRAMP for Cloud Providers

Any cloud service provider that wants to host federal data must go through the Federal Risk and Authorization Management Program. FedRAMP baselines are built directly on top of NIST SP 800-53 Revision 5, with additional FedRAMP-specific parameters layered on.¹² The provider implements the controls, submits a full authorization package, and receives approval from either the Joint Authorization Board or an agency authorizing official.

NIST SP 800-171 and CMMC for Defense Contractors

Contractors that handle Controlled Unclassified Information face a related set of requirements under NIST SP 800-171. Revision 3 of that publication explicitly treats SP 800-53 as its “single authoritative source,” deriving its security requirements by tailoring the moderate baseline in SP 800-53B down to what is necessary for protecting CUI.¹³ When the SP 800-53B moderate baseline is updated, the 800-171 requirements update as well.

For defense contractors, the Cybersecurity Maturity Model Certification program adds a verification layer. CMMC Level 2 is equivalent to the full set of security requirements in NIST SP 800-171, and contractors must demonstrate compliance to win or keep Department of Defense contracts involving CUI.¹⁴ The practical effect is that SP 800-53 controls ripple outward from federal agencies into the entire defense industrial base.

Where the Legal Weight Comes From

SP 800-53 does not exist in isolation. The Federal Information Security Modernization Act of 2014 is the statutory foundation, requiring agencies to implement controls that meet minimum security standards. OMB Circular A-130 operationalizes that mandate by directing agencies to select controls from SP 800-53, tailored as appropriate, to satisfy the minimum requirements in FIPS 200.¹⁵ The Risk Management Framework in NIST SP 800-37 provides the process model that ties everything together: categorize the system, select the controls, implement them, assess their effectiveness, authorize the system, and monitor continuously.³

FISMA also makes agency heads personally responsible for their organization’s information security posture. Under 44 U.S.C. § 3554, each agency head must provide security protections proportional to the risk involved, integrate security into budget and strategic planning, and delegate day-to-day compliance to a Chief Information Officer backed by a senior information security officer.¹⁶ Every agency also submits annual reports on its security program to OMB and to six congressional committees, detailing incident counts, major breach descriptions, and the agency head’s assessment of the program.¹⁷ Understanding where SP 800-53 fits in this hierarchy explains why the catalog is structured the way it is: FIPS 199 feeds the categorization, FIPS 200 sets the floor, SP 800-53 provides the controls, and SP 800-53B maps them to baselines.

1
National Institute of Standards and Technology. NIST Special Publication 800-53 Revision 5 – Security and Privacy Controls for Information Systems and Organizations
2
Computer Security Resource Center. SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
3
National Institute of Standards and Technology. NIST Special Publication 800-37 Revision 2 – Risk Management Framework for Information Systems and Organizations
4
National Institute of Standards and Technology. FIPS 199 – Standards for Security Categorization of Federal Information and Information Systems
5
National Institute of Standards and Technology. NIST SP 800-53B – Control Baselines for Information Systems and Organizations
6
National Institute of Standards and Technology. FIPS 200 – Minimum Security Requirements for Federal Information and Information Systems
7
National Institute of Standards and Technology. Security and Privacy Controls for Information Systems and Organizations
8
Computer Security Resource Center. Overlay Overview – NIST Risk Management Framework
9
Computer Security Resource Center. NIST SP 800-53A Rev. 5, Assessing Security and Privacy Controls in Information Systems and Organizations
10
CMS Information Security and Privacy Program. Authorization to Operate (ATO)
11
National Institute of Standards and Technology. Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations (SP 800-137)
12
FedRAMP. FedRAMP Baseline Revision 5 Transition Guide
13
NIST Computer Security Resource Center. Frequently Asked Questions: NIST SP 800-171 Revision 3 and NIST SP 800-171A Revision 3
14
Department of Defense CIO. Cybersecurity Maturity Model Certification (CMMC) Model Overview
15
The White House. OMB Circular A-130 – Managing Information as a Strategic Resource
16
Office of the Law Revision Counsel. 44 USC 3554 – Federal Agency Responsibilities
17
The White House. M-25-04 Fiscal Year 2025 Guidance on Federal Information Security and Privacy Management Requirements