If your team is preparing for FedRAMP 20x certification or transitioning from Rev5, you'll need a Security Decision Record (SDR) that meets the machine-readable documentation requirements effective July 4, 2026. The SDR replaces the traditional System Security Plan as your living record of security decisions.
This template provides the structure FedRAMP expects, with guidance on what each section should contain and how to maintain it as JSON.
Purpose of the Template
The Security Decision Record documents every security decision made throughout your cloud service offering's lifecycle. It's not a one-time submission artifact but a continuously maintained record available in both human-readable and JSON formats.
Use the SDR to:
- Document implementation decisions for applicable FedRAMP rules
- Record Key Security Indicator (KSI) values and thresholds
- Map controls to FedRAMP requirements
- Demonstrate your security posture to agency customers
- Support Quarterly Reviews and Ongoing Certification Reports
The Consolidated Rules require Rev5 CSPs to achieve SDR compliance by January 1, 2027, with maintenance starting August 1, 2027. For 20x CSPs, the SDR is mandatory from the beginning of your certification path.
Prerequisites
Before building your SDR, ensure you have:
Technical foundation:
- JSON schema validation tools (FedRAMP publishes schemas for required artifacts)
- Automated pipeline to generate JSON from source documentation
- Version control system to track security decision changes
Content foundation:
- Your target Certification Profile (Type, Path, and Class)
- Complete inventory of applicable FedRAMP rules for your profile
- Current control implementation statements
- KSI definitions and current values
- Documentation of compensating controls or accepted risks
Process foundation:
- Change management workflow for SDR updates
- Review cycle to keep the SDR aligned with actual implementation
- Access controls for modifying security decisions
The Template
{
"sdr_metadata": {
"csp_name": "[Your organization legal name]",
"offering_name": "[Cloud service offering name]",
"certification_profile": {
"type": "[Rev5 or 20x]",
"path": "[Program or Agency]",
"class": "[A, B, C, or D]"
},
"sdr_version": "[Semantic version number]",
"last_updated": "[ISO 8601 date]",
"next_review_date": "[ISO 8601 date]",
"responsible_party": {
"name": "[Name]",
"role": "[Title]",
"contact": "[Email]"
}
},
"security_decisions": [
{
"decision_id": "[Unique identifier]",
"fedramp_rule": "[Rule identifier from Consolidated Rules]",
"decision_date": "[ISO 8601 date]",
"decision_summary": "[Brief description of what you decided]",
"implementation_approach": "[How you're implementing this requirement]",
"rationale": "[Why this approach satisfies the rule]",
"evidence_location": "[Where supporting evidence is stored]",
"related_controls": ["[Control IDs that implement this decision]"],
"last_validated": "[ISO 8601 date]",
"validation_method": "[How you confirmed this is still accurate]"
}
],
"key_security_indicators": [
{
"ksi_id": "[Identifier]",
"ksi_name": "[Descriptive name]",
"measurement_method": "[How you calculate this indicator]",
"current_value": "[Current measurement]",
"threshold": "[Acceptable range or limit]",
"last_measured": "[ISO 8601 date]",
"measurement_frequency": "[How often you measure]",
"responsible_team": "[Team that owns this KSI]"
}
],
"control_implementations": [
{
"control_id": "[Control identifier]",
"control_source": "[Framework: FedRAMP Rev5, NIST SP 800-53, etc.]",
"implementation_status": "[Implemented, Partially Implemented, Planned, Not Applicable]",
"implementation_statement": "[Detailed description of how you implement this control]",
"implementation_evidence": ["[Evidence artifact references]"],
"responsible_role": "[Role responsible for this control]",
"testing_frequency": "[How often you test this control]",
"last_tested": "[ISO 8601 date]",
"test_results": "[Most recent test outcome]",
"compensating_controls": ["[If applicable, controls that compensate for gaps]"]
}
],
"accepted_risks": [
{
"risk_id": "[Unique identifier]",
"risk_description": "[What the risk is]",
"affected_rules": ["[FedRAMP rules this risk relates to]"],
"acceptance_rationale": "[Why you're accepting this risk]",
"acceptance_date": "[ISO 8601 date]",
"accepted_by": "[Name and role of decision authority]",
"risk_level": "[Low, Moderate, High]",
"review_frequency": "[How often you reassess this decision]",
"next_review_date": "[ISO 8601 date]",
"conditions": "[Under what conditions this acceptance is valid]"
}
],
"change_log": [
{
"change_date": "[ISO 8601 date]",
"changed_by": "[Name and role]",
"change_type": "[Added, Modified, Removed]",
"affected_sections": ["[Which SDR sections changed]"],
"change_summary": "[What changed and why]",
"related_scn": "[If this change triggered a Significant Change Notification, reference it]"
}
]
}
Customizing the Template
Start with your Certification Profile. Your target class determines which FedRAMP rules apply. Class A requires fewer rules than Class D. Don't document decisions for rules that don't apply to your profile.
Map your existing controls first. If you're converting from Rev5, extract your control implementation statements into the control_implementations section. Each control should reference the security decisions that implement it.
Document decisions, not just implementations. The SDR isn't a copy of your policies. For each applicable FedRAMP rule, record what you decided, when, and why that decision satisfies the requirement. Document choices between multiple implementation approaches.
Link evidence systematically. Reference where evidence lives in your trust center. Use consistent naming conventions so evidence locations are machine-parseable.
Automate KSI collection. Your KSIs should come from monitoring systems, not manual surveys. If you're manually updating KSI values, improve your instrumentation. The measurement_method field should describe an automated process.
Treat accepted risks carefully. Every accepted risk needs a named decision authority and a review cycle. Indefinite risk acceptance without reassessment isn't managing it.
Keep the change log current. Log every update to a security decision. This becomes your audit trail. When an auditor asks about changes, the change log should provide immediate answers.
Validation Steps
Schema validation first. Validate the JSON against FedRAMP's published schema before considering your SDR complete. Invalid JSON means your SDR doesn't meet the machine-readable requirement.
Consistency check between formats. Ensure your human-readable and JSON versions contain the same information. Automate the generation of both from a single source. Manual synchronization will fail.
Completeness audit. For your Certification Class, identify every applicable FedRAMP rule. Confirm you have a security_decisions entry for each one. Missing rules are gaps in your certification package.
Evidence verification. Spot-check that evidence_location references are valid. If your SDR points to non-existent or inaccessible evidence, you have a documentation integrity problem.
Stakeholder review. Have technical leads review the implementation_approach fields for accuracy. Have your legal or compliance team review accepted_risks entries. The SDR is authoritative, so it needs to reflect actual decisions, not aspirational ones.
Test your update process. Make a test change to one security decision. Confirm your change management workflow triggers an SDR update, generates valid JSON, updates the change log, and publishes to your trust center. If any step fails, fix your process before you're under audit pressure.
Your SDR becomes the foundation for every other FedRAMP artifact you produce. Get it right, keep it current, and the rest of your certification maintenance becomes significantly more manageable.
