How to Convert Your SSP to OSCAL: A Step-by-Step Guide

To convert a Word/Excel System Security Plan (SSP) into OSCAL, you map your existing content into the six parts of the NIST OSCAL SSP model — metadata, import-profile, system-characteristics, system-implementation, control-implementation, and back-matter — then validate the result against FedRAMP's published constraints. The practical workflow is: start from FedRAMP's OSCAL SSP template, point it at the correct OSCAL baseline (Low, Moderate, High, or LI-SaaS), move each control narrative into an implemented-requirement, and run the FedRAMP validation rules until the file is clean. OSCAL is a structured data format, not prose, so the real work is re-expressing what you already wrote — not rewriting it.

Key takeaways

• OSCAL is NIST's machine-readable standard (XML, JSON, or YAML) for security documentation; FedRAMP publishes OSCAL templates, a registry of extensions, and validation rules on top of it.
• A FedRAMP OSCAL SSP has six top-level sections; the bulk of conversion effort lands in control-implementation, where each control narrative becomes an implemented-requirement.
• FedRAMP's OSCAL work targets a specific NIST OSCAL version (the published FedRAMP release was built on OSCAL 1.0.4), so always match your tooling to the version FedRAMP supports.
• You do not start from a blank file: begin from the FedRAMP OSCAL SSP template and the matching OSCAL baseline so identifiers and extensions line up.
• Validation is non-negotiable — a file that opens fine in a text editor can still fail FedRAMP's Schematron constraint checks.

What does "convert an SSP to OSCAL" actually mean?

It means re-expressing the same facts your Word SSP and Excel workbooks already contain as structured OSCAL data, so that machines — assessors' tools, the FedRAMP review pipeline, and your own automation — can read and validate them directly.

A traditional SSP is a narrative document: headings, tables, and paragraphs meant for a human reader. OSCAL is the opposite. It stores the same information as typed, addressable data: the authorization boundary, information types and impact level, the system inventory, responsible roles, control parameters, and a per-control description of how each requirement is satisfied. Because every element has a stable identifier, an OSCAL SSP can be diffed, queried, and checked against rules in ways a Word file never can.

If you want the conceptual background first — what OSCAL is, why NIST built it, and how the layers fit together — read our companion explainer, OSCAL for FedRAMP explained. This post assumes you already have an SSP and want to move it into OSCAL.

	Word/Excel SSP	OSCAL SSP
Format	.docx narrative + .xlsx workbooks	XML, JSON, or YAML data
Audience	Human readers	Tools, validators, and humans (via rendering)
Control content	Prose paragraphs in Appendix A	implemented-requirement per control, addressable to the statement level
Identifiers	Section numbers, manual cross-refs	UUIDs and tokens with referential integrity
Validation	Manual review / checklists	Automated schema + FedRAMP constraint checks
Updates	Track-changes, version copies	New document UUID + last-modified timestamp on every change

Source: NIST OSCAL — System Security Plan (SSP) Model

What is the OSCAL SSP model structure?

The OSCAL SSP model is organized into six top-level sections, in this order. Knowing them is the map for the entire conversion.

1. metadata — document title, version, publication date, OSCAL version, plus the roles, parties (people, teams, organizations), and locations referenced elsewhere in the file. Required in every OSCAL model.
2. import-profile — a pointer to the control baseline your system claims, expressed as an OSCAL profile. For FedRAMP this is the Low, Moderate, High, or Tailored LI-SaaS baseline.
3. system-characteristics — the system's name, description, authorization boundary, information types, security categorization/impact level, and status.
4. system-implementation — how the system is deployed: users and their roles, components, interconnections, services, and the system inventory.
5. control-implementation — one implemented-requirement per control in the baseline, describing how the control is satisfied. Satisfaction can be described for the whole system or attributed to specific components, down to an individual control statement, and can carry parameter values, responsible roles, implementation status, and control origination.
6. back-matter — attachments, citations, and embedded resources (diagrams, policies, and other referenced files).

Two NIST rules matter from the start: every time the file's content changes, you must generate a new document-level UUID on the root element and update the last-modified timestamp in metadata. Those two values are how tools detect that a file has actually changed.

Source: NIST OSCAL — SSP Model Overview

How do you convert an SSP to OSCAL, step by step?

Step 1 — Understand the target and pick your OSCAL version

Before touching your content, decide which OSCAL version you're producing and confirm it matches what FedRAMP supports. FedRAMP's published OSCAL release was built on NIST OSCAL 1.0.4, and the program only supports data at or above the minimum version it tags. Producing a file against the wrong version is the easiest way to fail review before anyone reads a single narrative. Read the NIST SSP model reference and FedRAMP's guidance so you know exactly what the finished file must contain.

Step 2 — Choose your tooling

You have three broad options, and most teams combine them:

• Start from FedRAMP's OSCAL templates. FedRAMP publishes pre-populated SSP, SAP, SAR, and POA&M template files in XML, JSON, and YAML, seeded with FedRAMP extensions, defined identifiers, and conformity tags. This is the recommended starting point because it bakes in the FedRAMP-specific structure you'd otherwise have to reverse-engineer.
• Use NIST and open-source tooling. NIST provides XML-to-JSON and JSON-to-XML converters and schema files, so you can author in whichever serialization you prefer and convert losslessly.
• Generate from system data. Rather than hand-typing thousands of lines, derive the OSCAL SSP programmatically from your inventory, identity provider, and cloud configuration. This is where automation earns its keep (more below).

Pick one serialization to author in — JSON and YAML are friendlier to hand-edit than XML — knowing you can convert with NIST's official converters at any time.

Step 3 — Map system characteristics and implementation

Move the descriptive parts of your SSP first, because they're the most mechanical:

• From your SSP front matter and identification tables → populate system-characteristics (system name, description, boundary, information types, impact level).
• From your inventory workbook and architecture sections → populate system-implementation (components, users/roles, interconnections, services, inventory items).
• From your points-of-contact tables → populate metadata roles and parties, then reference those party UUIDs wherever a responsible role is named.

Get identifiers right here. Roles, parties, and components you define in this step are referenced by UUID throughout control-implementation, and FedRAMP's validators check that every reference resolves.

Step 4 — Map your control implementations

This is the heart of the conversion and where the most time goes. For each control in your baseline:

• Create an implemented-requirement keyed to the control's ID (e.g., ac-2).
• Move the corresponding Appendix A narrative into the implementation description.
• Attribute satisfaction to the right components using by-component, rather than describing everything at the system level, when a specific component does the work.
• Set the implementation status, control origination (system-specific, inherited, hybrid, etc.), and any parameter values the baseline expects.
• Where the baseline defines named statements within a control, attach narratives to the matching statement so detail lands at the right granularity.

A clean, specific narrative converts well; a vague one ("we follow industry best practices") converts into a vague OSCAL field that an assessor still can't test. Conversion is a good moment to tighten weak narratives, not just relocate them.

Step 5 — Wire up the baseline (import-profile) and back-matter

Set import-profile to the correct FedRAMP OSCAL baseline — Low, Moderate, High, or Tailored LI-SaaS — published in the FedRAMP automation repository. This is what lets a validator confirm that every control-id and param-id you reference actually exists in the baseline. Then move diagrams, policies, and other attachments into back-matter as resources, and link to them by UUID from the relevant sections.

Step 6 — Validate against FedRAMP constraints

Schema-valid is not the same as FedRAMP-valid. FedRAMP publishes its rules as Schematron validations (the FedRAMP ASAP rule set) in the GSA automation repository, with browsable rule documentation and an in-browser validator. Run your file through two layers:

1. NIST schema validation — confirms the file is well-formed OSCAL for the SSP model.
2. FedRAMP constraint validation — confirms FedRAMP-specific requirements: extensions present, required identifiers used, references resolving, accepted values respected.

Fix every error, regenerate the document UUID and last-modified on each change, and repeat until clean.

Step 7 — Export, package, and submit

Once validation passes, produce the serialization FedRAMP expects (you can convert between XML and JSON with NIST's converters), package the OSCAL SSP with its companion artifacts, and submit through your authorization path. Because the package is now data, downstream artifacts — the SAP, SAR, and POA&M — can reference the same identifiers, keeping the whole package internally consistent. If you need a refresher on how those documents relate, see FedRAMP documentation explained.

What are the most common SSP-to-OSCAL pitfalls?

The failures we see most often are mechanical, not conceptual:

• Wrong OSCAL version. Authoring against a NIST version FedRAMP doesn't support, then discovering it at submission time.
• Starting from a blank file. Skipping the FedRAMP template means re-inventing extensions and identifiers, and missing FedRAMP-specific fields entirely.
• Broken references. A component-uuid, party-uuid, or role-id that points at nothing. The schema may pass; FedRAMP's constraint checks will not.
• System-level dumping. Putting every narrative at the system level instead of attributing it to the component that implements it, which loses the traceability OSCAL exists to provide.
• Forgetting the UUID/last-modified discipline. Editing content without minting a new document UUID and timestamp, which breaks change-detection for any tool consuming the file.
• Treating conversion as a one-time event. An OSCAL SSP that drifts from the running system is just a Word SSP with angle brackets.

How does automation generate and maintain an OSCAL SSP?

The most durable way to "convert" an SSP is to stop treating it as a document you transcribe and start treating it as a report generated from your system's actual state. This is the angle Boundera is built around.

Much of an OSCAL SSP is derivable from sources you already operate: your cloud accounts describe the boundary and inventory, your identity provider describes users and roles, and your configuration management describes how technical controls are implemented. An automation layer can read those sources and emit the system-characteristics, system-implementation, and large parts of control-implementation directly — with consistent UUIDs and FedRAMP extensions already in place — then run the FedRAMP validations on every build.

The payoff isn't the first conversion; it's the second hundred. When your system changes, the OSCAL SSP regenerates from current data instead of being hand-patched, the document UUID and last-modified update automatically, and your narratives stay aligned with reality through continuous monitoring. The same source-of-truth approach extends to evidence — see how teams automate KSI evidence for FedRAMP 20x.

Frequently asked questions

Do I have to rewrite my SSP from scratch to use OSCAL?

No. OSCAL conversion is about re-expressing the facts your existing SSP already contains as structured data, not authoring new content. You map your boundary, inventory, roles, and control narratives into the OSCAL SSP model's six sections. It is, however, a good opportunity to tighten vague narratives, since weak prose converts into weak OSCAL.

What format should I author my OSCAL SSP in — XML, JSON, or YAML?

Author in whichever serialization your tooling and team prefer; NIST provides official converters between XML and JSON, so the choice isn't permanent. JSON and YAML are generally easier to read and hand-edit than XML. FedRAMP publishes its templates in all three formats.

Which OSCAL version does FedRAMP require?

Match your tooling to the version FedRAMP supports — its published OSCAL release was built on NIST OSCAL 1.0.4, and FedRAMP only supports data at or above its tagged minimum version. Because NIST issues periodic syntax updates, always check the current NIST OSCAL release notes alongside FedRAMP's guidance before you build.

How do I validate a FedRAMP OSCAL SSP?

Validate in two layers. First, check the file against NIST's OSCAL SSP schema to confirm it's well-formed OSCAL. Second, run FedRAMP's Schematron constraint rules (the FedRAMP ASAP rule set in the GSA automation repository) to confirm FedRAMP-specific requirements — extensions, identifiers, references, and accepted values. The repository includes browsable rule documentation and an in-browser validator.

Where do FedRAMP's OSCAL templates and validation rules live?

In the GSA fedramp-automation repository on GitHub, which hosts the FedRAMP OSCAL SSP/SAP/SAR/POA&M templates, the FedRAMP OSCAL Registry of extensions and identifiers, the OSCAL baselines, and the Schematron validation rules. Note that this repository was archived in mid-2025, so always confirm you're working from the version and guidance FedRAMP currently points to.

Can I generate an OSCAL SSP automatically instead of building it by hand?

Yes. Because much of the SSP is derivable from system data — cloud inventory, identity provider, configuration management — automation can generate the bulk of system-characteristics, system-implementation, and control-implementation and keep them current as the system changes. That turns the OSCAL SSP from a document you maintain into a report you regenerate.

Does converting to OSCAL change my FedRAMP designation?

No. OSCAL is a format for your documentation, not a different authorization. Your designation is the same single label — FedRAMP Certified — whether you take the Rev 5 or 20x path, and OSCAL simply makes the package machine-readable for review and continuous monitoring.

Sources

• NIST OSCAL — System Security Plan (SSP) Model
• NIST OSCAL — Layers and Models overview
• GSA FedRAMP Automation repository (templates, registry, baselines, validation rules)
• FedRAMP — Using the FedRAMP OSCAL Resources and Templates

---

Last updated: June 2026. Written by the Boundera team.