NIST Special Publication 800-53 Revision 5
Security & Privacy Controls
A comprehensive catalog of safeguards for information systems, organizations, and individuals
NIST SP 800-53 is the federal government’s authoritative catalog of security and privacy controls. First published in 2005 and now in its fifth revision (September 2020), it defines over 1,000 controls and control enhancements organized into 20 families. It serves as the foundational control catalog for FedRAMP, FISMA compliance, RMF Step 2 control selection, and is widely adopted in commercial enterprise security programs.
Rev 5 made the catalog technology-neutral and sector-agnostic — explicitly applicable to federal agencies, commercial organizations, industrial control systems, cloud environments, IoT, and privacy programs. It is no longer scoped exclusively to federal information systems.
The 20 Control Families
AC
Access Control
25 base controls
AT
Awareness & Training
6 base controls
AU
Audit & Accountability
16 base controls
CA
Assessment & Authorization
9 base controls
CM
Configuration Mgmt
14 base controls
CP
Contingency Planning
13 base controls
IA
Identification & Auth
12 base controls
IR
Incident Response
10 base controls
MA
Maintenance
6 base controls
MP
Media Protection
8 base controls
PE
Physical & Environmental
23 base controls
PL
Planning
11 base controls
PM
Program Management
32 base controls
PS
Personnel Security
9 base controls
PT
PII & Privacy
8 base controls
RA
Risk Assessment
10 base controls
SA
System & Svc Acquisition
23 base controls
SC
Sys & Comms Protection
51 base controls
SI
System & Info Integrity
23 base controls
SR
Supply Chain Risk Mgmt
12 base controls
Three security baselines
Every control in the catalog is tagged to one or more baselines based on the impact level of the system. Organizations select a baseline appropriate to their impact categorization under FIPS 199, then apply tailoring to adjust controls to their specific environment and risk posture.
LOW IMPACT
Low Baseline
Minimum controls for systems where compromise would have limited adverse effect. ~116 controls from 17 families.
MODERATE IMPACT
Moderate Baseline
Most federal systems fall here. Serious adverse effect if compromised. ~323 controls and enhancements.
HIGH IMPACT
High Baseline
Systems where compromise causes severe/catastrophic harm. ~447 controls and enhancements.
800-53 is a catalog, not a checklist
The full catalog contains every possible control across all impact levels. No organization implements all of them. The intent is to select from the catalog using baselines, then tailor to your specific environment, threat profile, mission, and risk tolerance. Selecting the moderate baseline is the starting point — not the endpoint.
September 2020
What’s New in Rev 5
The most significant rewrite since the catalog’s inception — seven major changes
Revision 5, finalized September 23, 2020, was the first major revision since Rev 4 in 2013. It fundamentally changed the catalog’s scope, structure, and philosophy — not just added controls. Security architects and compliance teams need to understand these changes to apply the catalog correctly and avoid carrying Rev 4 assumptions forward.
1. Technology and sector-neutral scope
Rev 4 was written primarily for federal information systems. Rev 5 explicitly removes this limitation. The catalog is now applicable to any organization in any sector — commercial enterprises, healthcare, financial services, critical infrastructure, and state/local government — without any translation or interpretation layer required. The language no longer assumes a federal context.
2. Privacy controls fully integrated
Prior to Rev 5, privacy controls were maintained in a separate appendix (Appendix J) and treated as a secondary concern. Rev 5 integrates privacy controls throughout the catalog, treating security and privacy as complementary disciplines. The new
PT family (PII Processing and Transparency) formalizes privacy requirements. Privacy-specific controls appear alongside security controls within each family where relevant.SP 800-53B separates the catalog from the baselines
Rev 5 moved the security and privacy control baselines into a companion document: NIST SP 800-53B (October 2020). This separates “what controls exist” (800-53) from “which controls are required at each impact level” (800-53B), making both documents easier to maintain independently.
3. Outcomes-based control language
Rev 4 controls were written as requirements directed at organizations (“The organization shall…”). Rev 5 restructures control statements into outcome-based language focused on what the control achieves rather than prescribing how an organization must be structured. This makes controls more flexible across different operating models and organizational structures.
4. Supply Chain Risk Management — new SR family
Supply chain risk was addressed implicitly in Rev 4. Rev 5 elevates it to a dedicated family (SR) with 12 base controls covering supply chain risk plans, procurement processes, supply chain protection, provenance tracking, and supplier assessments. This responds directly to years of supply chain compromise incidents (SolarWinds, hardware implants, counterfeit components).
5. PII Processing and Transparency — new PT family
The PT family is entirely new in Rev 5, covering authority for PII processing, purpose specification, information sharing, consent, and individual access. It aligns with GDPR concepts while remaining NIST-native. Organizations subject to both FISMA and privacy regulations now have a single control framework that addresses both.
6. Controls linked to attack TTPs
Rev 5 includes explicit references to MITRE ATT&CK and other threat frameworks in control supplemental guidance. Controls are now contextualized against real-world adversary behavior — not just compliance checklists. This allows security architects to map their control gaps directly to ATT&CK tactics and evaluate control effectiveness against known threat actor techniques.
7. Reduced federal/organizational separation
Rev 4 separated controls into “organization-level” and “information system-level” designations. Rev 5 removes this artificial split. Controls operate at whatever level is appropriate for the organization’s structure. This simplification is particularly important for cloud-hosted systems where the traditional boundary between organization and system has dissolved.
Rev 4 mappings do not carry forward automatically
Rev 5 renumbered, merged, and restructured many controls. Rev 4 control IDs do not map 1:1 to Rev 5. NIST publishes a formal Rev 4-to-Rev 5 mapping document. FedRAMP completed its Rev 5 transition in 2023 — systems authorized under Rev 4 baselines must be re-assessed against Rev 5.
NIST SP 800-53 Rev 5 · Chapter Two
Control Structure
How individual controls are organized, layered, and read
Every control in the 800-53 catalog follows a consistent structure. Understanding this structure is prerequisite to using the catalog correctly — particularly the relationship between base controls and enhancements, and the role of parameters and supplemental guidance.
Anatomy of a control
ID
Control Identifier
Family prefix + sequential number. Example:
AC-3 is the third control in the Access Control family. Enhancements add a parenthetical: AC-3(7) is enhancement 7 of Access Control-3.NAME
Control Name
A short descriptive title for the control. Not a requirement itself — the statement is the requirement. Example: AC-3 is named “Access Enforcement.”
STMT
Control Statement
The actual requirement. Rev 5 uses outcome-based language. May include assignment parameters [organization-defined values] and selection parameters [one or more from a list]. Organizations must fill in or select parameter values as part of implementation.
DISC
Discussion
Non-mandatory supplemental guidance explaining the intent, rationale, and implementation considerations. Not a requirement — but essential context for interpreting the control correctly and making implementation decisions.
RELATED
Related Controls
Cross-references to other controls that complement or depend on this one. These are critical for architecture — they reveal the dependency graph between controls and help identify where a single implementation decision satisfies multiple requirements.
REFS
References
Other NIST publications and external standards that provide additional guidance. Common references include SP 800-160, SP 800-207, FIPS 140-3, FIPS 186-5, and ISO/IEC 27001.
Base controls vs. control enhancements
Each family contains base controls (numbered sequentially) and control enhancements (parenthetical additions to base controls). Enhancements add capability, specificity, or rigor to the base control. They are never selected without first selecting the base control they extend.
Example: AC-2 and its enhancements
AC-2 (base) requires account management — creating, modifying, enabling, disabling, and removing accounts. AC-2(1) adds automated system account management. AC-2(3) adds automatic disabling of inactive accounts after [organization-defined time period]. AC-2(13) adds disabling accounts on high risk from threat intelligence. Each enhancement is additive — higher baselines require more enhancements on top of the same base.
Organization-defined parameters (ODPs)
Many control statements contain [Assignment: organization-defined values]. These are not blanks to leave empty — they are security decisions that organizations must make and document. NIST SP 800-53B provides default parameter values for each baseline. Organizations may accept the defaults or define stricter values. Examples:
| Control | Parameter | Low default | Mod default | High default |
|---|---|---|---|---|
| AC-2(3) | Inactivity period before account disable | Not required | 35 days | 35 days |
| AC-7 | Max consecutive invalid logon attempts | 3 | 3 | 3 |
| AU-11 | Audit log retention period | Not specified | Not specified | Not specified |
| SI-2 | Flaw remediation time (critical flaws) | Not specified | Not specified | Not specified |
| IA-5(1) | Password minimum length | Not required | Not required | Not required |
Undefined ODPs are an audit finding
Leaving organization-defined parameters undefined is not a minor procedural gap — it means the control has not been fully implemented. Assessors (CA-7, CA-8) will flag undefined ODPs as incomplete control implementations. Document every parameter value in your System Security Plan (SSP).
NIST SP 800-53B · October 2020
Baselines & Impact Levels
Three control baselines derived from FIPS 199 impact categorization
SP 800-53B defines three security control baselines — Low, Moderate, and High — corresponding to the impact levels established by FIPS 199 (Standards for Security Categorization). The baseline provides the starting set of controls for each impact level, which organizations then tailor to their specific context.
Impact categorization (FIPS 199)
The security category of a system is determined by assessing the potential impact of a security breach on three security objectives: Confidentiality, Integrity, and Availability. Each is rated Low, Moderate, or High. The overall system categorization is the high watermark — the highest individual rating across all three objectives.
| Impact Level | Definition | Example systems |
|---|---|---|
| LOW | Limited adverse effect. Loss of confidentiality, integrity, or availability would cause minor mission degradation, minor financial damage, or minor harm. | Public-facing informational websites, internal training systems, non-sensitive productivity apps |
| MODERATE | Serious adverse effect. Would cause significant mission degradation, significant financial damage, significant harm (not loss of life) to individuals. | HR systems, financial reporting, internal collaboration, most federal IT systems |
| HIGH | Severe or catastrophic adverse effect. Could cause severe mission failure, major financial damage, severe harm, or loss of life. | Emergency services, power grid control, law enforcement systems, weapons systems |
What each baseline includes
LOW BASELINE
~116 controls
Covers all 17 applicable families (PM and PT are organizational-level and not tied to impact level). Primarily base controls with minimal enhancements. Focuses on foundational hygiene: account management, basic access enforcement, audit logging, incident response capability, and contingency planning basics.
MODERATE BASELINE
~323 controls
Includes all Low baseline controls plus significant enhancements. Adds automated monitoring, stronger authentication, more rigorous audit requirements, network boundary protection, flaw remediation timeframes, and insider threat program requirements. The target for most commercial enterprises and federal civilian systems.
HIGH BASELINE
~447 controls
Maximum controls for systems with catastrophic impact potential. Adds additional enhancements on top of Moderate: two-person integrity requirements, enhanced physical controls, insider threat capabilities, advanced cryptographic requirements, and near-real-time monitoring. Typically DoD, IC, and critical infrastructure systems.
Privacy baseline
SP 800-53B also defines a Privacy Baseline that applies to systems processing Personally Identifiable Information (PII), regardless of security impact level. The privacy baseline draws primarily from the
PT family and privacy-related controls scattered across other families. It applies in addition to the applicable security baseline — not as a replacement.FedRAMP and baseline alignment
FedRAMP aligns to SP 800-53 baselines but adds additional FedRAMP-specific controls and parameters. FedRAMP Low = ~125 controls, FedRAMP Moderate = ~325 controls, FedRAMP High = ~421 controls. The differences reflect FedRAMP-specific cloud requirements and tailored ODPs. FedRAMP completed transition to Rev 5 in 2023.
NIST SP 800-53 Rev 5 · Chapter Three
Tailoring & Overlays
Adjusting the baseline to match your environment, threat profile, and risk tolerance
No baseline fits every organization perfectly. Tailoring is the formal process of modifying a selected baseline to produce a set of controls that is appropriately protective for a specific system, environment, and risk posture. Every tailoring decision must be documented and justified in the System Security Plan.
Tailoring operations
Applying scoping considerations
Removing controls that are not applicable given the system’s technology, deployment model, or operational context. Example: a system with no external network interfaces may scope out several SC boundary protection controls. Scoping must be justified — not assumed.
Selecting compensating controls
Substituting an equivalent control when a baseline control cannot be implemented as specified. The compensating control must provide equivalent protection and be documented with a rationale for why it is equally effective.
Specifying organization-defined parameters
Filling in all ODPs with specific, documented values. This is not optional — unresolved ODPs are incomplete control implementations. Parameter values may be stricter than SP 800-53B defaults but not less protective without documented risk acceptance.
Supplementing the baseline
Adding controls from the catalog (or from other sources) that the baseline doesn’t include, when your threat profile or operational context requires additional protection. Common for high-value targets, critical infrastructure, and organizations with mature threat intelligence programs.
Accepting risk for unimplemented controls
When a control cannot be implemented and no compensating control is available, the residual risk must be explicitly accepted by the Authorizing Official (AO) — not the ISSO or system owner. Undocumented risk acceptance is a fundamental audit finding.
Overlays
An overlay is a pre-built tailoring package developed for a specific community of interest, environment, or technology type. Overlays provide parameter values, scoping decisions, and supplementary controls that have already been vetted for a particular context. Organizations apply an overlay by importing its tailoring decisions into their baseline selection.
| Overlay | Applies to | Source |
|---|---|---|
| Industrial Control Systems (ICS) | SCADA, DCS, PLC environments | NIST SP 800-82 |
| Privacy | Systems processing PII | SP 800-53B Privacy Baseline |
| Cloud Systems | FedRAMP cloud service providers | FedRAMP Rev 5 |
| Classified National Security Systems | TS/SCI and below classified systems | CNSSI 1253 |
| Healthcare | HHS/CMS covered entities and BAs | HHS 405(d) |
| Intelligence Community | IC systems and networks | ICD 503 |
Tailoring is not risk elimination — it’s risk documentation
The purpose of tailoring is not to reduce the control set to the minimum possible. It is to produce a control set that is properly scoped, documented, and risk-accepted. An auditor reviewing a well-tailored SSP can evaluate every control decision — what was selected, why, and what risk was accepted. A poorly tailored SSP has gaps the organization doesn’t know exist.
NIST SP 800-53 Rev 5 · Family AC
Access Control
25 base controls governing who can access what, under what conditions, and to what degree
The AC family is the largest and most commonly referenced family in the catalog. It governs account lifecycle, access enforcement, least privilege, separation of duties, remote access, and wireless access. For Zero Trust architectures, AC is the primary family — ZTA principles are direct implementations of AC controls taken to their logical extreme.
Key controls
AC-2
Account Management
Establishes the full lifecycle for accounts: identification, establishment, activation, modification, review, disabling, and removal. Requires defining account types, conditions for use, and time-limited accounts for temporary access. AC-2 enhancements add automation, privileged account management, and dynamic privilege management.
AC-3
Access Enforcement
Enforces approved authorizations for logical access to information and system resources using access control policies such as attribute-based access control (ABAC), identity-based access control, role-based access control (RBAC), and relationship-based access control. The core enforcement control.
AC-4
Information Flow Enforcement
Controls how information flows between systems, domains, and components based on security policy. Critical for data loss prevention, cross-domain solutions, and network segmentation. Enhancements address encrypted information, metadata, and dynamic information flow policies.
AC-5
Separation of Duties
Ensures no single individual can complete a critical function alone. Defines incompatible roles and enforces separation. Essential for preventing insider fraud and limiting the blast radius of a compromised account.
AC-6
Least Privilege
Access rights limited to the minimum necessary for authorized tasks. Enhancements cover privileged accounts (AC-6(1)), non-privileged access for non-security functions (AC-6(2)), network access for privileged commands (AC-6(3)), and limiting functions available to non-privileged users.
AC-17
Remote Access
Establishes usage restrictions, configuration/connection requirements, and documentation for remote access. Enhancements require monitoring and control of remote access sessions, automated enforcement of remote access policy, and protection of confidentiality and integrity of remote access sessions.
AC-24
Access Control Decisions
New in Rev 5. Requires the system to transmit access authorization information to other systems that need to make their own access control decisions. Enables consistent access enforcement across distributed architectures and aligns directly with ZTA policy engine concepts.
AC and Zero Trust alignment
AC-2 (account management), AC-3 (access enforcement), AC-4 (information flow), and AC-6 (least privilege) collectively describe the behavioral requirements of a Zero Trust architecture. The ZTNA Policy Engine (PE) and Policy Enforcement Point (PEP) are implementation mechanisms for these controls. Mapping your ZTA design to these controls demonstrates compliance through architecture.
NIST SP 800-53 Rev 5 · Family IA
Identification & Authentication
12 base controls governing identity verification, credential management, and device authentication
The IA family establishes how users, devices, services, and processes prove their identity to a system before access is granted. It covers unique identification, credential strength, authenticator management, re-authentication, and device-level identity. In Zero Trust architectures, IA and AC are the two families most directly implemented by the IDMS, PKI, and Policy Engine.
Key controls
IA-2
Identification and Authentication (Organizational Users)
The foundational MFA control. Requires MFA for network access to privileged accounts (IA-2(1)) and non-privileged accounts (IA-2(2)). IA-2(6) requires MFA for local access. IA-2(12) added in Rev 5 specifically requires acceptance of PIV credentials and FIDO-AAL2/AAL3 authenticators — aligning with phishing-resistant MFA requirements.
IA-3
Device Identification and Authentication
Devices must uniquely identify and authenticate themselves before connection. Critical for ZTA: every device must present a verifiable identity (typically an enterprise-issued X.509 certificate) before the Policy Engine will evaluate an access request. Enhancements add cryptographic bidirectional authentication.
IA-5
Authenticator Management
Governs the full authenticator lifecycle: initial distribution, storage, use, revocation, and recovery. IA-5(1) applies to password-based authenticators (minimum length, complexity, history). IA-5(2) covers PKI-based authenticators. IA-5(13) prohibits caching credentials beyond the established organizational time limit — relevant for offline token handling.
IA-8
Identification and Authentication (Non-Organizational Users)
Extends authentication requirements to external users, contractors, and partners. Enhancements (IA-8(1)–(6)) address PIV acceptance from other federal agencies, acceptance of third-party credentials, and use of FICAM-approved credentials. Essential for federated identity architectures.
IA-11
Re-authentication
Requires re-authentication when [organization-defined circumstances or situations] occur. This is the control that mandates session re-authentication on risk change — a cornerstone of Zero Trust dynamic access policies. Organizations define the triggering conditions (inactivity timeout, privilege escalation, anomaly detection).
IA-12
Identity Proofing
New in Rev 5. Requires in-person or remote identity proofing before issuing credentials. Aligns with NIST SP 800-63A Identity Assurance Levels (IAL1–IAL3). Establishes that digital credentials are only as trustworthy as the identity proofing process that backed them.
IA-2(12): The phishing-resistant MFA control
OMB M-22-09 and CISA guidance point to IA-2(12) as the control that mandates phishing-resistant MFA — specifically PIV, CAC, and FIDO2/WebAuthn authenticators. Organizations that satisfy IA-2(1) and IA-2(2) with legacy SMS OTP or TOTP do not satisfy IA-2(12). The distinction matters for federal systems and increasingly for commercial enterprises under cyber insurance requirements.
NIST SP 800-53 Rev 5 · Family AU
Audit & Accountability
16 base controls governing what gets logged, how it’s protected, reviewed, and retained
The AU family establishes the organization’s audit capability — what events are recorded, how audit records are protected, how they’re reviewed, and how long they’re retained. A robust audit posture is foundational to both compliance and security operations — without it, incident detection, forensic investigation, and accountability are impossible.
Key controls
AU-2
Event Logging
Defines the event types the organization determines to be auditable. The organization must coordinate with other entities to select audit events, and balance audit requirements with capabilities. The baseline events differ by impact level — High baseline systems log significantly more event types than Low baseline systems.
AU-3
Content of Audit Records
Each audit record must contain sufficient information to determine: what event occurred, when, where (source and destination), who or what was involved, and the outcome. Enhancements add additional content: user identity (AU-3(1)), centralized management of planned audit record content (AU-3(2)).
AU-6
Audit Record Review, Analysis, and Reporting
Requires review and analysis of audit records for indications of inappropriate or unusual activity. Enhancements add automated integration with SIEM (AU-6(1)), correlation across systems (AU-6(3)), and integration with vulnerability scanning (AU-6(5)). This is the control that drives SIEM/SOC requirements.
AU-9
Protection of Audit Information
Protects audit logs and tools from unauthorized access, modification, and deletion. The principle: the attacker who can delete logs can hide. Enhancements cover cryptographic protection of audit information (AU-9(3)) and protecting audit information via separate storage (AU-9(2)).
AU-11
Audit Record Retention
Retains audit records for [organization-defined time period] to support after-the-fact investigations. The ODP is critical — organizations must define the retention period. NIST provides no default; sector-specific requirements (HIPAA, PCI DSS, federal) drive this value. Common values: 90 days online, 1–3 years archived.
AU-12
Audit Record Generation
Requires information systems to generate audit records for the events defined in AU-2. All system components must support audit record generation and compile records from multiple sources. Enhancements add system-wide audit trails (AU-12(1)) and standardized formats.
NIST SP 800-53 Rev 5 · Family CA
Assessment, Authorization & Monitoring
9 base controls — the RMF process controls for authorizing and continuously monitoring systems
The CA family governs the Risk Management Framework (RMF) process: how systems are assessed, how an Authority to Operate (ATO) is obtained, and how ongoing security posture is maintained through continuous monitoring. CA is the family most closely aligned with governance and compliance processes.
Key controls
CA-2
Control Assessments
Requires a plan for and execution of security control assessments. Assessments must occur before initial operation (initial ATO) and at defined intervals thereafter. Enhancements add inclusion of automated tools, specialized assessments (CA-2(2)), and independent assessors (CA-2(1)).
CA-5
Plan of Action and Milestones
The POA&M is the formal tracking document for all control deficiencies. It must document the deficiency, responsible party, planned remediation, and target completion date. Updating the POA&M is ongoing — assessors review it at every assessment. An incomplete POA&M is one of the most common ATO findings.
CA-6
Authorization
The ATO (Authority to Operate) control. An Authorizing Official must formally accept the risk of operating the system. The authorization package includes the SSP, SAR, and POA&M. Authorization decisions are based on risk — not on whether all controls are implemented, but on whether remaining risk is acceptable.
CA-7
Continuous Monitoring
Ongoing monitoring of control effectiveness, security posture, and changes. Requires a continuous monitoring strategy, ongoing assessments, ongoing remediation, and regular reporting. This is what transforms a point-in-time ATO into a living security program. Enhancements add independent assessment (CA-7(1)) and trend analysis (CA-7(4)).
CA-8
Penetration Testing
Required at Moderate and High baselines. Defines the frequency and scope of penetration testing. Enhancements add independent penetration agent (CA-8(1)) and red team exercises (CA-8(2)). The control requires acting on pentest findings — not just conducting the test.
Continuous monitoring vs. point-in-time assessment
CA-6 grants the ATO; CA-7 keeps it valid. Many organizations treat the ATO as a milestone — once granted, the focus shifts away from security rigor. NIST’s intent is the opposite: the ATO initiates a continuous monitoring program that provides ongoing visibility into the system’s actual security posture. The ATO’s validity depends on continuous monitoring remaining active and effective.
NIST SP 800-53 Rev 5 · Family RA
Risk Assessment
10 base controls governing how threats, vulnerabilities, and risks are identified and evaluated
The RA family establishes how the organization identifies and evaluates risks to operations, assets, and individuals. It drives the intelligence-informed security architecture discipline — security controls should be selected based on identified risks, not on what’s easiest to implement. RA is the analytical foundation on which CA, PM, and tailoring decisions rest.
Key controls
RA-2
Security Categorization
Formal categorization of the information system per FIPS 199. This determines baseline selection — the security category is the input to tailoring. Must be documented in the SSP and approved by the AO. Incorrect categorization (usually under-categorizing) is a systemic risk — it results in the wrong baseline and systematically under-protected systems.
RA-3
Risk Assessment
A formal assessment of risk to organizational operations, assets, individuals, other organizations, and the nation. Must assess likelihood and impact of threats and vulnerabilities. RA-3 informs which controls to implement, where to augment the baseline, and what residual risks require AO acceptance.
RA-5
Vulnerability Monitoring and Scanning
Requires ongoing vulnerability scanning at organization-defined frequencies and when new vulnerabilities affecting the system are identified. Analyzes and remediates vulnerabilities. Enhancements add privileged access for scans (RA-5(5)), automated trend analysis (RA-5(8)), and reviewing historical audit logs for vulnerabilities (RA-5(10)).
RA-7
Risk Response
New in Rev 5. Requires responding to findings from risk assessments with corrective actions. Bridges the gap between identifying risk and acting on it — the control that makes RA-3 operational rather than documentary.
RA-9
Criticality Analysis
New in Rev 5. Identifies critical system components and functions — the parts whose compromise would have the highest impact. Focuses protection resources on the highest-criticality elements. Supports the supply chain risk management (SR) controls by identifying which components require enhanced supply chain scrutiny.
NIST SP 800-53 Rev 5 · Family PM
Program Management
32 base controls — the enterprise-level governance and oversight framework for security programs
The PM family is unique: its controls operate at the organizational level, not the system level. PM controls establish the overall security program structure — governance, risk management, security architecture, workforce, and resource management. They apply to the organization regardless of how many systems it operates. PM cannot be satisfied by a single system SSP.
Key controls
PM-1
Information Security Program Plan
The overarching document that describes the security program. Must address program management controls, describe how the program is implemented, and be reviewed and updated at defined intervals. The program plan is the governance backbone — it establishes authority and accountability for the entire security program.
PM-9
Risk Management Strategy
Establishes the organization’s risk tolerance, risk appetite, and the framework for managing risk across all systems. Must be approved at the senior leadership level. The risk management strategy is what makes tailoring decisions defensible — without it, there’s no documented basis for risk acceptance.
PM-11
Mission and Business Process Definition
Defines the mission-critical and business-critical processes that the security program must protect. Feeds directly into FIPS 199 categorization by grounding impact levels in actual mission impact — not abstract definitions.
PM-30
Supply Chain Risk Management Strategy
New in Rev 5. Establishes the organizational supply chain risk management strategy that drives the SR family controls. Defines risk tolerance for supply chain risks, accountability, and how supply chain risk integrates with the broader risk management program.
PM-31
Insider Threat Program
Requires an insider threat program that includes a cross-discipline insider threat working group, access to HR data, automatic indicators, and response procedures. Required at Moderate and High baselines. Insider threat is the risk that pure technical controls cannot fully address — PM-31 establishes the people and process layer.
PM controls are frequently under-assessed
Because PM controls don’t belong to any single system, they often fall through the cracks in system-level security assessments. In practice, many organizations have robust system-level controls (AC, IA, AU) but weak program-level governance (PM). Assessors reviewing an ATO package should verify that PM controls are addressed — typically in an organization-wide security program plan rather than a system SSP.
NIST SP 800-53 Rev 5 · Family CM
Configuration Management
14 base controls governing system baselines, change control, software inventory, and least functionality
The CM family establishes control over the technical configuration of information systems. The core discipline is maintaining known, documented, approved configurations and controlling how those configurations change over time. Configuration drift is one of the most common root causes of security vulnerabilities — CM controls are the preventive layer.
Key controls
CM-2
Baseline Configuration
Documents and maintains a current baseline configuration for each information system component. The baseline is the authoritative reference for what a system is supposed to look like. Enhancements add automation (CM-2(2)), review and update triggers (CM-2(3)), and unauthorized software controls (CM-2(7)).
CM-3
Configuration Change Control
Establishes a formal change control process for all configuration changes. Changes must be documented, tested, approved, and reviewed. Unauthorized changes are detected and rolled back. This is the control that prevents “one quick change in prod” from becoming a persistent vulnerability.
CM-6
Configuration Settings
Requires configuration settings that reflect the most restrictive mode consistent with operational requirements, using security configuration checklists (DISA STIGs, CIS Benchmarks). Forces explicit justification for any deviation from the hardened baseline — deviation must be documented and approved.
CM-7
Least Functionality
Configure systems to provide only essential capabilities. Prohibit or restrict the use of functions, ports, protocols, services, and programs not required for operation. The configuration equivalent of least privilege for access control. Enhancements add authorized software lists and application deny-listing.
CM-8
System Component Inventory
Maintains an accurate, current inventory of system components. You cannot protect what you don’t know you have. Enhancements add automated updates, discovery of unauthorized components, and no-duplicate accounting. This feeds directly into vulnerability management (RA-5) and supply chain risk (SR).
CM-14
Signed Components
New in Rev 5. Prevents installation of software without verification of the developer or manufacturer’s digital signature. A direct countermeasure to supply chain attacks that introduce tampered software. Requires code signing enforcement at the OS or deployment pipeline level.
NIST SP 800-53 Rev 5 · Family SI
System & Information Integrity
23 base controls — flaw remediation, malware protection, monitoring, and information accuracy
The SI family addresses the ongoing trustworthiness of systems and the information they process. It covers patching, malware defense, intrusion detection, monitoring, and information quality. While CM controls prevent unauthorized change, SI controls detect when changes have occurred or when systems are behaving anomalously — the detective layer.
Key controls
SI-2
Flaw Remediation
Identifies, reports, and corrects system flaws. Tests software and firmware updates before installation. Installs security-relevant updates within organization-defined time periods after release. The ODP (remediation time period) is among the most important in the catalog — organizations must define patching SLAs by severity and document them.
SI-3
Malicious Code Protection
Requires malware protection mechanisms at entry and exit points, including workstations, servers, and mobile computing devices. Enhancements add non-signature-based detection, centralized management, and protection during system maintenance.
SI-4
System Monitoring
One of the most critical controls in the catalog. Monitors the system to detect attacks, indicators of potential attacks, and unauthorized connections. Requires identifying unauthorized use, deploying monitoring devices, protecting monitoring information, and heightened monitoring when indications of compromise are detected. The control that drives SIEM and SOC investment.
SI-5
Security Alerts, Advisories, and Directives
Receives, tracks, and disseminates security alerts from external organizations (CISA, sector ISACs, vendors). Implements security directives in accordance with established timeframes. Ensures operational security awareness is continuously updated from external intelligence sources.
SI-7
Software, Firmware, and Information Integrity
Employs integrity verification tools to detect unauthorized changes to software, firmware, and information. Enhancements add automated response (SI-7(5)), integration of detection and response (SI-7(7)), and code authentication. This is the control behind file integrity monitoring (FIM) requirements.
SI-10
Information Input Validation
Checks validity of information inputs — the primary application security control in the 800-53 catalog. Defines what the system does with invalid, unexpected, or erroneous inputs. The NIST control that maps to OWASP input validation requirements for application-layer security.
NIST SP 800-53 Rev 5 · Family SA
System & Services Acquisition
23 base controls — security requirements for development, procurement, and outsourcing
The SA family governs how organizations build and buy systems and services. It establishes security requirements that must be incorporated into acquisition contracts, development lifecycle processes, and third-party services. SA is the primary family for DevSecOps alignment and cloud service procurement security requirements.
Key controls
SA-4
Acquisition Process
Includes security and privacy functional requirements, security strength requirements, security assurance requirements, and developer requirements in acquisition contracts. Requires documentation of design, development, and security test results. The control that gives legal force to security requirements in vendor contracts.
SA-8
Security and Privacy Engineering Principles
Applies established security engineering principles to the development, implementation, modification, and retirement of the information system. Enhancements reference specific principles from NIST SP 800-160. Maps directly to mature security architecture practice — this is the control that requires security to be designed in, not bolted on.
SA-11
Developer Testing and Evaluation
Requires developers to create and implement a security and privacy assessment plan, perform testing, and provide documentation of results. Enhancements add static analysis (SA-11(1)), threat modeling (SA-11(2)), and dynamic analysis (SA-11(5)). The control that drives SAST/DAST and security testing requirements in software development.
SA-15
Development Process, Standards, and Tools
Requires a documented development process that addresses security and privacy. Mandates the use of development tools with security capabilities and the explicit management of vulnerabilities introduced by tools. The secure SDLC and pipeline security control.
SA-22
Unsupported System Components
Replaces or provides compensating controls for system components that cannot be supported or have reached end-of-life. One of the most practically important controls for large enterprises — requires documenting and managing every EoL component rather than simply ignoring them.
NIST SP 800-53 Rev 5 · Family SC
System & Communications Protection
51 base controls — the largest family, covering network architecture, cryptography, and boundary protection
SC is the largest family in the catalog and addresses the technical infrastructure of data protection: network boundaries, encryption, cryptographic key management, denial-of-service protection, and information in transit. SC controls are the technical implementation layer for Zero Trust network architecture and encryption requirements.
Key controls
SC-5
Denial-of-Service Protection
Protects against and limits the effects of DoS attacks. Enhancements add capacity and bandwidth management, protection against resource exhaustion, and detection/reporting. Required at all baseline levels with increasing specificity.
SC-7
Boundary Protection
Monitors and controls communications at external boundaries and key internal boundaries. Requires managed interfaces, connection denying by default, and fail-secure configurations. Enhancements (SC-7(3)–(29)) cover access points, transmission of system component information, host-based boundary protection, and dynamic isolation/segregation. One of the most extensively enhanced controls in the catalog.
SC-8
Transmission Confidentiality and Integrity
Implements cryptographic mechanisms to prevent unauthorized disclosure or modification of information during transmission. SC-8(1) requires FIPS-validated cryptographic algorithms. The foundational control for TLS/mTLS requirements — all data in transit must be encrypted.
SC-12
Cryptographic Key Establishment and Management
Establishes and manages cryptographic keys when cryptography is employed. The organization must define the key management practices, key lifecycle procedures, key storage requirements, and key recovery procedures. A weak key management posture undermines all encryption controls — SC-12 is the governance control for the entire cryptographic infrastructure.
SC-28
Protection of Information at Rest
Protects the confidentiality and integrity of information at rest. Enhancement SC-28(1) requires cryptographic protection. Drives full-disk encryption and database encryption requirements. SC-28 paired with SC-8 establishes the “encrypt everything, everywhere” baseline requirement.
SC-39
Process Isolation
Maintains a separate execution domain for each executing process. Prevents processes from accessing memory space or resources assigned to other processes. The control behind container isolation, hypervisor segmentation, and OS-level process sandboxing requirements.
SC and Zero Trust alignment
SC-7 (boundary protection with microsegmentation enhancements), SC-8 (encrypted transmission including mTLS), SC-28 (encryption at rest), and SC-39 (process isolation) collectively describe the SC-layer requirements for a Zero Trust architecture. A ZTA implementation that satisfies NIST 800-207 tenets will simultaneously satisfy large portions of the SC family.
NIST SP 800-53 Rev 5 · Family PE
Physical & Environmental Protection
23 base controls governing physical access, environmental controls, and facility security
The PE family addresses the physical security of facilities and equipment. It governs physical access authorization, monitoring, visitor management, power protection, temperature and humidity controls, and emergency procedures. Often underweighted in software-centric security programs, physical security remains a foundational layer — an attacker with physical access bypasses most logical controls.
Key controls
PE-2
Physical Access Authorizations
Manages physical access authorizations to facilities containing information systems. Maintains a list of individuals with authorized access, issues authorization credentials, and reviews the list at defined intervals. Physical access authorization follows the same lifecycle as logical account management (AC-2) — joiners, movers, and leavers must be reflected in both.
PE-3
Physical Access Control
Enforces physical access authorizations at entry/exit points. Inspects individuals entering and exiting facilities. Requires visitor escorts and monitoring. Maintains access logs. Controls must match the sensitivity of the facility — a data center requires more rigorous controls than an office building.
PE-6
Monitoring Physical Access
Monitors physical access to detect and respond to physical security incidents. Reviews physical access logs and coordinates results with incident response capability. Enhancements add video surveillance, monitoring at defined physical spaces (PE-6(2)), and automated intrusion recognition (PE-6(4)).
PE-19
Information Leakage
Protects the system from information leakage due to electromagnetic signals emanations. TEMPEST control. Required at High baseline for systems in close proximity to adversarial environments. Signals intelligence capability is an underappreciated physical threat vector for high-value systems.
NIST SP 800-53 Rev 5 · Family MA
Maintenance
6 base controls governing who can maintain systems, how, from where, and with what tools
The MA family controls system maintenance activities — both on-site and remote. It addresses who is authorized to perform maintenance, how maintenance is scheduled and recorded, what tools can be used, and how remote maintenance sessions are secured. Maintenance windows are high-risk periods: authorized individuals have elevated access, and unauthorized tools can introduce persistent access mechanisms.
Key controls
MA-2
Controlled Maintenance
Schedules, documents, and reviews maintenance. Requires approval, explicit records, and review of completed maintenance activities. The control foundation — all other MA controls assume MA-2 is in place.
MA-4
Nonlocal Maintenance
Authorizes, monitors, and controls nonlocal (remote) maintenance. Requires authentication equivalent to local access, session recording, and documented approval. Enhancements add document authentication (MA-4(2)), comparable security (MA-4(3)), and disconnection verification (MA-4(7)). The control governing all remote admin sessions — RDP, SSH, jump servers.
MA-5
Maintenance Personnel
Establishes a process for authorizing maintenance personnel and maintaining records of organizations and individuals performing maintenance. Controls what happens when maintenance personnel don’t have appropriate access authorizations — requires escort and monitoring during maintenance activities by unauthorized individuals.
MA-6
Timely Maintenance
Obtains maintenance support and spare parts within organization-defined time periods. Ensures that critical systems have an assured supply of spare parts and maintenance support so that recovery objectives (see CP family) can be met. Particularly important for systems with long lead times for specialized hardware.
NIST SP 800-53 Rev 5 · Family CP
Contingency Planning
13 base controls governing backup, recovery, testing, and continuity of operations
The CP family addresses what happens when systems fail. It governs contingency plans, backup procedures, alternate processing sites, system recovery, and reconstitution. CP controls ensure that organizations can restore operations within defined time objectives after disruptions — natural disasters, ransomware, hardware failures, or destructive cyberattacks.
Key controls
CP-2
Contingency Plan
Develops, documents, and distributes a contingency plan for the system. Must identify essential missions and business functions, provide recovery objectives, and address alternate processing. The plan must be reviewed and updated after testing and after system changes. The foundation of the entire CP family.
CP-4
Contingency Plan Testing
Tests the contingency plan at defined intervals. Documents results and initiates corrective actions. An untested contingency plan is not a contingency plan — organizations regularly discover that backups don’t restore, alternate sites aren’t functional, or key personnel don’t know their roles during a real event.
CP-9
System Backup
Conducts backups of user-level and system-level information. Defines backup frequency and retains backups for defined periods. Protects backup confidentiality and integrity. Enhancements add cryptographic protection (CP-9(8)), and off-site transfer (CP-9(3)). The control that mandates the 3-2-1 backup strategy at a policy level.
CP-10
System Recovery and Reconstitution
Provides for the recovery and reconstitution of the system to a known state after a disruption. Defines the point where reconstitution is considered complete. Enhancements address transaction recovery (CP-10(2)), restore within defined time period (CP-10(4)), and failover capability (CP-10(6)).
RTO and RPO must be defined and tested, not assumed
CP-2 requires documenting recovery time objectives (RTO) and recovery point objectives (RPO). CP-4 requires testing that these are achievable. Many organizations document ambitious RTOs and RPOs they have never validated. A ransomware incident is the wrong time to discover that restoring from backup takes 72 hours, not the 4-hour RTO in the contingency plan.
NIST SP 800-53 Rev 5 · Family IR
Incident Response
10 base controls governing detection, reporting, handling, and learning from security incidents
The IR family ensures organizations can detect, contain, eradicate, recover from, and learn from security incidents. It establishes the policy, training, testing, monitoring, and handling procedures that make incident response a repeatable capability rather than an ad-hoc crisis. Paired with AU (audit) and SI-4 (monitoring), IR is the detection-to-response pipeline.
Key controls
IR-2
Incident Response Training
Provides incident response training before assuming an incident response role, when required by system changes, and at defined frequencies thereafter. Enhancements add simulated events (IR-2(1)) and automated training (IR-2(2)). Training must address roles and responsibilities — a documented plan with untrained personnel provides no real capability.
IR-3
Incident Response Testing
Tests the incident response capability at defined frequencies. Documents and reviews results. Enhancements add coordination with related plans (IR-3(2)). Tabletop exercises, red team exercises, and live-fire simulations all satisfy IR-3 at increasing levels of rigor — the baseline requires testing, not necessarily the most intensive form.
IR-4
Incident Handling
Implements an incident handling capability covering preparation, detection, analysis, containment, eradication, and recovery. Coordinates with contingency planning (CP family). Enhancements add automated incident handling (IR-4(1)), insider threats (IR-4(6)), correlation with physical incidents (IR-4(7)), and dynamic response capability (IR-4(9)).
IR-5
Incident Monitoring
Tracks and documents incidents. Provides a formal record of each incident through its lifecycle. The documentation requirement feeds into post-incident analysis (IR-8) and continuous improvement. Incident statistics also feed the CA-7 continuous monitoring program and PM-level risk reporting.
IR-8
Incident Response Plan
Documents the incident response plan: organizational structure and management commitment, scope, roles and responsibilities, handling of specific incident types, escalation paths, and criteria for declaring a major incident. The plan must be distributed, tested, and updated. The governing document for the entire IR capability.
NIST SP 800-53 Rev 5 · Family AT
Awareness & Training
6 base controls governing security literacy, role-based training, and insider threat awareness
The AT family ensures that personnel who use, operate, and manage information systems have the security and privacy awareness and role-based training they need to carry out their responsibilities. Technical controls are only as effective as the people operating them — AT controls address the human layer of the security architecture.
Key controls
AT-2
Literacy Training and Awareness
Provides basic security and privacy literacy training to all users before authorizing access, when changes require it, and at defined intervals. Covers recognizing threats (phishing, social engineering), reporting requirements, organizational policies, and individual responsibilities. Enhancements add insider threat awareness (AT-2(2)) and social engineering simulations (AT-2(3)).
AT-3
Role-based Training
Provides role-based security and privacy training before assuming responsibilities, when required by changes, and at defined intervals. Role-based training goes beyond general awareness — system administrators, security personnel, developers, and executives each receive training appropriate to their security responsibilities and the risks they manage.
AT-4
Training Records
Documents and monitors training activities. Records must be retained and available for audit. The documentation requirement is not bureaucratic box-checking — it creates accountability and enables verification that high-risk roles are actually trained before accessing sensitive systems.
AT-2(3): Phishing simulations are now a control requirement
Enhancement AT-2(3) requires simulated social engineering and phishing exercises. This makes regular phishing simulation campaigns a compliance requirement — not just a best practice — for organizations implementing the Moderate or High baseline. Simulation results feed back into training content targeting demonstrated weaknesses.
NIST SP 800-53 Rev 5 · Family PS
Personnel Security
9 base controls governing screening, terms of employment, transfers, termination, and sanctions
The PS family addresses the human side of security before and after employment. It governs background screening, access agreements, the rules of behavior, and what happens when employment changes. While technical controls protect against external threats, PS controls reduce insider risk by establishing the personnel management processes that constrain human behavior.
Key controls
PS-3
Personnel Screening
Screens individuals before authorizing access. The depth of screening scales with the risk designation of the position. Individuals with privileged access, access to sensitive data, or critical operational roles require more rigorous screening than general users. Rescreening at defined conditions (changes in circumstances, defined time periods) is required.
PS-4
Personnel Termination
Disables access, retrieves credentials and equipment, and ensures departed individuals no longer have access within the organization-defined time period after termination. The time period ODP is critical — immediate vs. end-of-day vs. end-of-week are very different risk postures for insider threat scenarios.
PS-5
Personnel Transfer
Reviews and adjusts logical and physical access authorizations when individuals transfer to different positions. Role changes that reduce privilege must be reflected in access changes — not just handled via off-boarding at departure. This is the JML (Joiner, Mover, Leaver) “Mover” control.
PS-6
Access Agreements
Requires signed access agreements (rules of behavior, acceptable use policies, nondisclosure agreements) before access is granted, and updated agreements when content changes. The access agreement is the legal and policy acknowledgment that creates individual accountability for how access is used.
NIST SP 800-53 Rev 5 · Family PL
Planning
11 base controls — security planning, rules of behavior, architecture, and concept of operations
The PL family governs security planning documents and artifacts at the system level. It requires the organization to think through its security posture, document it formally, and review it periodically. PL controls produce the System Security Plan (SSP), rules of behavior, security architecture documentation, and concept of operations — the authoritative record of how a system is secured.
Key controls
PL-2
System Security and Privacy Plans
The SSP — the central document that describes the system boundary, system environment, security categorization, all implemented controls, and the rationale for tailoring decisions. Required for every system seeking an ATO. The SSP must be kept current — a stale SSP that doesn’t reflect the current system state is a compliance finding.
PL-4
Rules of Behavior
Establishes and distributes rules of behavior for system users. Defines responsibilities and expected behavior for information and system access. Users sign acknowledgment before access is granted. Pairs with PS-6 (access agreements) — together they define the behavioral contract for system use.
PL-8
Security and Privacy Architectures
Develops security and privacy architecture for the system that describes the overall philosophy, requirements, and approach for protecting the system. Addresses how the architecture integrates with and supports the enterprise architecture. This is the NIST control that formally requires documented security architecture — not just implemented controls, but a documented architectural rationale.
PL-8 is the security architecture control
PL-8 requires organizations to document their security architecture — the why behind control placement, trust boundary definitions, data flow protections, and integration with enterprise architecture. For mature security programs, PL-8 is where architecture decision records, threat models, and trust zone diagrams live. An SSP with only a control checklist and no architectural documentation has not satisfied PL-8.
NIST SP 800-53 Rev 5 · Family MP
Media Protection
8 base controls governing the handling, transport, sanitization, and disposal of information media
The MP family governs physical and digital media — how it’s classified, accessed, transported, sanitized, and disposed of. While cloud-native architectures have reduced removable media risk, MP remains essential for environments handling classified, sensitive, or regulated data where media handling creates real data exfiltration and exposure risks.
Key controls
MP-2
Media Access
Restricts access to digital and non-digital media containing sensitive information to authorized individuals. Ties media access control to the same authorization framework as system access control. Prevents unauthorized copying of sensitive data to removable media.
MP-6
Media Sanitization
Sanitizes media before disposal, release outside organizational control, or reuse. Sanitization method must match the sensitivity of the data — overwriting for moderate-sensitivity, physical destruction for high-sensitivity or classified. Enhancements add equipment testing, non-destructive techniques, and controlled unclassified information (CUI) provisions.
MP-7
Media Use
Restricts or prohibits the use of organization-defined types of system media on information systems. The control that allows organizations to disable USB ports, prohibit removable storage, or restrict the types of media that can be connected. A primary DLP (data loss prevention) control at the endpoint layer.
NIST SP 800-53 Rev 5 · Family PT · New in Rev 5
PII Processing & Transparency
8 base controls — the privacy family, new in Rev 5, governing PII authority, purpose, consent, and access
The PT family is entirely new in Rev 5. It governs the organization’s authority to collect and process PII, the purpose for which PII is used, how that purpose is disclosed, consent and privacy preferences, and individual rights to access their own information. PT aligns NIST’s control catalog with modern privacy frameworks including GDPR, CCPA, and the Fair Information Practice Principles (FIPPs).
Key controls
PT-1
Policy and Procedures
Establishes and maintains privacy policy and procedures. The PT family’s governance foundation — defines the organizational commitment to privacy and the procedural framework for all other PT controls.
PT-2
Authority to Process Personally Identifiable Information
Identifies and documents the legal authority that permits the collection, use, maintenance, sharing, and disposal of PII. Organizations must be able to point to a legal basis for every PII processing activity. Without documented authority, PII processing is unauthorized — a direct GDPR Article 6 parallel.
PT-3
Personally Identifiable Information Processing Purposes
Identifies and documents the purpose for which PII is processed. Restricts the processing of PII to only the identified purposes. Connects legal authority (PT-2) to actual processing activities — organizations must document not just that they can process PII, but why they are processing it.
PT-5
Privacy Notice
Provides notice to individuals about PII processing before or at the time of collection, or as soon as practicable. Covers: what is collected, authority, purpose, how it’s shared, and individual rights. The control that drives privacy policy and consent banner requirements.
PT-7
Specific Categories of Personally Identifiable Information
Applies additional processing conditions and additional safeguards for categories of PII that require special treatment — health data, financial data, biometrics, race/ethnicity, and other sensitive categories. Aligns with GDPR Article 9 special category requirements.
PT applies regardless of security baseline
PT controls are driven by whether a system processes PII — not by the system’s security impact level. A Low-baseline system that processes PII must implement the privacy baseline’s PT controls. Organizations often miss this because they categorize systems only for security impact (FIPS 199) without separately assessing privacy impact (NISTIR 8062).
NIST SP 800-53 Rev 5 · Family SR · New in Rev 5
Supply Chain Risk Management
12 base controls — the supply chain family, new in Rev 5, governing vendor risk, provenance, and integrity
The SR family is entirely new in Rev 5, elevated from scattered references in Rev 4 to a standalone family. It governs supply chain risk management strategy, vendor risk assessment, procurement security requirements, provenance tracking, and component integrity verification. SR was created in direct response to supply chain compromises (SolarWinds, CCleaner, hardware implants) demonstrating that security cannot stop at the organization’s boundary.
Key controls
SR-2
Supply Chain Risk Management Plan
Develops and documents a supply chain risk management plan. The plan must address organizational roles and responsibilities, supplier risk assessment, and how supply chain risks integrate with organizational risk management. Required at all baselines — the plan drives all other SR controls.
SR-3
Supply Chain Controls and Processes
Establishes and maintains a process or processes to identify, assess, and select suppliers and vendors. Uses multi-tiered risk assessments. Enhancements add qualified supplier lists (SR-3(1)), limited disclosure (SR-3(2)), and primary and alternate suppliers.
SR-4
Provenance
Documents and maintains provenance of systems, components, and associated data. Provenance tracking answers: where did this component come from, who made it, what chain of custody has it followed? Essential for detecting counterfeit components and tampered software. Directly addresses the hardware implant threat class.
SR-6
Supplier Assessments and Reviews
Assesses and reviews suppliers at organization-defined frequencies using organization-defined methods. Enhancements add testing and analysis of supply chain elements (SR-6(1)). Supplier assessments are not one-time events at procurement — they must be ongoing, especially for critical suppliers.
SR-10
Inspection of Systems or Components
Inspects systems or components before and after installation and at defined intervals. The physical inspection control — looking for evidence of tampering, unexpected components, or physical modifications. Particularly relevant for systems deployed in remote or exposed locations.
SR-11
Component Authenticity
Employs mechanisms to detect counterfeit components. Reports counterfeit components to defined external organizations. Enhancements add anti-counterfeit scanning, configuration control for component service and repair, and anti-counterfeit training. Counterfeit components introduced through legitimate maintenance channels are a real and documented threat vector.
SR requires RA-9 (criticality analysis) as a prerequisite
Supply chain controls must be prioritized — you cannot apply full SR rigor to every vendor and every component. RA-9 (criticality analysis) identifies which components are most critical to mission and most attractive to adversaries. SR controls are then applied most rigorously to critical components. Without a criticality analysis, SR implementation degenerates into either checkbox compliance or unsustainable overhead.
Source document
NIST SP 800-53
Security and Privacy Controls for Information Systems and Organizations — Revision 5, September 2020
About this document
NIST Special Publication 800-53 Rev 5 defines the comprehensive catalog of security and privacy controls for protecting federal information systems and organizations. Published September 23, 2020, it represents the most significant revision since Rev 4 (2013). It is sector-neutral, technology-neutral, and integrates privacy controls throughout. The companion document SP 800-53B (October 2020) provides the security and privacy control baselines.
Related publications
| Publication | Relationship to 800-53 |
|---|---|
| SP 800-53B | Companion document containing Low, Moderate, and High control baselines. Released October 2020. |
| SP 800-53A Rev 5 | Assessment procedures — how to assess whether each control is implemented correctly. |
| SP 800-37 Rev 2 | Risk Management Framework — the process that uses 800-53 for control selection (Step 2) and assessment (Step 5). |
| FIPS 199 | Security categorization standards that determine which baseline to apply. |
| SP 800-160 | Systems security engineering — engineering principles referenced by SA-8. |
| SP 800-207 | Zero Trust Architecture — describes the implementation model that satisfies many AC, IA, SC, and SI controls. |
| SP 800-63 | Digital identity guidelines — the technical standard referenced by IA-2, IA-5, and IA-12. |
Full citation: Joint Task Force. (2020). Security and Privacy Controls for Information Systems and Organizations (NIST Special Publication 800-53, Rev. 5). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-53r5