FISMA Compliance: NIST SP 800-53 for Federal Systems

Introduction

The federal government’s OPM data breach of 2015 exposed the personnel records of 21.5 million current and former federal employees and contractors. The investigation found that OPM’s systems had not implemented multi-factor authentication, had failed to conduct required security assessments, and had not maintained an inventory of all systems — all requirements under FISMA and NIST SP 800-53. The breach led directly to new OMB directives and stricter enforcement of existing FISMA requirements. The cost to remediate and notify affected individuals exceeded USD 500 million.

FISMA compliance is the legal framework that governs how every federal agency and every contractor operating a federal information system must manage information security. It is not a technical standard — it is a law (44 U.S.C. §§ 3551–3558) that mandates federal agencies follow NIST standards and report to Congress annually on their security posture. The NIST standards, particularly SP 800-53 Rev 5 and SP 800-37 Rev 2, are where the technical controls live.

For technology companies selling to the federal government — particularly SaaS providers and cloud vendors — FISMA compliance as exercised through FedRAMP is the market entry requirement. A cloud product without FedRAMP authorization cannot be used to process federal data. For cloud security frameworks, see our guide on SOC 2 encryption controls. This article explains the FISMA legal framework, the NIST controls that implement it, the ATO process, and what your team must build.

What Is FISMA?

The Federal Information Security Modernization Act of 2014 (44 U.S.C. §§ 3551–3558) updated the original FISMA of 2002 to reflect the shift to continuous monitoring and modern cyber threats. FISMA establishes a comprehensive framework for ensuring the effectiveness of information security controls over federal government information systems.

Who is subject to FISMA:

• All federal executive branch agencies
• Contractors and other organizations operating information systems on behalf of federal agencies
• Cloud service providers whose offerings process federal information (subject to FedRAMP, which implements FISMA for cloud)

FISMA’s Core Requirements (44 U.S.C. § 3554):

1. Periodic risk assessments of agency information and information systems
2. Risk-based policies and procedures to cost-effectively reduce risk
3. Plans for providing adequate information security for networks, facilities, and systems
4. Security awareness training for agency personnel
5. Periodic testing and evaluation of the effectiveness of information security policies
6. A process for planning, implementing, evaluating, and documenting remedial action
7. Procedures for detecting, reporting, and responding to security incidents
8. Plans for continuity of operations for information systems that support operations

The NIST Connection: FISMA mandates compliance with “information security standards and guidelines developed by NIST” under 44 U.S.C. § 3554(b). NIST SP 800-53 Rev 5 is the foundational control catalog. NIST SP 800-37 Rev 2 provides the Risk Management Framework (RMF) — the step-by-step process for applying those controls.

How FISMA Compliance Works

The NIST Risk Management Framework (SP 800-37 Rev 2)

The RMF is a 7-step process that systems go through to achieve and maintain an Authority to Operate:

Step 1 — Prepare: Establish the organizational risk management strategy, roles, and resources. Identify common controls that can be inherited by multiple systems.

Step 2 — Categorize: Categorize the information system and the information it processes using FIPS Publication 199. Determine impact levels (Low, Moderate, High) for confidentiality, integrity, and availability. The highest impact level across the three determines the system’s overall categorization.

Step 3 — Select: Select the applicable NIST SP 800-53 control baseline (Low, Moderate, or High) based on the categorization. Tailor the baseline by adding controls for specific threats or removing controls that are not applicable to the system’s operating environment.

Step 4 — Implement: Implement the selected controls. Document implementation details in a System Security Plan (SSP). The SSP is the primary artifact of FISMA compliance — it describes every control, how it is implemented, and any gaps.

Step 5 — Assess: An independent Security Control Assessor (SCA) evaluates whether the controls are implemented correctly and operating as intended. The assessment produces a Security Assessment Report (SAR).

Step 6 — Authorize: The Authorizing Official reviews the SSP, SAR, and Plan of Action and Milestones (POA&M). If residual risk is acceptable, the AO issues an ATO. ATOs are typically valid for 3 years, after which the system must be reassessed.

Step 7 — Monitor: Continuously monitor controls for changes, new threats, and control effectiveness. Report security status to the Authorizing Official. Conduct ongoing assessments of selected controls and update the SSP when significant changes occur.

NIST SP 800-53 Rev 5 — Control Families

SP 800-53 Rev 5 contains 20 control families, identified by two-letter codes. The most directly relevant to data security and encryption:

SC — System and Communications Protection (controls SC-1 through SC-51):

• SC-8: Transmission Confidentiality and Integrity — requires cryptographic protection for data in transit
• SC-12: Cryptographic Key Establishment and Management — requires documented key management lifecycle
• SC-13: Cryptographic Protection — all cryptographic implementations must use FIPS-validated cryptographic modules (FIPS 140-2 or 140-3)
• SC-28: Protection of Information at Rest — requires cryptographic protection for sensitive information at rest

IA — Identification and Authentication (IA-1 through IA-12):

• IA-2: Identification and Authentication (Organizational Users) — MFA required for all accounts with privileged access and all network access for Moderate/High systems
• IA-5: Authenticator Management — password length, complexity, and rotation requirements
• IA-7: Cryptographic Module Authentication — authentication mechanisms must use FIPS-validated modules

AU — Audit and Accountability (AU-1 through AU-16):

• AU-2: Event Logging — specific security-relevant events must be logged
• AU-3: Content of Audit Records — logs must include enough information to reconstruct events
• AU-9: Protection of Audit Information — logs must be protected from unauthorized modification
• AU-11: Audit Record Retention — 3 years for most federal systems

CA — Assessment, Authorization, and Monitoring:

• CA-2: Control Assessments — annual assessment of at least a subset of controls
• CA-7: Continuous Monitoring — ongoing monitoring of security controls and system changes

VIDEO · READY 16:9

PLAY

FISMA and NIST Risk Management Framework Explained

FISMA / NIST SP 800-53 Compliance Checklist

Use this checklist for ATO preparation or FedRAMP authorization. Items are organized by the 7 RMF steps and key control families.

Step 1 — Prepare

1. System owner identified and documented with name and contact information
2. Authorizing Official identified — senior agency official with authority to accept risk
3. Common control catalog reviewed — identify inherited controls (e.g., agency-provided authentication, network perimeter controls)
4. Privacy threshold analysis completed to determine if the system processes PII

Step 2 — Categorize (FIPS 199)

1. System categorized by evaluating confidentiality, integrity, and availability impact levels
2. FIPS 199 categorization form completed and approved
3. Overall system categorization established (Low / Moderate / High)
4. Information types documented using NIST SP 800-60 taxonomy

Step 3 — Select Controls

1. Applicable baseline selected: Low (125 controls), Moderate (323 controls), or High (421 controls)
2. Tailoring decisions documented: added controls for specific threats, removed non-applicable controls
3. FedRAMP baseline applied if the system is a cloud offering (FedRAMP Moderate: 325 controls)
4. Control allocation determined: which controls are implemented by the system vs. inherited from the organization

Step 4 — Implement (System Security Plan)

1. SSP completed for all selected controls — each control documented with implementation status and description
2. SC-13 (Cryptographic Protection): FIPS 140-2 or 140-3 validated module in use — documented with validation certificate number
3. SC-28 (Protection of Information at Rest): all sensitive data at rest encrypted using FIPS-validated module
4. SC-8 (Transmission Confidentiality): TLS 1.2 minimum with FIPS-approved cipher suites on all connections transmitting sensitive data
5. IA-2 (MFA): MFA implemented for all privileged accounts and all network access (Moderate/High)
6. AU-2/AU-3 (Logging): all required security-relevant events logged with sufficient detail
7. CA-3 (System Interconnection Agreements): ISA/MOU executed for all connections to external systems
8. PL-8 (Security Architecture): security architecture document describes all system components and their security controls

Step 5 — Assess (Security Assessment Report)

1. Independent SCA engaged — must have no conflict of interest with system owner
2. Assessment plan reviewed and approved by Authorizing Official before testing begins
3. Assessment methods include: examination (document review), interview, and testing for each control
4. SAR documents all findings with risk ratings (Critical, High, Medium, Low, Informational)
5. All Critical and High findings remediated or accepted with documentation before ATO

Step 6 — Authorize

1. POA&M created for all outstanding findings not remediated before authorization
2. Risk acceptance letter from Authorizing Official with residual risk documented
3. ATO letter issued with specific system boundary and authorization date
4. ATO expiration tracked — maximum 3 years before reassessment required

Step 7 — Monitor (Continuous Monitoring)

1. Continuous monitoring plan documented: which controls are monitored, how often, and by whom
2. Monthly security status reports submitted to Authorizing Official
3. Annual assessment of at least a subset of controls (CA-2)
4. Significant change procedures: security impact analysis conducted before any significant system change
5. POA&M updated monthly with remediation status

FedRAMP-Specific (for cloud service providers)

1. FedRAMP package repository access: documentation submitted through FedRAMP Secure Repository
2. Third-Party Assessment Organization (3PAO): accredited 3PAO engaged for initial assessment
3. Continuous monitoring deliverables: monthly vulnerability scans, annual penetration test, monthly POA&M updates
4. FedRAMP Marketplace listing maintained once authorization achieved

FISMA vs ISO 27001 for Federal Contractors

The key practical difference for technology companies pursuing government contracts: ISO 27001 certification is a useful market signal to government buyers, but it does not satisfy FISMA requirements for systems that process federal information. A system operating federal data needs an ATO based on NIST SP 800-53 controls — ISO 27001 certification does not substitute. Many companies hold both: ISO 27001 for commercial and European clients, FedRAMP authorization for federal clients.

Real-World Use Cases

Cloud SaaS provider entering the federal market: A commercial SaaS company wants to offer its platform to federal agencies. It must achieve FedRAMP authorization — specifically, FedRAMP Moderate if the system processes data that could seriously adversely affect agency operations. The 3PAO conducts a full assessment against 325 controls. The process typically takes 12 to 18 months and costs USD 500,000 to USD 2 million in assessment, documentation, and remediation. The reward is access to a market that spends over USD 90 billion annually on IT.

Federal contractor operating agency systems: A consulting firm operating a financial management system on behalf of a cabinet agency must maintain a current ATO. The firm’s SSP documents all 800-53 controls, the monthly continuous monitoring reports go to the agency’s AO, and any significant system changes trigger a security impact analysis. When a subcontractor is added to the environment, an Interconnection Security Agreement (ISA) must be executed.

OMB Memorandum M-22-09 compliance: In January 2022, OMB issued M-22-09, “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles,” requiring agencies to meet specific NIST SP 800-207 Zero Trust Architecture milestones by the end of FY 2024. These milestones — MFA for all agency users, encrypted DNS traffic, endpoint detection and response — are implemented through specific NIST SP 800-53 controls and must be reflected in each system’s SSP.

Common Mistakes to Avoid

Using non-FIPS-validated cryptography. SC-13 is categorical: cryptographic operations on federal systems must use FIPS 140-2 or FIPS 140-3 validated cryptographic modules. Many commercial encryption libraries (OpenSSL, BoringSSL) are not FIPS-validated in their default configuration. Their FIPS-enabled builds, or government-specific distributions, are required. Using a library that has not been validated — even if it implements AES-256 correctly — is a finding under SC-13 that will block ATO.

Incomplete System Security Plan. The SSP is the single most important document for an ATO. Assessors review every control entry. Entries that say “Not applicable” without documentation of why, or “Planned” without implementation dates, produce findings. Every control in the selected baseline must have a complete, accurate implementation description. Vague entries like “The system uses encryption” are insufficient — the SCA needs to know the specific algorithm, the FIPS validation certificate number, and where it is applied.

No POA&M management. Every finding from an assessment that is not immediately remediated goes into the Plan of Action and Milestones. The POA&M must be updated monthly with remediation progress. An AO who reviews a POA&M that has not been touched in six months — with findings still at “open, in progress” — will question whether continuous monitoring is genuinely occurring. This can trigger a reevaluation of the ATO.

Getting Started

Determine your system’s impact level. Use FIPS Publication 199 and NIST SP 800-60 to categorize the information your system processes. This categorization drives every subsequent decision — it determines your control baseline, your assessment depth, and your continuous monitoring requirements.

If you are a cloud provider, begin the FedRAMP process by reviewing the FedRAMP Security Assessment Framework and engaging an accredited 3PAO for a readiness assessment. The 3PAO will identify gaps before the formal assessment — this is the most efficient way to reduce the time and cost of achieving authorization.

Build your SSP as a living document from day one. Do not wait until assessment time to document your controls. As you implement infrastructure and security controls, record them in the SSP. An SSP that reflects actual implementation is dramatically faster to assess than one written retroactively.

For the encryption controls required under SC-13 and SC-28, see FIPS 140-3 explained: what validation levels mean in practice. For the key management infrastructure behind NIST-required controls, read hardware security modules: HSM vs KMS explained. If you sell to the Department of Defense, CMMC compliance layers on top of the same NIST 800-171 control baseline; if you sell cloud services more broadly to federal agencies, see what FedRAMP authorization requires beyond FISMA itself.