
NIST Special Publication 800-53 identifies federal information security controls. It is the catalogue of security and privacy controls that federal agencies apply to their information systems.
FISMA is the law that requires them. NIST SP 800-53 is the document that lists them.
That distinction is where most of the confusion sits, and it is worth holding onto as you read on.
The Answer: NIST Special Publication 800-53
The full title is Security and Privacy Controls for Information Systems and Organizations.
It is published by the National Institute of Standards and Technology under authority granted by the Federal Information Security Modernization Act.
If you are answering a training question, that is the answer. NIST SP 800-53.
Everything below explains why, and what the document actually does once you get past the name.
Why Not FOIA, the Privacy Act, or FISMA Itself?
These three show up as options in nearly every version of this question. Each is plausible. None is correct, though one comes close enough to deserve a proper explanation.
The Freedom of Information Act
FOIA is about disclosure. It gives the public a right to request records held by federal agencies.
Its purpose is releasing information, not protecting it.
If anything, FOIA points in the opposite direction from a security control catalogue. Easy to rule out once you see it that way.
The Privacy Act of 1974
This one is genuinely relevant to personal information, which is why it catches people.
The Privacy Act governs how federal agencies collect, maintain, use, and disclose records about individuals. It carries real legal weight around PII handling.
But it contains no control catalogue. It does not tell you to enforce multi-factor authentication or set audit log retention periods.
It creates obligations. NIST SP 800-53 supplies the controls that meet them.
FISMA - Close, but Not Quite
Here is the nuance worth knowing.
FISMA is the law requiring federal agencies to secure their information systems. It created the whole framework. Some course materials accept FISMA as the answer, and you can see why.
But FISMA does not list controls. Laws rarely do.
Instead it directs NIST to develop the standards and guidelines. That delegation is precisely what makes SP 800-53 the document that identifies the controls.
Think of it as a chain. FISMA creates the requirement. NIST SP 800-53 fulfils it.
What NIST SP 800-53 Actually Contains
The document catalogues hundreds of individual controls, each with a statement of what it requires, supplemental guidance, and control enhancements for higher-risk situations.
They are grouped into families.
The 20 Control Families
Revision 5 organises controls into 20 families. Each has a two-letter identifier that appears throughout federal security documentation.
ID | Family |
AC | Access Control |
AT | Awareness and Training |
AU | Audit and Accountability |
CA | Assessment, Authorization, and Monitoring |
CM | Configuration Management |
CP | Contingency Planning |
IA | Identification and Authentication |
IR | Incident Response |
MA | Maintenance |
MP | Media Protection |
PE | Physical and Environmental Protection |
PL | Planning |
PM | Program Management |
PS | Personnel Security |
PT | PII Processing and Transparency |
RA | Risk Assessment |
SA | System and Services Acquisition |
SC | System and Communications Protection |
SI | System and Information Integrity |
SR | Supply Chain Risk Management |
Controls get referenced by family and number. AC-2 is account management. IR-4 is incident handling.
Once the family codes are familiar, federal security documentation becomes far easier to read.
What Revision 5 Changed
Revision 5 was a structural rework rather than a refresh.
Two families were added. PT brought privacy controls into the main catalogue instead of leaving privacy in a separate appendix. SR made supply chain risk a first-class concern, reflecting how attacks had actually been happening.
The language shifted to outcome-based as well. Earlier revisions described what the organisation must do. Revision 5 describes the control itself, which lets it apply to systems, components, and services rather than only to agencies.
NIST issues patch releases against Revision 5 as individual controls get updated. Worth checking the current release before building a control set from it.
The Other Documents in the Same Family
SP 800-53 does not operate alone. Several publications interlock, and knowing which does what saves a lot of confusion.

Document | What it does |
FISMA | The law. Requires agencies to secure federal information systems |
FIPS 199 | Categorises systems as low, moderate, or high impact |
FIPS 200 | Sets the minimum security requirements |
NIST SP 800-53 | The control catalogue. Identifies the actual controls |
NIST SP 800-53A | Covers how to assess whether controls are working |
NIST SP 800-53B | Defines the control baselines for each impact level |
NIST SP 800-37 | The Risk Management Framework. The process for applying all of it |
NIST SP 800-171 | Protecting controlled unclassified information in nonfederal systems |
OMB Circular A-130 | Federal policy on managing information resources |
A shortcut for holding it together: FIPS 199 tells you how serious the system is. SP 800-53B tells you which controls apply at that level. SP 800-53 tells you what each control involves. SP 800-37 tells you the order to do it in.
Working through the process itself? Our guide to the RMF steps covers it stage by stage.
Which Controls Apply to a Given System?
Not all of them. That is the part people miss.
Step 1. Categorise the System
FIPS 199 asks one question across three properties: confidentiality, integrity, and availability.
For each, what would the impact be if it were lost? Low, moderate, or high.
The highest of the three sets the overall category. A system with low confidentiality impact but high availability impact is a high-impact system.
Step 2. Apply the Matching Baseline
SP 800-53B defines three baselines - low, moderate, and high - plus a privacy baseline.
Your categorisation selects the baseline. The baseline gives you the starting control set.
From there you tailor. Add controls where risk assessment demands them. Scope out controls that genuinely do not apply, with documented justification.
That justification is not optional in practice. Tailoring without recorded reasoning is the finding assessors write up most often.
Where Does PII Fit In?
Many people reach this question through personally identifiable information training, so it is worth being precise.
PII protection draws on both security and privacy controls.
The PT family covers privacy specifically - consent, notice, purpose limitation, and how PII gets processed. Security families like AC, MP, and SC protect it in practice through access restrictions, media handling, and encryption.
The Privacy Act sets the legal obligations around PII. NIST SP 800-53 supplies the technical and procedural controls.
Both apply. They answer different questions.
How to Meet the Requirement: A 10-Step Checklist
For teams implementing this rather than answering a test question, here is the sequence.

- Build the system inventory. Every information system, with boundaries defined. You cannot secure what you have not listed.
- Categorise each system using FIPS 199. Confidentiality, integrity, availability. Take the highest rating.
- Select the baseline from SP 800-53B matching that categorisation.
- Tailor the control set. Add what risk assessment demands. Remove what does not apply, and record why.
- Document in the System Security Plan. Every control, its implementation status, and its owner.
- Implement the controls. Technical, operational, and management.
- Assess the controls using SP 800-53A methods. Independent assessment where required.
- Authorise the system. The authorising official accepts residual risk formally, in writing.
- Monitor continuously. Ongoing assessment, configuration management, and reporting.
- Report and reassess. FISMA reporting to OMB, plus reauthorisation when the system changes materially.
Steps 9 and 10 are where most programmes weaken. Authorisation feels like the finish line. It is closer to halfway.
Three Things Teams Get Wrong
Treating the baseline as the final answer. Baselines are a starting set, not a target. A moderate baseline applied without tailoring usually produces both over-controlled areas and real gaps.
Skipping justification for scoped-out controls. Removing a control is permitted. Removing it without recorded reasoning is a finding waiting to happen.
Assuming FISMA stops at the agency boundary. Contractors, cloud providers, and subcontractors handling federal data are in scope. Organisations working toward CMMC compliance or handling controlled unclassified information hit this constantly.
Managing Security Controls in Effivity
Twenty control families across multiple systems generates a lot of evidence. System security plans, implementation records, assessment results, authorisation decisions, monitoring output.
Keeping it current is an administrative problem as much as a security one.
Effivity's information security management capability gives each control an owner, a status, and an evidence trail. Assessment findings link back to the controls they relate to, and corrective actions carry owners and due dates.
Version history with date and time stamps, role-based access, and e-signatures mean an authorisation decision from three years ago comes out with its trail intact. That matters when reassessment lands and the people who made the original call have moved on.
Running ISO 27001 alongside federal requirements? Many SP 800-53 controls map closely to Annex A, and maintaining both separately duplicates work. Our guide to cyber security compliance covers where they overlap.
Frequently Asked Questions
What guidance identifies federal information security controls?
NIST Special Publication 800-53, Security and Privacy Controls for Information Systems and Organizations. NIST issues it under authority from FISMA, and it catalogues the controls federal agencies apply to their information systems.
Does the Privacy Act of 1974 identify federal information security controls?
No. The Privacy Act governs how federal agencies collect, maintain, use, and disclose records about individuals. It sets legal obligations around personal information but contains no catalogue of security controls. NIST SP 800-53 does that.
What are the three main types of information security controls?
Technical, administrative, and physical. Technical controls work through technology such as encryption and access management. Administrative controls are policies, procedures, and training. Physical controls protect facilities and equipment. NIST SP 800-53 covers all three across its 20 families.
What is the difference between FISMA and NIST SP 800-53?
FISMA is the law requiring federal agencies to secure their information systems. NIST SP 800-53 is the publication listing the controls used to meet that requirement. FISMA creates the obligation, SP 800-53 supplies the catalogue.
How many control families are in NIST SP 800-53?
Revision 5 contains 20 control families. Two were added in Revision 5 - PII Processing and Transparency, and Supply Chain Risk Management.
Does FISMA apply to contractors?
Yes. Contractors, cloud service providers, and other organisations handling federal information or operating systems on behalf of an agency fall within scope. The requirement follows the data rather than the organisation type.
What is FIPS 199 used for?
FIPS 199 categorises an information system as low, moderate, or high impact based on confidentiality, integrity, and availability. That categorisation determines which SP 800-53 baseline applies.
Do all NIST SP 800-53 controls apply to every system?
No. A system applies the baseline matching its FIPS 199 categorisation, then tailors it. Controls can be added based on risk or scoped out where they do not apply, provided the reasoning is documented.