NIST 800-53: Control Families, Baselines and How to Use the Catalogue

NIST 800-53 (NIST Special Publication 800-53) is the most detailed public catalogue of security and privacy controls in use today. US federal agencies must use it, the FedRAMP cloud program is built on it, and many other frameworks, from the NIST Cybersecurity Framework to ISO/IEC 27001, publish mappings to it. If you sell software or cloud services to the US government, you will meet its control identifiers, such as AC-2 for account management or AU-2 for event logging, in contracts and assessments.

This guide explains how the catalogue is organised, the 20 control families, baselines and tailoring, the 2025 release that added software update integrity controls, how assessment and authorisation work, and how commercial software teams can use the catalogue without drowning in it.

What is NIST SP 800-53?

SP 800-53 is a publication of the US National Institute of Standards and Technology titled "Security and Privacy Controls for Information Systems and Organizations". It provides a catalogue of controls to protect organisational operations, assets, individuals, other organisations and the nation from threats including hostile attacks, human error, natural disasters and privacy risks. Three companion documents complete it:

• SP 800-53B: control baselines (low, moderate, high and privacy) that give a starting set of controls for systems of different impact levels.
• SP 800-53A: assessment procedures that describe how to test whether each control is implemented and effective.
• SP 800-37: the Risk Management Framework, which explains how controls are selected, implemented, assessed, authorised and monitored.

NIST also publishes the catalogue in machine-readable OSCAL format, which tools use to generate system security plans and assessment results.

History and why it was introduced

The first edition was published in 2005 to give federal agencies a common set of security controls under the Federal Information Security Management Act of 2002. Revisions followed as threats and technology changed. Revision 4 (2013) added controls for supply chain and insider threats and a privacy appendix. Revision 5, published in September 2020, made major changes: controls became outcome-based rather than written for federal agencies only, privacy controls were integrated into the main catalogue, new families for supply chain risk management (SR) and PII processing and transparency (PT) were added, and the baselines moved into the separate SP 800-53B.

NIST now updates the catalogue in numbered releases. Release 5.2.0, finalised in August 2025 in response to Executive Order 14306, focused on software development, updates and patch integrity, adding controls such as SA-24 and SI-02(07). It did not change the baselines in SP 800-53B.

Who must use NIST 800-53?

• US federal agencies, which must protect federal information systems under FISMA and OMB Circular A-130, using FIPS 199 to categorise systems and FIPS 200 and SP 800-53 to set minimum controls.
• Contractors operating federal systems or processing federal information on behalf of agencies.
• Cloud service providers seeking FedRAMP authorisation, whose baselines derive from SP 800-53.
• State and local government suppliers, through programs such as GovRAMP and state policies.
• Private organisations that want a detailed catalogue, including many banks, health systems and critical infrastructure operators.

Defence contractors handling Controlled Unclassified Information in their own systems usually follow NIST SP 800-171 instead, which is derived from SP 800-53 moderate controls.

The 20 control families

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

Each control has an identifier (for example AC-2 Account Management), a control statement, discussion, related controls, and optional control enhancements that add strength, written as AC-2(1), AC-2(2) and so on. Many controls include organisation-defined parameters, such as how often to review accounts, which the organisation or a program like FedRAMP fills in.

Families that matter most for software teams

• AC and IA: account management, least privilege, session lock and termination, MFA, authenticator management.
• AU: which events to log, content of audit records, protection of logs, review and reporting.
• CM: baseline configurations, change control, least functionality, software inventories.
• SA: secure development (SA-8 security and privacy engineering principles, SA-11 developer testing, SA-15 development process), and, since Release 5.2.0, controls on software updates.
• SC: boundary protection, encryption in transit and at rest, session authenticity.
• SI: flaw remediation, malicious code protection, system monitoring, input validation, and update integrity.
• SR: supply chain risk, provenance and component authenticity.

Reading a control: AC-2 as an example

Every control follows the same structure, so it helps to read one closely. AC-2 Account Management asks the organisation to define the types of accounts allowed, assign account managers, require conditions for group and role membership, specify authorised users and their access, require approvals for account requests, create, enable, modify, disable and remove accounts according to policy, monitor account use, notify account managers when accounts are no longer required or users leave or change roles, authorise access based on intended use, review accounts for compliance at an organisation-defined frequency, and align credential management with personnel processes.

Enhancements then add strength: AC-2(1) automated system account management, AC-2(2) automated removal of temporary and emergency accounts, AC-2(3) disabling accounts after a period of inactivity or when no longer needed, AC-2(4) automated audit of account actions, and so on. A baseline decides which enhancements apply at each impact level, and the parameters (such as the review frequency or inactivity period) make the control testable. The assessment procedure in SP 800-53A then lists the objects to examine (policies, account lists, logs), the people to interview, and the mechanisms to test.

Seen this way, most controls translate directly into product features and operational routines. AC-2 becomes an admin console with roles, approval workflows, automatic disabling of inactive accounts, and a quarterly access review report.

Mapping common controls to software features

Control	What it asks for	Typical implementation in a web application
AC-6 Least Privilege	Users and processes get only the access they need	Role-based permissions, separate admin roles, scoped API tokens
AC-7 Unsuccessful Logon Attempts	Limit consecutive failed logons and act when exceeded	Lockout or delay after failed attempts, with alerting
AC-11 and AC-12 Device Lock and Session Termination	Lock or end sessions after inactivity or conditions	Idle timeouts, session expiry, forced re-authentication for sensitive actions
AU-2, AU-3, AU-12 Event Logging and Content	Log defined events with enough detail	Structured audit logs of logins, permission changes, data exports and admin actions with user, time, source and outcome
AU-9 Protection of Audit Information	Protect logs from unauthorised access and change	Write-once storage, separate log accounts, restricted access
IA-2 Identification and Authentication	Uniquely identify users; MFA for privileged and, at higher baselines, other access	SSO with MFA, no shared accounts
IA-5 Authenticator Management	Protect passwords, keys and tokens	Strong password hashing, breached password checks, secret rotation
SC-8 and SC-13 Transmission Confidentiality and Cryptography	Protect data in transit with approved cryptography	TLS everywhere, FIPS-validated modules where federal customers require them
SC-28 Protection of Information at Rest	Protect stored data	Database and storage encryption, field-level encryption for sensitive data
SI-2 Flaw Remediation	Find and fix flaws within defined times	Dependency scanning, patch timelines by severity
SI-10 Information Input Validation	Check validity of inputs	Server-side validation and safe query handling
SA-11 Developer Testing and Evaluation	Require testing by the developer	Static analysis, security tests and code review in CI

Federal customers often require cryptographic modules validated under FIPS 140, which affects library and hosting choices. Check this early, because swapping cryptographic libraries late in a project is expensive.

Privacy controls in Revision 5

Revision 5 integrated privacy into the catalogue. The PT family (PII Processing and Transparency) covers authority to process PII, purpose specification, consent, privacy notices, specific categories of PII and computer matching. Other families include privacy-relevant controls, such as PM-18 for a privacy programme plan and RA-8 for privacy impact assessments. A separate privacy baseline in SP 800-53B lists controls that apply to systems processing PII, regardless of security impact level. For federal systems, privacy controls are selected and assessed with the senior agency official for privacy.

Baselines and tailoring

Systems are categorised as low, moderate or high impact using FIPS 199, based on the potential impact of a loss of confidentiality, integrity or availability. SP 800-53B gives a security baseline for each level and a separate privacy baseline. The organisation then tailors the baseline: identifying common controls inherited from the organisation or a provider, applying scoping considerations, assigning parameter values, adding controls for specific risks, and documenting the result in the system security plan. Programs such as FedRAMP publish their own baselines with parameters already set.

How to implement NIST 800-53 step by step

1. Categorise the system using FIPS 199 and define its boundary.
2. Select the baseline from SP 800-53B, or from the program you must meet, such as FedRAMP.
3. Tailor: identify inherited controls (for example from your cloud provider), set parameters, scope out controls that do not apply and add any needed.
4. Write the system security plan describing how each control is implemented, who is responsible and what is inherited.
5. Implement controls in the system and the organisation.
6. Assess using SP 800-53A procedures, internally or through an independent assessor.
7. Remediate and record open items in a plan of action and milestones (POA&M).
8. Authorise: for federal systems, an authorising official accepts the risk and grants an authorisation to operate.
9. Monitor continuously: vulnerability scanning, configuration monitoring, control reassessment and change management.

Documentation required

• System security plan (and privacy plan where applicable).
• Policies and procedures for each family (the "-1" control in each family, for example AC-1).
• Security assessment plan and report.
• Plan of action and milestones.
• Contingency plan and test results (CP), incident response plan (IR), configuration management plan (CM).
• Supply chain risk management plan (SR).
• Continuous monitoring strategy and results.

Assessment and authorisation

There is no "800-53 certification". Federal systems go through assessment and authorisation under the RMF, ending in an authorisation to operate issued by the agency. Cloud services sold to federal agencies use FedRAMP, which sets the baseline and assessment process. Commercial organisations can commission an independent assessment against SP 800-53 or use it as the control set behind an ISO/IEC 27001 or SOC 2 programme.

Timeline and cost considerations

Effort scales with the impact level and the size of the system. A low baseline is a fraction of a high baseline in control count. The largest costs are documentation (system security plans can be long), engineering for logging, configuration and access controls, independent assessment, and continuous monitoring. Inheriting controls from an authorised cloud provider reduces effort considerably.

Benefits and consequences of non-compliance

The catalogue gives precise, testable controls that leave little ambiguity, maps to most other frameworks and is free. For government suppliers, meeting it is a condition of doing business. Federal agencies that do not meet it face findings from inspectors general and OMB; contractors risk losing contracts or authorisations, and for knowingly false security representations to the US government, potential liability under the False Claims Act, which the Department of Justice has used in cyber cases.

Common mistakes and challenges for IT companies

• Trying to implement the whole catalogue. Start from the relevant baseline and tailor.
• Undocumented inheritance. Not recording which controls your cloud provider implements leads to gaps and duplicated effort.
• Parameters left blank. Controls are not testable until you set values such as review frequencies.
• Static system security plans that no longer match the system.
• Ignoring Release 5.2.0 software update and integrity controls in development pipelines.
• Treating SA controls as procurement only. For software vendors, SA covers your development process.

Best practices, tools and technologies

• Use OSCAL-based tools to manage system security plans and assessments as data.
• Automate evidence: identity provider reports for AC, central logging for AU, infrastructure as code for CM, scanning for RA-5 and SI-2.
• Keep a customer responsibility matrix showing which controls your product implements and which customers must.
• Sign and verify software updates and protect build pipelines to meet the 2025 integrity controls.
• Use the NIST CSF for leadership reporting and SP 800-53 for implementation.

We build audit logging, access control and configuration management into applications and modernise legacy systems that cannot meet them in our migration work.

How NIST 800-53 relates to other frameworks

Framework	Relationship
FISMA	The law that makes SP 800-53 mandatory for federal systems.
FedRAMP	Cloud authorisation program built on SP 800-53 baselines.
NIST SP 800-171	A smaller set of requirements derived from SP 800-53 for nonfederal systems handling CUI.
NIST CSF	Outcome framework mapped to SP 800-53 controls.
ISO/IEC 27001	NIST publishes a mapping between SP 800-53 and ISO/IEC 27001 Annex A.
NIST RMF	The process for selecting, assessing and authorising SP 800-53 controls.

Real-world implementation examples

Every FedRAMP-authorised cloud service has a system security plan built on SP 800-53 controls, and the FedRAMP marketplace lists those services and their impact levels. Federal agencies publish privacy impact assessments and, through inspectors general, FISMA audit reports that refer to specific control families where weaknesses were found, commonly in access control, configuration management and contingency planning.

An illustrative case for a SaaS vendor targeting state government: the state requires a moderate baseline. The vendor inherits physical and many SC controls from its authorised cloud provider, implements AC, AU, CM and IA controls in its own product and operations, writes a system security plan with a customer responsibility matrix, and engages an independent assessor. Most effort goes into logging and configuration management evidence rather than new technology.

Next steps

1. Confirm which baseline or program your customer requires.
2. Map your current controls and identify inherited ones.
3. Set parameters and write the system security plan.
4. Close gaps, starting with access control, logging and configuration.
5. Plan assessment and continuous monitoring.

Frequently asked questions

Is NIST 800-53 mandatory?

For US federal information systems, yes, under FISMA and OMB policy. For private organisations it is voluntary unless a contract or program such as FedRAMP requires it.

What is the current version of NIST 800-53?

Revision 5, maintained through numbered releases. Release 5.2.0 was finalised in August 2025.

How many control families are in NIST 800-53 Rev. 5?

Twenty, from Access Control to Supply Chain Risk Management.

What are NIST 800-53 baselines?

Starting sets of controls for low, moderate and high impact systems, plus a privacy baseline, published in SP 800-53B and then tailored.

Can we get NIST 800-53 certified?

No. Federal systems are authorised to operate after assessment; cloud services use FedRAMP; others can obtain independent assessments.

What is the difference between NIST 800-53 and 800-171?

SP 800-53 is the full catalogue for federal systems. SP 800-171 is a smaller set of requirements for protecting CUI in nonfederal systems, derived from it.

What is the difference between NIST 800-53 and ISO 27001?

ISO/IEC 27001 is a certifiable management system with 93 reference controls. SP 800-53 is a much larger, more detailed control catalogue. NIST publishes a mapping between them.

What changed in Release 5.2.0?

It added and revised controls on software development, deployment, updates and patch integrity, such as SA-24 and SI-02(07), without changing the baselines.

What is OSCAL?

The Open Security Controls Assessment Language, a NIST-developed machine-readable format for control catalogues, baselines, system security plans and assessment results.

What is a POA&M?

A plan of action and milestones: the record of known weaknesses, planned fixes, owners and dates, which assessors and authorising officials track.

Do private companies use NIST 800-53?

Yes. Many use it as their detailed control catalogue even without a government requirement, often alongside the NIST CSF or ISO/IEC 27001.