GovSignals is the only FedRAMP High authorized AI platform for government contracting. We completed our own FedRAMP High System Security Plan — documenting approximately 370 controls across 20 families — as part of achieving authorization in November 2025. This guide explains what goes into an SSP, how to define your authorization boundary, and how using FedRAMP High authorized tools reduces the controls you need to document from scratch.
What Is a System Security Plan (SSP)?
A System Security Plan is the foundational document that describes how your organization implements security controls for a specific information system. It is not a policy manual or a checklist. It is the complete, auditable record of your security architecture — what controls you implement, how you implement them, who is responsible for each one, and what evidence proves they are working.
The SSP is required across every major defense compliance framework:
- FedRAMP authorization: Cloud service providers must submit an SSP to their authorizing agency or the Joint Authorization Board (JAB). The SSP is the primary document that 3PAOs assess during the authorization process.
- CMMC Level 2 certification: C3PAOs verify your SSP during assessment. Your SSP is where you document implementation of all 110 NIST 800-171 controls.
- DFARS 252.204-7012 compliance: The cybersecurity clause requires "adequate security" for covered defense information. Your SSP is the evidence that adequate security exists. Raytheon's $8.4 million False Claims Act settlement was triggered in part by running CUI through a system with no System Security Plan.
- NIST 800-171 self-assessment: Your SPRS score is derived from your SSP's documentation of control implementation status.
The SSP is what separates "we follow security best practices" from "here is exactly how we implement control AC-2 and who is responsible for enforcing it." Assessors, contracting officers, and C3PAOs do not care about your intentions. They care about your SSP.
What Goes Into a FedRAMP System Security Plan?
The FedRAMP SSP template — available on the FedRAMP Rev 5 documents and templates page — contains 17 major sections. Each section serves a specific purpose in documenting your security posture.
The 17 SSP Template Sections
| Section | Purpose |
|---|---|
| 1. Information System Name/Title | Unique system identifier used throughout authorization documentation |
| 2. Information System Categorization | FIPS 199 impact level (Low, Moderate, High) and justification |
| 3. System Owner | Organization and individual responsible for the system |
| 4. Authorizing Official | Federal official who accepts risk and grants the ATO |
| 5. Other Designated Contacts | ISSO, ISSM, and key security personnel |
| 6. Assignment of Security Responsibility | Who owns which security functions |
| 7. System Operational Status | Operational, under development, or undergoing modification |
| 8. Information System Type | Major application, general support system, or cloud service |
| 9. General System Description | System function, architecture overview, and purpose |
| 10. System Environment | Production, development, staging environments and their boundaries |
| 11. System Interconnections | Every external system that connects to yours, with ISA/MOU documentation |
| 12. Laws, Regulations, and Policies | Applicable compliance requirements (FISMA, NIST, DFARS, etc.) |
| 13. Minimum Security Controls | The control baseline applicable to your impact level |
| 14. Control Implementation Descriptions | The bulk of the SSP — how each control is implemented |
| 15. Appendices (A-M) | Supporting artifacts including the authorization boundary diagram, data flow diagrams, ports/protocols/services, and the Customer Responsibility Matrix |
| Appendix A | Authorization boundary diagram |
| Appendix J | Customer Responsibility Matrix (CRM) — critical for inherited controls |
The Control Implementation Descriptions: Where the Work Lives
Section 14 is where most of the SSP's substance resides. For a FedRAMP High SSP, this means documenting approximately 370 individual controls from NIST 800-53 Rev. 5. For each control, the SSP must document:
- How it is implemented. Not a restatement of the control requirement — a specific description of the technical, operational, or management mechanisms that satisfy it. "We use encryption" is insufficient. "Data at rest is encrypted using AES-256 via AWS KMS with FIPS 140-2 validated modules, keys rotated every 90 days per organizational policy CM-6" is what assessors expect.
- Who is responsible. Named roles, not vague team references. The SSP must identify whether the control is the responsibility of the CSP, the customer, or shared between them.
- What evidence supports it. Configuration screenshots, policy documents, scan results, audit logs. The SSP references this evidence; the 3PAO verifies it exists.
- Implementation status. Implemented, partially implemented, planned, or alternative implementation. Any control not fully implemented requires a corresponding POA&M entry.
For defense contractors writing their own SSPs against NIST 800-171, the same principle applies at a smaller scale: 110 controls, each documented with implementation details, responsible parties, and supporting evidence.
The Authorization Boundary: The Most Important Part of Your SSP
If you get one thing right in your SSP, make it the authorization boundary. The boundary defines exactly which systems, components, data flows, networks, and personnel are included in the authorization scope. Everything inside the boundary must meet the security baseline. Everything outside is excluded from the assessment — but any data flowing across the boundary must be documented and secured.
What the Boundary Includes
A properly defined authorization boundary encompasses:
- Hardware and infrastructure. Servers, network devices, storage systems, load balancers — whether physical or virtual.
- Software components. Operating systems, application code, databases, middleware, APIs, and third-party libraries.
- Data flows. How CUI and other protected information moves into, within, and out of the system. Data flow diagrams are a required SSP appendix (Appendix A).
- Network architecture. Subnets, VPCs, firewalls, and segmentation between system components. The boundary must show logical and physical network topology.
- Personnel. Roles with access to the system, including administrators, operators, and users.
- External connections. Every system interconnection that crosses the boundary — APIs, VPN tunnels, database replication, email gateways.
The Boundary Drawing Mistakes
Drawing the boundary too broadly. Including systems that do not need to be in scope increases cost and complexity. Every component inside the boundary must be assessed, monitored, and maintained to the applicable baseline. A contractor who includes their entire corporate IT environment in a FedRAMP boundary has created an assessment scope that will take months longer and cost significantly more than a properly scoped system.
Drawing the boundary too narrowly. Excluding components that handle protected data creates gaps. If CUI flows through a system that is outside your authorization boundary, you have an undocumented data path that assessors will flag — and adversaries will exploit. The most common version of this mistake: a contractor defines their boundary around their primary application but excludes the logging infrastructure, backup systems, or CI/CD pipeline that also touches CUI.
Ignoring the physical/logical distinction. FedRAMP requires both physical and logical boundary documentation. The physical boundary covers where your infrastructure lives — data center locations, rack assignments, physical access controls. The logical boundary covers how components interact — network segmentation, encryption boundaries, authentication domains. Cloud-native systems still have physical boundaries — they just inherit them from the infrastructure provider (AWS, Azure, GCP). Your SSP must document this inheritance.
Failing to document boundary changes. Authorization boundaries are not static. When you add a new microservice, migrate to a different database, or integrate a new external API, the boundary changes. Your SSP must be updated to reflect the current architecture. An outdated boundary diagram is one of the most common 3PAO findings during continuous monitoring reviews.
The authorization boundary is also the highest-value artifact for defense contractors writing SSPs for DFARS 252.204-7012 compliance. Contracting officers and C3PAO assessors will look at your boundary diagram first to understand the scope of your CUI environment. A clean, accurate boundary diagram signals a mature security program. A vague or missing one signals the opposite.
Inherited Controls: How FedRAMP High Tools Simplify Your SSP
This is where the SSP becomes a strategic document rather than just a compliance exercise. The shared responsibility model means that not every control in your SSP requires fresh implementation evidence from your organization. When you use a FedRAMP authorized cloud service, you inherit the controls that the CSP has already implemented and had assessed by a 3PAO.
How Control Inheritance Works
Every FedRAMP authorized CSP publishes a Customer Responsibility Matrix (CRM) — documented in Appendix J of their SSP. The CRM categorizes each control into one of three responsibility types:
| Responsibility Type | What It Means | SSP Impact |
|---|---|---|
| CSP-implemented (Inherited) | The CSP fully satisfies this control. The customer inherits it. | Your SSP references the CSP's authorization. No customer implementation needed. |
| Shared | Both the CSP and customer have responsibilities for this control. | Your SSP documents your portion. The CSP's portion is inherited. |
| Customer-implemented | The customer is fully responsible for this control. | Your SSP must document full implementation details and evidence. |
Why FedRAMP High Provides More Inherited Controls
FedRAMP High authorization requires approximately 370 controls from NIST 800-53 Rev. 5. FedRAMP Moderate requires approximately 287. The 83+ additional controls at High cover areas like advanced access control, enhanced audit capabilities, comprehensive supply chain risk management, and stronger incident response.
When a CSP holds FedRAMP High authorization, the controls available for customer inheritance are broader and deeper than what a Moderate-authorized CSP provides. Specifically:
- Physical and Environmental Protection (PE). A FedRAMP High authorized SaaS platform inherits PE controls from its infrastructure provider at the High baseline — data center physical security, environmental controls, power redundancy. Your SSP cites this inheritance rather than documenting physical security for cloud infrastructure you do not operate.
- Supply Chain Risk Management (SR). The SR family, added in NIST 800-53 Rev. 5, requires documented supply chain risk assessment, component authenticity verification, and provenance tracking. A FedRAMP High CSP has already satisfied these controls. Your SSP inherits them.
- Contingency Planning (CP). Backup, recovery, and continuity controls are implemented by the CSP at the High baseline, including geographically diverse failover and tested recovery procedures.
- Maintenance (MA). System maintenance controls — patching, update management, remote maintenance security — are the CSP's responsibility for their platform. Your SSP inherits them.
The practical impact: fewer controls in your SSP that require original implementation evidence. That means a shorter assessment timeline, lower remediation costs, and a cleaner POA&M. For defense contractors pursuing CMMC Level 2, this is significant — every inherited control is one less control your C3PAO needs to verify through your own evidence.
GovSignals' FedRAMP High Authorization and Your SSP
GovSignals holds FedRAMP High authorization — the highest baseline available under the FedRAMP program. For defense contractors using GovSignals for acquisition intelligence and proposal management:
- Your SSP can cite GovSignals' authorization for inherited controls. When documenting how you satisfy NIST 800-171 control 3.13.1 (boundary protection) or 3.13.8 (CUI encryption during transmission), you reference GovSignals' FedRAMP High authorization rather than building and documenting these controls independently.
- Assessors can verify inheritance against the FedRAMP Marketplace. GovSignals' authorization is listed on the FedRAMP Marketplace, providing C3PAOs and contracting officers with independent verification that the inherited controls claim is valid.
- The CRM documents exactly what you inherit. GovSignals' Customer Responsibility Matrix (Appendix J) specifies which controls are CSP-implemented, shared, and customer-implemented. No ambiguity about where GovSignals' responsibility ends and yours begins.
- FedRAMP High inheritance exceeds the DFARS minimum. DFARS 252.204-7012 requires FedRAMP Moderate as the floor. Inheriting controls from a FedRAMP High authorized platform means your SSP documents a stronger posture than the minimum — which matters when contracting officers evaluate your compliance documentation.
SSP and CMMC Level 2 Assessments
CMMC Level 2 requires third-party C3PAO assessment of all 110 NIST 800-171 controls. Your SSP is the document that C3PAOs use as the starting point for their assessment. A well-written SSP with clear control implementation descriptions, accurate boundary documentation, and properly cited inherited controls makes the assessment process faster and produces fewer findings.
What C3PAOs Look For in Your SSP
Control implementation specificity. For each of the 110 controls, the assessor verifies that your SSP describes the actual mechanism of implementation — not a restatement of the requirement. Vague descriptions generate findings. Specific descriptions with referenced evidence close controls.
Authorization boundary accuracy. The assessor compares your SSP's boundary diagram to your actual environment. Undocumented systems, missing data flows, or components that handle CUI but sit outside the boundary will be flagged.
Inherited controls documentation. For every cloud service in your CUI environment, assessors verify that the service holds FedRAMP authorization (or meets the DoD CIO's equivalency standard) and that your SSP accurately documents which controls are inherited. NIST 800-171 control 3.13.1 requires listing cloud services and their authorization status — C3PAOs verify this against the FedRAMP Marketplace.
POA&M status. Controls that are not fully implemented must have a Plan of Action and Milestones documenting the gap, the remediation plan, and the timeline. Under CMMC, POA&Ms must close within 180 days of assessment. An SSP with extensive unresolved POA&Ms signals an immature security program.
Evidence availability. The SSP references supporting evidence for each control — configuration files, policy documents, scan results, audit logs. C3PAOs will request this evidence during assessment. If your SSP claims a control is implemented but the evidence does not exist, the control fails.
Strengthening Your SSP With FedRAMP High Authorized Tools
Defense contractors using FedRAMP High authorized tools in their CUI environment produce stronger SSPs for one reason: verifiable inheritance. When your C3PAO asks "how do you satisfy this control for your acquisition intelligence platform?", the answer is not "we configured it ourselves and here are our screenshots." The answer is "this platform holds FedRAMP High authorization, assessed by an accredited 3PAO, with continuous monitoring. Here is the CRM documenting which controls we inherit." That is a fundamentally different evidentiary posture — and it is one that assessors trust because the underlying authorization has already been independently verified.
Common SSP Mistakes Defense Contractors Make
After completing our own FedRAMP High SSP and working with defense contractors navigating CMMC assessments, these are the mistakes we see most frequently.
1. Vague Authorization Boundary Definitions
"Our system includes servers, applications, and network components" is not a boundary definition. A proper boundary diagram names specific components, shows network topology, identifies data flows, and distinguishes between in-scope and out-of-scope systems. If an assessor cannot look at your boundary diagram and understand exactly what is being assessed, the diagram needs work.
2. Missing or Incomplete POA&Ms
A Plan of Action and Milestones is not a place to hide problems — it is a place to document remediation plans for known gaps. Every control that is not fully implemented needs a POA&M entry with a specific remediation date, responsible party, and resource requirements. Under CMMC, POA&Ms must close within 180 days. Leaving controls undocumented — neither implemented nor documented in a POA&M — is worse than having a POA&M, because it suggests the gap was not identified at all.
3. Undocumented Inherited Controls
This is the most common missed opportunity. Contractors use FedRAMP authorized tools but fail to cite them in the SSP as sources of inherited controls. If you run CUI through a FedRAMP High authorized platform and your SSP does not reference that authorization, you are doing extra work — documenting controls from scratch that you could have documented as inherited. Check GovSignals' CRM (Appendix J) and map every inheritable control into your SSP.
4. Outdated SSPs
An SSP is a living document. When you add a new cloud service, decommission a server, change your network architecture, or modify your access control policies, the SSP must be updated. FedRAMP requires annual SSP updates at minimum, with significant changes documented within 30 days. An SSP that describes your environment from two years ago is not an SSP — it is a liability. The DOJ's Civil Cyber-Fraud Initiative has made clear that outdated compliance documentation can trigger False Claims Act investigations.
5. Referencing "FedRAMP Equivalent" Tools Instead of Authorized Ones
The DoD CIO's December 2023 FedRAMP Equivalency memo redefined the standard: equivalency now requires 100% compliance with all FedRAMP baseline controls, validated by a FedRAMP-recognized 3PAO, with zero control-related POA&Ms. Self-attestation and SOC 2 reports do not satisfy this standard. Listing a "FedRAMP equivalent" tool in your SSP without 3PAO validation is a finding waiting to happen. The safer path: use tools with actual FedRAMP authorization listed on the FedRAMP Marketplace. No equivalency arguments needed, no documentation gaps, no assessment risk.
6. Treating the SSP as a One-Time Deliverable
The SSP is not a document you write once and file away. It is the operational record of your security program. Continuous monitoring reports feed into it. Incident response outcomes update it. Configuration changes modify it. Assessors return to it annually. Organizations that treat the SSP as a living, maintained document pass assessments. Organizations that treat it as a one-time compliance artifact fail them.
Frequently Asked Questions
What is a FedRAMP System Security Plan (SSP)?
A FedRAMP SSP is a comprehensive document that describes how a cloud service provider or organization implements security controls for a specific information system. For FedRAMP High authorization, the SSP documents implementation of approximately 370 NIST 800-53 Rev. 5 controls across 20 families. It includes the authorization boundary definition, system architecture, data flow diagrams, control implementation descriptions, and the Customer Responsibility Matrix. The SSP is the primary document assessed by 3PAOs during authorization.
How many sections are in the FedRAMP SSP template?
The FedRAMP Rev 5 SSP template contains 17 major sections plus appendices (A through M). Key sections include system categorization, authorization boundary, system environment, control implementation descriptions, and interconnection documentation. Appendix A contains the authorization boundary diagram and Appendix J contains the Customer Responsibility Matrix (CRM), which documents inherited, shared, and customer-implemented controls.
What is an authorization boundary in FedRAMP?
The authorization boundary defines exactly which systems, components, data flows, networks, and personnel are included in the scope of a FedRAMP authorization or CMMC assessment. Everything inside the boundary must meet the applicable security baseline. The boundary includes physical elements (data center locations, infrastructure) and logical elements (network segmentation, encryption domains, authentication boundaries). Properly defining the boundary is the single most important architectural decision in the SSP.
How do inherited controls reduce SSP complexity?
When you use a FedRAMP authorized cloud service, you inherit the controls that the CSP has already implemented and had assessed by a 3PAO. The CSP's Customer Responsibility Matrix (CRM) documents which controls are fully inherited, shared, or customer-implemented. Inherited controls do not require independent implementation evidence from your organization — you reference the CSP's authorization instead. FedRAMP High authorized tools provide more inherited controls than Moderate-authorized tools because the High baseline covers approximately 83 additional controls.
Do I need an SSP for CMMC Level 2?
Yes. CMMC Level 2 requires documentation of how you implement all 110 NIST 800-171 Rev. 2 controls, and the SSP is the standard vehicle for that documentation. C3PAO assessors use your SSP as the starting point for their evaluation. The SSP must include your authorization boundary, control implementation descriptions, POA&Ms for any gaps, and documentation of inherited controls from FedRAMP authorized cloud services in your CUI environment.
Build a Stronger SSP With FedRAMP High Inherited Controls
Every cloud service in your CUI environment is a line item in your SSP. GovSignals' FedRAMP High authorization means that line item comes with verified inherited controls at the highest federal baseline — reducing the controls you document from scratch and strengthening the evidence your C3PAO reviews.
See how GovSignals supports your SSP and compliance posture.