You've accepted that FedRAMP 20x is coming, your 3PAO is already asking about OSCAL submissions, and you're tired of manually reconciling Word documents every time a control changes. What you need is a working OSCAL System Security Plan template you can customize and validate today.
This template provides the structural framework of an OSCAL-formatted SSP in JSON. You'll add your system details, map your controls, and produce a package that validates cleanly against NIST's published schemas without starting from scratch.
Purpose of the Template
This OSCAL SSP template implements the System Security Plan Model from NIST's OSCAL specification. It's designed for teams pursuing FedRAMP authorization (Rev5 or 20x) who need to produce a machine-readable SSP that:
- Validates against NIST's OSCAL SSP schema
- Integrates with FedRAMP PMO automated validation tools
- Supports continuous monitoring workflows that depend on structured data
- Eliminates manual re-keying when controls or baselines change
If you're still using legacy Word documents, this template positions you to migrate when FedRAMP 20x becomes mandatory for your authorization class. If you're already under 20x requirements, this is the structural foundation your submission package needs.
Prerequisites
Before customizing this template, ensure you have:
Technical requirements:
- A text editor that handles JSON (VS Code, Sublime, or similar)
- Access to NIST's OSCAL schema files for validation (available at NIST CSRC)
- A JSON validator or command-line tool to check schema compliance
Compliance context:
- Your system's authorization boundary documented (components, interfaces, data flows)
- The baseline you're implementing (FedRAMP Low, Moderate, or High)
- Control implementation details for each applicable control in your baseline
- Component ownership assignments (who implements which controls)
Optional but recommended:
- An OSCAL-native compliance platform that can ingest and maintain this data
- Your 3PAO's preferred submission format (some assessors have specific OSCAL tools they integrate with)
The Template
{
"system-security-plan": {
"uuid": "GENERATE-UUID-HERE",
"metadata": {
"title": "[Your System Name] System Security Plan",
"last-modified": "2024-01-15T00:00:00Z",
"version": "1.0",
"oscal-version": "1.0.4",
"roles": [
{
"id": "system-owner",
"title": "System Owner"
},
{
"id": "authorizing-official",
"title": "Authorizing Official"
}
],
"parties": [
{
"uuid": "GENERATE-UUID-HERE",
"type": "organization",
"name": "[Your Organization Legal Name]"
}
],
"responsible-parties": [
{
"role-id": "system-owner",
"party-uuids": ["PARTY-UUID-HERE"]
}
]
},
"import-profile": {
"href": "https://raw.githubusercontent.com/GSA/fedramp-automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_MODERATE-baseline-resolved-profile_catalog.json"
},
"system-characteristics": {
"system-ids": [
{
"identifier-type": "https://fedramp.gov",
"id": "[FedRAMP Package ID if assigned]"
}
],
"system-name": "[Your System Name]",
"description": "[Brief system description and mission]",
"security-sensitivity-level": "moderate",
"system-information": {
"information-types": [
{
"uuid": "GENERATE-UUID-HERE",
"title": "[Information Type 1]",
"description": "[Type description]",
"categorizations": [
{
"system": "https://doi.org/10.6028/NIST.SP.800-60v2r1",
"information-type-ids": ["C.2.8.12"]
}
],
"confidentiality-impact": {
"base": "fips-199-moderate"
},
"integrity-impact": {
"base": "fips-199-moderate"
},
"availability-impact": {
"base": "fips-199-moderate"
}
}
]
},
"security-impact-level": {
"security-objective-confidentiality": "fips-199-moderate",
"security-objective-integrity": "fips-199-moderate",
"security-objective-availability": "fips-199-moderate"
},
"status": {
"state": "operational"
},
"authorization-boundary": {
"description": "[Describe what is inside and outside the authorization boundary]"
}
},
"system-implementation": {
"users": [
{
"uuid": "GENERATE-UUID-HERE",
"title": "Application Administrator",
"role-ids": ["system-owner"],
"authorized-privileges": [
{
"title": "Full administrative access",
"functions-performed": ["System configuration", "User management"]
}
]
}
],
"components": [
{
"uuid": "GENERATE-UUID-HERE",
"type": "software",
"title": "[Component Name - e.g., Web Application Server]",
"description": "[Component description and role in system]",
"status": {
"state": "operational"
}
}
]
},
"control-implementation": {
"description": "Control implementation for [Your System Name]",
"implemented-requirements": [
{
"uuid": "GENERATE-UUID-HERE",
"control-id": "ac-1",
"statements": [
{
"statement-id": "ac-1_smt.a",
"uuid": "GENERATE-UUID-HERE",
"by-components": [
{
"component-uuid": "COMPONENT-UUID-HERE",
"uuid": "GENERATE-UUID-HERE",
"description": "[How this component implements AC-1.a]"
}
]
}
]
}
]
}
}
}
How to Customize It
Step 1: Generate UUIDs
Every uuid field requires a universally unique identifier. Use an online UUID generator or command-line tool (uuidgen on Linux/Mac, PowerShell's New-Guid on Windows). Do not reuse UUIDs across different objects.
Step 2: Replace placeholder text
Search for every bracketed placeholder [Your System Name], [Your Organization Legal Name], etc. Replace with your actual system details. The system-name field should match what you use in all other authorization documents.
Step 3: Set the correct baseline
The import-profile href points to the FedRAMP Moderate baseline. If you're implementing Low or High, update the URL to reference the correct baseline from FedRAMP's automation repository.
Step 4: Map your components
In system-implementation.components, add one entry per component in your authorization boundary. Each component needs a unique UUID, a type (software, hardware, service, policy, physical, process-procedure, or plan), and a description of its role.
Step 5: Document control implementations
For each control in your baseline, add an implemented-requirements entry. Reference the control ID exactly as it appears in NIST SP 800-53 Rev 5 (e.g., ac-2, sc-7). For controls with multiple statement parts (a, b, c), add separate statements entries and map each to the component UUID that implements it.
Step 6: Add responsible parties
In metadata.responsible-parties, map roles to party UUIDs. At minimum, you need a system owner and an authorizing official. If your organization has an ISSO, add that role and assignment.
Step 7: Categorize information types
In system-information.information-types, document every category of data your system processes. Use NIST SP 800-60 Vol 2 Rev 1 identifiers in the information-type-ids array. Set confidentiality, integrity, and availability impact levels based on your system's actual risk profile.
Validation Steps
Schema validation:
Download NIST's OSCAL SSP schema (JSON Schema format) from the NIST CSRC OSCAL releases page. Run your customized template through a JSON Schema validator. Fix any errors before submission. Common issues: missing required fields, incorrect UUID format, invalid enum values in impact levels.
FedRAMP-specific checks:
If you're submitting to FedRAMP, use the FedRAMP Automation repository's validation scripts. These catch FedRAMP-specific requirements that go beyond base OSCAL schema compliance (required metadata fields, specific baseline references, etc.).
Cross-reference integrity:
Every component-uuid referenced in control-implementation must match a UUID defined in system-implementation.components. Every party-uuid in responsible-parties must match a party defined in metadata.parties. Automated validators catch these, but manual review helps you understand the relationships.
Human readability test:
OSCAL is machine-readable, but it should still make sense to a human reviewer. Have someone unfamiliar with your system read the system-characteristics.description and authorization-boundary.description fields. If they can't understand what your system does and where the boundary sits, rewrite those sections before you validate controls.
Version control:
Commit this template to version control immediately after customization. OSCAL SSPs are living documents. You'll update control implementations, add components, and revise descriptions as your system evolves. Track those changes the same way you'd track code.
This template won't write your entire SSP for you, but it eliminates the structural guesswork. You're working with the same data model FedRAMP's automated validation tools expect, which means fewer rejection cycles and faster turnaround when controls change or assessors request updates.
For organizations managing multiple systems or overlapping frameworks, OSCAL-native tooling that maintains this structure automatically is worth the investment. Manual JSON editing works for initial setup; it doesn't scale when you're tracking ongoing changes across dozens of controls and multiple authorization boundaries.
