The Problem with Traditional SSPs
System Security Plans have traditionally been massive Word documents—hundreds of pages of text that become outdated the moment they're written. Security teams spend weeks manually documenting controls, only to repeat the process during every assessment cycle.
What is OSCAL?
Open Security Controls Assessment Language (OSCAL) is a standardized, machine-readable format for security documentation. Developed by NIST, OSCAL enables automation of security documentation and assessment processes that were previously manual and error-prone.
How Our Automation Works
Our OSCAL-native approach transforms how you create and maintain security documentation:
- Infrastructure Discovery: Automatically scan your cloud environments to identify systems, services, and configurations
- Control Mapping: Map discovered infrastructure to specific NIST 800-53 and FedRAMP control requirements
- SSP Generation: Generate machine-readable SSP documents in OSCAL JSON/XML format
- Continuous Updates: As your infrastructure changes, your documentation updates automatically
Key Benefits
Organizations implementing OSCAL-native documentation see dramatic improvements:
- 80% reduction in documentation creation time
- Real-time accuracy — documentation always reflects current state
- FedRAMP Marketplace ready — machine-readable artifacts for automated review
- Version control — track changes over time with git-like versioning
Integration with FedRAMP 20x
FedRAMP 20x emphasizes automation-first compliance. OSCAL is the foundation of this vision, enabling:
- Automated package validation by the FedRAMP PMO
- Continuous authorization through machine-readable evidence
- Faster agency reviews with standardized documentation formats
Getting Started
Transitioning to OSCAL-native documentation doesn't require a complete overhaul. We help organizations migrate incrementally, starting with high-impact control families and expanding coverage over time.
What Developing Compliance Actually Looks Like
Most compliance programmes are attempted backwards. The framework arrives, someone writes documentation describing how the controls are satisfied, and then the organization spends the next year trying to make reality resemble the document.
That order cannot work, and OSCAL makes the failure obvious rather than hiding it. You cannot generate machine-readable documentation from a system that does not consistently do the thing being documented. A Word SSP can describe an aspiration in careful language. A generated artifact just reports what is there.
So the sequence matters more than the tooling.
Start with identity
Before anything else is worth building, you need a reliable answer to who can reach what. Not a policy stating it — a system enforcing it, producing a record every time access is granted, changed, or revoked.
Everything downstream depends on this. An audit log is only meaningful if identity attribution is trustworthy. A configuration baseline means little if you cannot say who was authorized to change it. Teams that skip identity and start with the framework spend the rest of the programme writing documentation that rests on an assumption nobody has verified.
Then the building blocks
With identity solid, the fundamentals get built in dependency order rather than framework order:
- Logging and retention — events captured centrally, with enough fidelity to answer who did what, and held long enough to matter
- Configuration baselines — a defined intended state, and detection when reality diverges from it
- Change control — a record connecting every change to an authorization and an identity
- Secrets and key management — credentials with owners, rotation, and an audit trail
- Vulnerability management — a loop that closes, rather than a scanner producing reports nobody actions
None of these are compliance activities. They are basic security engineering, and an organization should want them whether or not an auditor is coming. That is the point — they are worth building on their own merits, and compliance is what you get downstream for free.
Then map to the framework
Only now does the documentation exercise become tractable, because each block is already emitting the evidence a control statement needs.
The identity layer answers most of IA and a large share of AC. Logging answers AU. Baselines and change control answer the bulk of CM. Vulnerability management answers RA and parts of SI. The mapping is a translation exercise against systems that already work, not a writing exercise describing systems you hope to build.
This is also where OSCAL stops being a format decision and becomes useful. When control implementations are generated from working systems, the documentation is current by construction. When they are written by hand about systems that may or may not behave as described, the format makes no difference — you have just made a stale document machine-readable.
What this means for sequencing
If you are early, resist the urge to start with the framework. Build identity, then the blocks, then map. The programme finishes sooner and the documentation is defensible because it describes something real.
If you already have a document-first programme in flight, the recovery is not to throw it out. It is to work backwards from the SSP, identify which control implementations describe systems that genuinely behave that way and which describe intent, and treat the second list as your engineering backlog rather than your documentation backlog.
We have done both, and the second is harder. Nobody enjoys being told that a chunk of finished documentation is actually a to-do list. It is still cheaper to hear it from us than from an assessor.
