The problem this solves

Most SSPs are written once by a consultant or generated from a template, then left to age. By assessment day, the document describes an environment that no longer exists. Tools have changed, personnel have changed, controls have been implemented or modified. A C3PAO assessor reading an SSP that doesn't match what they observe in the environment doesn't just note the discrepancies. They treat the SSP itself as unreliable, which creates additional scrutiny across every section.

What Goes into the SSP

The SSP Export draws from every other module in the platform. The implementation statements come from the notes you entered in the Requirements Browser for each practice. The evidence index comes from the Evidence Manager. The policy references come from the Policy Generator. The POA&M summary comes from the POA&M Tracker. The system boundary description, asset inventory, and user roles come from the configuration data you entered during setup.

None of this requires a separate document-writing effort. The SSP is the output of the work you've already done in the platform. When any source data changes. A practice status is updated, an evidence artifact is added, a policy is regenerated. Exporting the SSP again produces a document that reflects the change.

Dashboard Requirements Evidence POA&M Reports

1TEN System Security Plan generated from live assessment data

SSP Structure and Export Format

The exported SSP follows the structure C3PAO assessors expect, based on the NIST SP 800-18 system security plan format and the CMMC Assessment Guide requirements. Assessors who receive a well-structured SSP before an assessment arrive with context. Which shortens interviews and reduces the number of requests for additional documentation.

The document exports to Word format for final review and signature. The implementation statement for each practice is drawn directly from the notes you entered. Per-practice, per-objective, specific to your environment. The SSP is version-stamped at export, and prior versions are retained to satisfy the CA.L2-3.12.4 requirement for periodic updates.

Dashboard Requirements Evidence POA&M Reports

1TEN SSP export showing the C3PAO-ready System Security Plan document

What the SSP Contains

*System description. Organization name, system name, system boundary, and operational environment
*CUI environment description. Where CUI is stored, processed, and transmitted within the boundary
*User types and privilege levels. Roles, access types, and authorization basis
*Per-practice implementation statements for all 110 CMMC Level 2 requirements. Drawn from Requirements Browser notes
*Responsible roles for each practice. Who owns implementation and ongoing operation of each control
*Evidence index. Complete list of artifacts linked in the Evidence Manager, organized by practice
*Policy references. The 14 domain policies from the Policy Generator cited by practice
*POA&M summary. Open items, scheduled completion dates, and point values for each gap
*Version stamp and export date. Demonstrates the SSP is a maintained, periodically updated document

SSP Sections and Data Sources

SSP Section	Source in 1TEN
System description and boundary	System configuration data entered during setup
CUI environment description	Asset Inventory and CUI data tracker
User types and privilege levels	User Management module
Per-practice implementation statements	Requirements Browser. Implementation notes per practice
Responsible roles	Requirements Browser. Owner assignment per practice
Evidence index	Evidence Manager. All linked artifacts by practice
Domain policy references	Policy Generator. All 14 domain policies
POA&M summary	POA&M Tracker. Open items with milestones and point values
Risk register summary	Risk Register. Open risks with mitigation status
Version history	Auto-generated at each export with timestamp

What this replaces

*Consultant-authored SSPs written once against a best-guess environment description that no longer matches reality by assessment day
*Template SSPs with generic implementation statements. "The organization implements access controls" with no specifics
*SSPs with no evidence index. Assessors must ask for documentation that should have been organized in advance
*Single-version SSPs with no update history. Failing CA.L2-3.12.4 before the assessor asks a single question
*SSPs maintained in Word files disconnected from the compliance program. Updated manually, always out of date relative to the actual posture
*SSPs that describe policies but don't reference where those policies are or link them to the practices they satisfy

Practices Satisfied

Practice ID	Description
CA.L2-3.12.4	Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.

Related Modules

Requirements Browser

The implementation notes you enter per practice in the Requirements Browser become the per-practice statements in the SSP. The section assessors read most carefully.

Policy Generator

All 14 domain policies generated by the Policy Generator are referenced and embedded in the SSP output.

Evidence Manager

Every artifact linked in the Evidence Manager appears in the SSP's evidence index. Organized by practice, ready for assessor review.

POA&M Tracker

Open POA&M items are summarized in the SSP with scheduled completion dates and point values. Giving assessors the gap picture upfront.