Documentation & Narratives
The artifacts that get reviewed during an audit — SSP narratives, OSCAL output, interview records, and POA&Ms. Every lesson produces a real document you can submit.
SSP Narrative Writing
Write control narratives that pass CCA review
SSP narratives fail CCA review for one reason: they describe intent instead of implementation. "The organization monitors access" tells an assessor nothing. "The Security team reviews Splunk access alerts daily at 9 AM, with findings logged in Jira within 2 hours" — that passes. Specificity is the only standard.
Write a single control family narrative
Feed in the control family and your actual tool stack. Returns present-tense, first-person-plural narratives for each practice — the format that passes CCA review and provides evidence anchors.
Write an SSP system description narrative for a CMMC L2 control family.
CONTROL FAMILY: [e.g., "AC — Access Control"]
ORG TOOL STACK:
- Identity and Access: [e.g., "Okta for SSO and MFA, Azure AD for directory"]
- Endpoint: [e.g., "CrowdStrike Falcon"]
- Cloud: [e.g., "Azure (primary), AWS S3 for backups)"]
- Ticketing: [e.g., "Jira for IT requests"]
- Monitoring: [e.g., "Splunk SIEM"]
Write in present tense, first person plural ("The organization...").
For each CMMC L2 practice in this family:
1. Implementation narrative (3–5 sentences): Who does what, using which tool, how often, with what evidence
2. Responsible role: [specific role title — not "management"]
3. Evidence reference: [specific artifact — policy name, tool export, screenshot type]
Quality bar for each sentence: Could this be tested? Could an assessor pull the evidence you're describing?
Mark any practice where implementation is partial with "[PARTIAL — see POA&M]".Self-review checklist for narrative quality
Before submitting any SSP narrative, run the 10-question self-review. This catches the vague language and missing evidence anchors that lead to CCA questions and finding upgrades.
Review this SSP control family narrative for quality and completeness against CMMC L2 assessment standards. NARRATIVE: [paste the SSP narrative to review] CONTROL FAMILY: [family name] Apply this 10-question quality checklist: 1. Does every sentence describe a specific, observable action? (Not "we monitor" but "we review X via Y every Z") 2. Is there a named responsible role for every control? 3. Are tools/systems named specifically? (Not "our SIEM" but "Splunk Enterprise") 4. Are frequencies specified? (daily, weekly, quarterly, annually, per event) 5. Is evidence explicitly referenced? (policy doc name, tool export type, screenshot) 6. Is the narrative in present tense throughout? 7. Are any practices described as "planned" without a POA&M reference? 8. Does the narrative address all AOs for this practice, not just the practice title? 9. Is there any language that contradicts the evidence you actually have? 10. Would a CCA who has never seen this system understand exactly what to test? For each failed check: quote the specific sentence and suggest the rewrite. Overall narrative score: Pass / Conditional Pass (minor fixes) / Fail (major revision needed)
Vague language is contagious. One "we monitor access regularly" in a narrative signals to a CCA that the whole document is aspirational rather than descriptive — and they will probe deeper everywhere. The moment you find yourself writing "we ensure" or "management reviews", stop and rewrite with a specific actor, tool, frequency, and evidence artifact. Concrete details are what separate an SSP from a policy.
OSCAL Generation
Convert SSP narratives to machine-readable JSON
OSCAL (Open Security Controls Assessment Language) is the machine-readable format DoD and FedRAMP are moving toward for SSP submission. Knowing how to generate it means your narrative work doubles as structured data — and you can automate gap tracking against it.
Convert a single narrative to OSCAL JSON
Feed in one control implementation narrative. Returns an OSCAL Component Definition JSON block you can validate against the NIST OSCAL schema before submitting.
Convert this SSP control implementation narrative to OSCAL Component Definition JSON format (NIST OSCAL 1.1.2).
CONTROL: [e.g., "AC.L2-3.1.1"]
COMPONENT: [e.g., "Okta Identity Platform"]
NARRATIVE:
[paste the SSP implementation narrative for this control]
Generate the OSCAL component-definition JSON block including:
- component: title, description, type (software / policy / process / hardware)
- control-implementations array:
- source: NIST SP 800-171 catalog reference
- implemented-requirements:
- control-id
- description (the narrative)
- set-parameters (if applicable)
- implementation-status: implemented | partial | planned | not-applicable
- responsible-roles
Format as valid JSON. Include the uuid fields (use placeholder UUIDs formatted correctly).
Note any fields where you need real data from the client to complete the entry.Generate a full control family OSCAL file
From multiple component narratives, assemble a complete OSCAL Component Definition document covering a full control family — ready for oscal-cli validation.
Generate a complete OSCAL Component Definition JSON document for a control family. CONTROL FAMILY: [e.g., "AC — Access Control, NIST 800-171"] COMPONENTS: 1. [Component name]: [brief description and what controls it implements] 2. [Component name]: [brief description] [add as many as needed] SSP NARRATIVES BY CONTROL: [paste the implementation narratives organized by practice ID] Generate a valid OSCAL component-definition document with: - metadata block (org name, last-modified, version, oscal-version: 1.1.2) - components array (one entry per component) - Each component's control-implementations referencing the correct NIST 800-171 controls - implementation-status for each control After the JSON: - List of oscal-cli validation commands to run - Fields that will fail schema validation if left as placeholders - Which controls need additional properties (set-parameters) for this family
Validate against oscal-cli before submitting. OSCAL JSON that looks correct fails schema validation on subtle issues — wrong UUID format, missing required fields, incorrect reference URIs. The command is: oscal-cli component-definition validate [file].json. Run it before every submission. A validation failure on a government portal submission can delay your assessment by weeks.
Interview → AO Mapping
Turn raw interview notes into AO conformity records
Raw interview notes from an assessment session need to be structured into AO-level conformity records before they can drive a finding. This is the step most junior assessors skip — and it's why their interviews generate vague supporting evidence instead of specific findings.
Map interview notes to AOs
Paste raw interview notes and get back a structured table mapping every substantive statement to a specific AO, with preliminary conformity determination and follow-up actions flagged.
Here are raw interview notes from a CMMC L2 assessment interview. Map each statement to a specific NIST 800-171A Assessment Objective. INTERVIEWEE: [role — e.g., "IT Director"] CONTROL FAMILIES COVERED: [e.g., "AC, IA, AU"] RAW NOTES: [paste your raw interview notes — fragments, quotes, observations, anything you captured] For each substantive statement in the notes: | AO ID | AO Description | Interviewee Statement (verbatim or paraphrased) | Assessment Method (I = Interview) | Preliminary Finding | Follow-up Needed? | Preliminary Finding options: Met | Not Met | Partial | Insufficient Info Follow-up needed: Yes (describe what) | No After the table: - AOs from the covered families with NO interview evidence (need to address) - Statements that contradict each other or the SSP narrative - Highest-confidence Met findings (strong verbal evidence) - Highest-risk Not Met signals (statements indicating control failure)
Generate follow-up question bank from gaps
From the mapping, build a targeted follow-up question list for the next session — focused on the AOs with insufficient evidence or contradictory statements.
Based on this interview AO mapping, generate a follow-up question bank for the next assessment session. AO MAPPING OUTPUT: [paste the mapping table from the previous prompt] OUTSTANDING ISSUES: - AOs with Insufficient Info: [list from mapping] - AOs with contradictory evidence: [list from mapping] - AOs with no interview evidence: [list from mapping] For each outstanding AO, generate: 1. Follow-up interview question (specific, not leading) 2. The evidence I should request to corroborate the interview response 3. The test procedure that would confirm the AO Met or Not Met independent of the interview Format by AO, sorted by risk level (highest risk first). Note: Which of these could be resolved via document review vs. requiring another interview?
One interview is never sufficient to determine a finding — it's one assessment method. NIST 800-171A requires examine, interview, and test for complete AO coverage. An interviewee telling you a control is in place means you still need to examine the policy and test the implementation before marking it Met. Interview evidence upgrades confidence; it doesn't replace the other methods. Document which methods you used for each AO in your workpapers.
POA&M Development
Build a DoD-compliant POA&M from gap analysis
A Plan of Action and Milestones is a formal commitment to remediate findings — not a get-out-of-jail-free card. For CMMC conditional certification, a POA&M extends the certification window for eligible practices only. Every entry needs to be specific, scheduled, and defensible.
Populate the POA&M template
Feed your gap analysis findings. Returns a DoD-format POA&M with all required fields populated — including the practices that cannot be on a POA&M for conditional certification.
Create a DoD-format POA&M for CMMC L2 based on these gap findings. GAP FINDINGS: [paste your Not Met and Partially Met practices from the gap analysis] CLIENT CONTEXT: - Org name: [name or "Client"] - Assessment date: [date] - Certification target: [date] - Current SPRS score: [score] For each eligible Not Met practice, generate a POA&M entry: | Weakness ID | Practice ID | Practice Name | Weakness Description | Point Value | Resources Required | Scheduled Completion | Milestones (30/60/90 day) | Status | POA&M Eligible? | POA&M Eligible = Yes only for practices not in the ineligible list. Mark clearly: "NOT ELIGIBLE FOR POA&M — must be Met at assessment time." Practices ineligible for CMMC POA&M include (but may not be limited to): - Any practice with critical infrastructure impact as defined by DoD - Practices where C3PAO has determined immediate risk After the table: - Total practices on POA&M - Projected SPRS score at assessment with POA&M practices scored as planned - SPRS score if all POA&M items are completed before assessment
Build the milestone schedule
Each POA&M item needs a milestone schedule — not just a completion date. This generates the 30/60/90/180-day milestone breakdown DoD expects to see.
Build a detailed milestone schedule for each POA&M item. POA&M ENTRIES: [paste the POA&M table from the previous prompt] CERTIFICATION TARGET DATE: [date] For each POA&M item, generate a milestone schedule: | Weakness ID | Practice | Milestone 1 (30 days) | Milestone 2 (60 days) | Milestone 3 (90 days) | Final Completion | Owner (role) | Evidence of Completion | Milestone descriptions should be specific actions — not "make progress on AC.L2-3.1.1" but "Complete access control policy review and CISO sign-off; Okta MFA configured for 100% of users in scope." Evidence of completion: the specific artifact that proves each milestone is done. After the schedule: - Critical path items (milestones that gate other milestones) - Resource conflicts (multiple high-effort items in the same 30-day window) - Milestones that require vendor action (longest lead times)
A POA&M does not change the assessment score — this is the most important client education point in the whole engagement. At assessment time, Not Met practices are still scored Not Met, regardless of whether they're on a POA&M. The POA&M enables conditional certification, not a score override. Clients who think their POA&M "fixes" their SPRS score before assessment are in for a difficult conversation. Set this expectation on day one.