OSCAL: The Complete Implementation Guide for FedRAMP Compliance

Your FedRAMP authorization package is about to become obsolete. On September 30, 2026, every cloud service provider must submit machine-readable authorization data to maintain FedRAMP certification. Word documents and Excel spreadsheets won’t cut it anymore.

The technology that makes this possible is OSCAL—the Open Security Controls Assessment Language. Developed by NIST in collaboration with industry, OSCAL transforms compliance documentation from static files into machine-readable, automatable data.

This guide covers everything you need to know: why it matters now, how it works in practice, the complete architecture, and exactly how to implement it.

Why OSCAL Matters Now
What is OSCAL?
The OSCAL Architecture
Practical Example: Inherited AWS Controls
Where OSCAL Data Goes
Deep Dive: The Nine Models
JSON Structure Reference
Tools and Platforms
Implementation Roadmap
Common Challenges and Solutions
Getting Started Today

Why OSCAL Matters Now

OSCAL has existed since 2019, but adoption was optional. That changed with FedRAMP RFC-0024, which mandates machine-readable authorization packages by September 2026.

The FedRAMP Mandate

RFC-0024 establishes clear requirements and penalties:

Deadline	Requirement
April 15, 2026	FedRAMP publishes supporting materials for OSCAL adoption
September 30, 2026	New authorization packages must be machine-readable
September 30, 2026	Annual assessments must include machine-readable updates
September 30, 2027	Non-compliant services lose FedRAMP certification

Penalties for Non-Compliance

Before September 30, 2027:

Public notification of non-compliance
Separate, lower-priority processing pipeline
90-day review window (vs. 30 days for compliant packages)

After September 30, 2027:

Complete revocation of FedRAMP certification
Full re-authorization required under current requirements

For Significant Change Violations:

Strike 1: Public notice + 3-month grace period
Strike 2: Immediate revocation + 3-month resubmission penalty

The Reality Check

Here’s the uncomfortable truth: In 2025, FedRAMP processed over 100 Rev5 authorizations without a single OSCAL submission. Even the FedRAMP 20x Phase 1 pilot participants didn’t use OSCAL for their machine-readable materials.

This gap between mandate and reality represents both a challenge and an opportunity. Organizations that invest in OSCAL now will have a significant advantage—and avoid scrambling as the deadline approaches.

Time and Cost Savings

Organizations using OSCAL-native tools report significant improvements:

Metric	Traditional	With OSCAL
SSP creation time	4-6 months	1-4 weeks
Assessment duration	2-4 months	2-4 weeks
Update turnaround	Weeks	Hours
Error rate	High (manual)	Low (automated validation)
Initial cost savings	Baseline	Up to 60% reduction
ConMon savings	Baseline	30-50% reduction

Some organizations report generating complete ATO packages in as little as 3.5 hours using automated OSCAL tools.

What is OSCAL?

OSCAL (Open Security Controls Assessment Language) is a set of standardized, machine-readable formats developed by NIST for expressing security control information. Available in XML, JSON, and YAML, OSCAL enables automation of security documentation, assessment, and continuous monitoring.

Think of OSCAL as a universal language for compliance. Just as HTML standardized web pages so any browser can render them, OSCAL standardizes security documentation so any compliant tool can process it.

The Core Problem OSCAL Solves

Traditional compliance documentation exists in Word documents, Excel spreadsheets, and PDFs. This creates several problems:

Problem	Impact
Manual updates	Changes require editing documents in multiple places
No validation	Inconsistencies go unnoticed until audit
Point-in-time snapshots	Documents become stale immediately after creation
Format incompatibility	Every organization uses different templates
Copy/paste inheritance	Control implementations copied between systems without traceability

OSCAL solves these problems by treating compliance data as structured information rather than narrative text. When compliance is data, you can:

Automatically validate completeness and consistency
Generate human-readable documents on demand
Track changes with version control (like code)
Import control implementations from component vendors
Enable continuous monitoring instead of annual assessments

OSCAL Formats

OSCAL content can be expressed in three equivalent formats:

JSON: Most common for APIs and modern tooling
XML: Best for document-centric workflows and XPath queries
YAML: Human-readable authoring format, often converted to JSON

All three formats are semantically equivalent—convert between them without data loss.

The OSCAL Architecture

OSCAL organizes its models into three layers, each building on the one below. This layered architecture enables traceability from assessment findings all the way back to the original control requirements.

Layer Overview

┌─────────────────────────────────────────────┐
│           ASSESSMENT LAYER                   │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│  │Assessment│  │Assessment│  │ POA&M   │     │
│  │  Plan   │  │ Results │  │         │     │
│  └─────────┘  └─────────┘  └─────────┘     │
├─────────────────────────────────────────────┤
│          IMPLEMENTATION LAYER                │
│  ┌───────────────────┐  ┌─────────────────┐ │
│  │ System Security   │  │   Component     │ │
│  │     Plan (SSP)    │  │   Definition    │ │
│  └───────────────────┘  └─────────────────┘ │
├─────────────────────────────────────────────┤
│            CONTROL LAYER                     │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│  │ Catalog │  │ Profile │  │ Mapping │     │
│  └─────────┘  └─────────┘  └─────────┘     │
└─────────────────────────────────────────────┘

The Nine Models

All nine OSCAL models have reached “Released” status:

Layer	Model	Purpose
Control	Catalog	Defines available security controls (e.g., NIST 800-53)
Control	Profile	Selects and tailors controls into a baseline
Control	Mapping	Relates controls across different frameworks
Implementation	System Security Plan (SSP)	Describes how a system implements controls
Implementation	Component Definition	Documents how components satisfy controls
Assessment	Assessment Plan	Defines assessment scope and activities
Assessment	Assessment Results	Records findings from assessments
Assessment	POA&M	Tracks remediation of identified issues

How Models Connect

Each model references others through imports and UUID links:

Catalog → Foundation containing all controls
Profile → Imports from Catalog, selects specific controls
SSP → Imports Profile as its baseline
Component Definition → Describes how components implement catalog controls
SSP → Imports Component Definitions for reusable implementations
Assessment Plan → References SSP to define scope
Assessment Results → Links to Assessment Plan and SSP
POA&M → Links to Assessment Results and SSP

This chain of references creates full traceability—you can trace any finding back to the original control requirement.

Practical Example: Inherited AWS Controls

Most FedRAMP systems inherit controls from their underlying infrastructure. Here’s how to document that your encryption control (SC-28) is inherited from AWS’s FedRAMP-authorized services.

Step 1: Reference the Leveraged Authorization

In your SSP, declare that you’re building on AWS’s existing FedRAMP authorization:

{
  "system-security-plan": {
    "system-implementation": {
      "leveraged-authorizations": [
        {
          "uuid": "aws-govcloud-auth-uuid",
          "title": "AWS GovCloud (US)",
          "date-authorized": "2023-06-15",
          "props": [
            {"name": "authorization-type", "value": "fedramp"},
            {"name": "impact-level", "value": "high"}
          ],
          "links": [
            {
              "href": "https://marketplace.fedramp.gov/products/...",
              "rel": "related"
            }
          ],
          "party-uuid": "aws-party-uuid"
        }
      ]
    }
  }
}

Step 2: Document the Inherited Control

For SC-28 (Protection of Information at Rest), show what AWS provides vs. what you implement:

{
  "control-implementation": {
    "implemented-requirements": [
      {
        "control-id": "sc-28",
        "statements": [
          {
            "statement-id": "sc-28_smt",
            "by-components": [
              {
                "component-uuid": "aws-kms-uuid",
                "description": "AWS KMS provides FIPS 140-2 validated encryption for all data at rest.",
                "inherited": {
                  "uuid": "inherited-sc28-uuid",
                  "provided-uuid": "aws-govcloud-auth-uuid",
                  "description": "Encryption at rest using AWS KMS is inherited from AWS GovCloud's FedRAMP High authorization."
                },
                "implementation-status": {"state": "implemented"}
              },
              {
                "component-uuid": "our-app-uuid",
                "description": "Application configures all S3 buckets and RDS instances to use KMS encryption with customer-managed keys.",
                "satisfied": {
                  "uuid": "satisfied-sc28-uuid",
                  "responsibility-uuid": "customer-key-mgmt",
                  "description": "Customer responsibility for key selection and access policies is satisfied through our key management procedures."
                },
                "implementation-status": {"state": "implemented"}
              }
            ]
          }
        ]
      }
    ]
  }
}

The Inheritance Flow

┌─────────────────────────────────────────────────────┐
│  AWS GovCloud FedRAMP Authorization (High)          │
│  ┌───────────────────────────────────────────────┐  │
│  │ SC-28: "AWS encrypts data at rest using       │  │
│  │        FIPS 140-2 validated modules"          │  │
│  └───────────────────────────────────────────────┘  │
└──────────────────────┬──────────────────────────────┘
                       │ INHERITED
                       ▼
┌─────────────────────────────────────────────────────┐
│  Your SaaS Application (Moderate)                   │
│  ┌───────────────────────────────────────────────┐  │
│  │ SC-28: "Inherited from AWS. We configure      │  │
│  │        KMS keys and enable encryption on      │  │
│  │        all storage resources."                │  │
│  └───────────────────────────────────────────────┘  │
└──────────────────────┬──────────────────────────────┘
                       │ INHERITED
                       ▼
┌─────────────────────────────────────────────────────┐
│  Agency Customer                                    │
│  ┌───────────────────────────────────────────────┐  │
│  │ SC-28: "Inherited from vendor. Agency         │  │
│  │        manages access to data."               │  │
│  └───────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────┘

Why This Matters

Instead of re-documenting AWS’s encryption implementation (which is already proven), you reference their authorization and focus on your responsibility:

Which KMS keys you use
How you configure encryption on your resources
What policies govern key access

This is exactly what OSCAL’s inherited and satisfied elements are designed for.

Where OSCAL Data Goes

You’ve written your OSCAL files. Now what happens to them?

The End-to-End Workflow

┌─────────────────────────────────────────────────────────────────┐
│  YOUR ORGANIZATION                                              │
│                                                                 │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────────────┐ │
│  │ Compliance  │    │   Git Repo  │    │  GRC Platform       │ │
│  │ Team writes │───▶│ (version    │───▶│ (RegScale, Paramify │ │
│  │ OSCAL JSON  │    │  control)   │    │  or similar)        │ │
│  └─────────────┘    └─────────────┘    └─────────────────────┘ │
│                                                 │               │
└─────────────────────────────────────────────────┼───────────────┘
                                                  │
                                                  ▼
┌─────────────────────────────────────────────────────────────────┐
│  FEDRAMP SUBMISSION                                             │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │ FedRAMP Repository / Package Upload                      │   │
│  │ - SSP.json                                               │   │
│  │ - SAP.json                                               │   │
│  │ - SAR.json (from 3PAO)                                   │   │
│  │ - POAM.json                                              │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                 │               │
└─────────────────────────────────────────────────┼───────────────┘
                                                  │
                                                  ▼
┌─────────────────────────────────────────────────────────────────┐
│  REVIEW PROCESS                                                 │
│                                                                 │
│  ┌──────────────┐   ┌──────────────┐   ┌──────────────┐        │
│  │   3PAO       │   │  FedRAMP PMO │   │   Agency     │        │
│  │  Assessment  │──▶│   Review     │──▶│   ATO        │        │
│  │              │   │              │   │   Decision   │        │
│  └──────────────┘   └──────────────┘   └──────────────┘        │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

How It Gets There

Step	Who	What Happens
1. Author	Your team	Write/generate OSCAL files (SSP, POA&M)
2. Validate	Your team	Run FedRAMP validators locally
3. Store	Your team	Commit to Git repo (version control)
4. Submit	Your team	Upload to FedRAMP repository
5. Assess	3PAO	Uses your OSCAL SSP, produces OSCAL SAR
6. Review	FedRAMP PMO	Automated validation + human review
7. Authorize	Sponsoring Agency	Issues ATO based on package

How It’s Reviewed

Automated Validation (Machine)

FedRAMP's tools automatically check:
├── Schema valid? (correct JSON structure)
├── All required fields present?
├── Control IDs match baseline?
├── Parameters within acceptable ranges?
├── Inherited controls properly linked?
└── No conflicting statements?

3PAO Assessment (Human + Machine)

Assessor does:
├── Pulls your OSCAL SSP
├── Compares claims to actual evidence
├── Tests controls (interview, examine, test)
├── Produces OSCAL Assessment Results
└── Findings link directly to SSP control IDs

FedRAMP PMO Review (Human)

PMO reviewer:
├── Sees automated validation results (pass/fail)
├── Reviews 3PAO findings
├── Checks for completeness
├── Flags issues back to you (via OSCAL POA&M)
└── Recommends authorization or remediation

The Key Difference from Word Documents

Old Way (Word)	New Way (OSCAL)
Reviewer reads 400 pages	Tool highlights changes since last review
”Did they address finding 47?” - search manually	Query: `poam-items[finding-uuid="47"].status`
”Is SC-28 implemented?” - Ctrl+F	Automated: `implemented-requirements[control-id="sc-28"].status`
Back-and-forth emails	Structured feedback in OSCAL format

Deep Dive: The Nine Models

This section provides detailed information about each OSCAL model for reference.

Control Layer

Catalog Model

The Catalog model represents a comprehensive collection of security controls. NIST maintains the official OSCAL catalog for SP 800-53 Rev 5.

A catalog includes:

Controls: The actual security requirements
Groups: Organizational structure (families like AC, AU, CA)
Parameters: Configurable values (organization-defined parameters)
Parts: Subdivisions of controls (statements, guidance, objectives)

{
  "catalog": {
    "uuid": "catalog-uuid",
    "metadata": {
      "title": "NIST SP 800-53 Rev 5",
      "oscal-version": "1.1.2"
    },
    "groups": [
      {
        "id": "ac",
        "title": "Access Control",
        "controls": [
          {
            "id": "ac-1",
            "title": "Policy and Procedures"
          }
        ]
      }
    ]
  }
}

Profile Model

The Profile model selects controls from catalogs and tailors them for a specific use case. FedRAMP baselines (Low, Moderate, High) are profiles.

Profiles can:

Import controls from catalogs or other profiles
Select specific controls to include
Modify control parameters and statements
Merge controls from multiple sources

Mapping Model

The Mapping model documents relationships between controls in different frameworks:

equivalent-to: Controls are semantically identical
subset-of: Source control is a subset of target
superset-of: Source control encompasses target
related-to: Controls are related but not equivalent

Implementation Layer

System Security Plan (SSP) Model

The SSP is the centerpiece of OSCAL for FedRAMP. It contains five major sections:

Metadata: Document information (title, version, dates, parties, roles)
Import Profile: Reference to the control baseline
System Characteristics: System description, boundaries, data types
System Implementation: Components, users, interconnections, inventory
Control Implementation: How each control is satisfied

For each control, the SSP describes:

Responsible roles: Who is accountable
Implementation status: Implemented, partial, planned, alternative, not applicable
Control origination: Provider, customer, shared, inherited
Description: How the control is implemented (at the statement level)

Component Definition Model

The Component Definition model describes reusable components and how they satisfy controls. Think of it as a “security specification sheet” for products.

Who creates them:

Vendors: Document how their products implement controls
Service providers: Describe their managed services
Policy owners: Define how policies satisfy requirements

When a system uses a component, the SSP author can import the component definition and pre-populate control implementations.

Assessment Layer

Assessment Plan Model

Describes what will be assessed, how, and by whom:

Import SSP: Reference to the system being assessed
Assessment subjects: What’s in scope
Assessment activities: Interview, examine, test procedures
Tasks: Scheduled assessment activities

Assessment Results Model

Documents findings from assessments:

Findings: Observations about control implementation
Observations: Specific evidence collected
Risks: Identified security risks

This model supports both point-in-time assessments and continuous monitoring.

POA&M Model

Tracks remediation of findings:

POA&M items: Issues requiring remediation
Origins: How issues were discovered
Remediations: Planned corrective actions
Risk log: History of risk decisions

JSON Structure Reference

Universal Elements

Every OSCAL document includes metadata:

{
  "metadata": {
    "title": "System Name - System Security Plan",
    "published": "2026-02-23T12:00:00Z",
    "last-modified": "2026-02-23T12:00:00Z",
    "version": "1.0.0",
    "oscal-version": "1.1.2",
    "roles": [
      {"id": "system-owner", "title": "System Owner"},
      {"id": "isso", "title": "Information System Security Officer"}
    ],
    "parties": [
      {
        "uuid": "party-uuid",
        "type": "organization",
        "name": "Acme Cloud Services"
      }
    ],
    "responsible-parties": [
      {"role-id": "system-owner", "party-uuids": ["party-uuid"]}
    ]
  }
}

UUID Requirements

Every content change requires:

New UUID for the root element
Updated last-modified timestamp

This enables tools to detect changes without reprocessing entire files.

SSP Skeleton

{
  "system-security-plan": {
    "uuid": "ssp-uuid",
    "metadata": {...},
    "import-profile": {
      "href": "fedramp-moderate-baseline.json"
    },
    "system-characteristics": {
      "system-name": "My Cloud System",
      "description": "Description of the system...",
      "security-sensitivity-level": "moderate",
      "status": {"state": "operational"},
      "authorization-boundary": {
        "description": "The boundary includes..."
      }
    },
    "system-implementation": {
      "users": [...],
      "components": [...],
      "inventory-items": [...]
    },
    "control-implementation": {
      "description": "Control implementation for...",
      "implemented-requirements": [...]
    }
  }
}

Back Matter for Resources

{
  "back-matter": {
    "resources": [
      {
        "uuid": "resource-uuid",
        "title": "System Architecture Diagram",
        "rlinks": [
          {"href": "./diagrams/architecture.png", "media-type": "image/png"}
        ]
      }
    ]
  }
}

Tools and Platforms

Open Source Tools

Trestle (OSCAL Compass)

The most comprehensive open-source OSCAL toolkit, contributed by IBM and now a CNCF sandbox project.

Features:

OSCAL SDK for Python
Command-line validation and transformation
GitOps workflow support (Agile Authoring)
Profile resolution
SSP generation from component definitions

GitHub: github.com/oscal-compass/compliance-trestle

Compliance-to-Policy (C2P)

Bridges OSCAL and policy-as-code engines:

Generates policies from OSCAL Assessment Plans
Produces OSCAL Assessment Results from policy engine outputs
Supports Kyverno, Open Policy Agent, Auditree

GSA FedRAMP Automation

Contains:

FedRAMP baselines in OSCAL format (Low, Moderate, High)
SSP, SAP, SAR, POA&M templates
Validation rules and conversion tools

GitHub: github.com/GSA/fedramp-automation

Commercial Platforms

RegScale: Built from the ground up on OSCAL with full schema support, OSCAL CLI, and continuous monitoring.

Paramify: Focused on SSP automation—import existing Word SSPs and auto-generate OSCAL. Their team achieved FedRAMP in 30 days using the platform.

DRTConfidence: Specializes in OSCAL conversion with a 4-step process: Extract, map, augment, validate.

Conversion Tools

OSCAL Converter (oscalconversion.com): Bi-directional conversion between OSCAL and FedRAMP Word templates.

GSA oscal-ssp-to-word: Renders OSCAL XML SSP to Word format, aligned with official FedRAMP templates.

Implementation Roadmap

Phase 1: Assessment (1-2 weeks)

Goal: Understand your current state

Inventory existing compliance documentation
Identify data locked in Word/PDF/Excel
Map current processes to OSCAL models
Assess team OSCAL knowledge

Phase 2: Foundation (2-4 weeks)

Goal: Establish OSCAL infrastructure

Select OSCAL tooling (open source or commercial)
Set up version control for OSCAL content
Download FedRAMP baselines and templates
Train team on OSCAL concepts

Phase 3: Conversion (4-8 weeks)

Goal: Convert existing SSP to OSCAL

Option A: Tool-assisted conversion using DRTConfidence, OSCAL Converter, or Paramify.

Option B: Clean-sheet authoring using FedRAMP template.

Option C: Component-based approach—define component definitions first, then assemble into SSP.

Phase 4: Automation (4-8 weeks)

Goal: Integrate OSCAL into development workflows

Create master compliance data source (YAML/JSON)
Build scripts to generate OSCAL artifacts
Implement CI/CD validation
Automate delta reports between versions

Phase 5: Continuous Compliance (Ongoing)

Goal: Maintain OSCAL as living documentation

Update OSCAL with every significant change
Run automated validation before merging
Generate human-readable docs on demand
Feed assessment results into POA&M workflow

Common Challenges and Solutions

Challenge: Legacy Data Migration

Problem: Control implementations in Word don’t map cleanly to OSCAL’s part-level granularity.

Solution: Break control responses into statement-level parts. Use OSCAL’s remarks field for narrative that doesn’t fit structured fields. Accept some manual restructuring as a one-time cost.

Challenge: Part-Level Control Structure

Problem: NIST 800-53 controls have nested parts (a, b, c, a.1, a.2, etc.) that OSCAL requires at the part level.

Solution: Review NIST OSCAL catalog for exact part IDs. Map responses to specific statement-id values. Use tools like Trestle that understand part hierarchy.

Challenge: Organization-Defined Parameters

Problem: ODPs are stored inconsistently or embedded in narrative.

Solution: Create a central parameter registry. Use OSCAL’s set-parameter consistently. Establish governance for parameter changes.

Challenge: Tool Selection

Problem: Many tools claim OSCAL support but vary in completeness.

Solution: Verify support for your specific models (SSP, POA&M, etc.). Test import/export with FedRAMP templates. Check OSCAL version support (1.1.2 is current).

Challenge: Organizational Adoption

Problem: Teams comfortable with Word resist change.

Solution: Emphasize time savings after initial learning curve. Provide markdown-based authoring (via Trestle) for familiar editing. Show generated Word output to demonstrate compatibility.

Getting Started Today

The September 2026 deadline is closer than it appears.

This Week

Download FedRAMP OSCAL templates from GSA
Install Trestle for validation
Review your current SSP structure vs. OSCAL requirements

This Month

Select your OSCAL tooling approach
Identify your most complex SSP for pilot conversion
Train key team members on OSCAL concepts

This Quarter

Convert one system’s SSP to OSCAL
Establish version control and governance
Begin CI/CD integration planning

Additional Resources

Official Documentation

GitHub Repositories

Summary

OSCAL transforms compliance from a documentation burden into a data-driven practice. With the September 2026 FedRAMP mandate, adoption is no longer optional—it’s required for continued certification.

The key takeaways:

The deadline is real. RFC-0024 mandates machine-readable packages by September 2026. Non-compliance means revocation.
Start with inheritance. Most of your controls are inherited from AWS, Azure, or GCP. Document that properly first.
OSCAL is a language, not a tool. You need tooling to work with it effectively.
The ecosystem is ready. Open source (Trestle) and commercial options are mature.
The workflow matters. Understand where your OSCAL data goes and how it’s reviewed.

The organizations that embrace OSCAL today will spend less time on paperwork and more time on security. Those that wait will face increasing pressure and diminishing options.

The clock is ticking. Time to start.

Table of Contents