CUI / CMMC OPERATIONAL PACKAGE

SSP · POA&M · SPRS · Boundary · 800-171 Practice Evidence · CMMC L2 Readiness · Subcontractor Register

Table of Contents

1. Purpose and Scope
2. Assumed Scrutiny Level, CMMC L2 Third-Party Assessment
3. CUI Boundary, Finding It and Drawing It
4. SSP Template
5. POA&M Template
6. SPRS Score Worksheet
7. CUI Boundary Diagram Template
8. CUI Data Flow Map Template
9. CUI Category Register
10. 800-171 Practice Evidence Matrix
11. CMMC L2 Readiness Checklist
12. C3PAO Assessment Logistics
13. CUI Subcontractor Register
14. FedRAMP Equivalency Evidence Checklist
15. Regulatory and Framework Alignment Summary
16. Document Control

1. Purpose and Scope

The CUI Handling Standard names what is required; this package makes the standard executable. It assembles the SSP, POA&M, SPRS worksheet, boundary diagrams, data flow maps, category register, 800-171 evidence matrix, CMMC L2 readiness checklist, C3PAO logistics, subcontractor register, and FedRAMP equivalency evidence into a single operational binder.

It applies to every system, person, and process within the CUI boundary, and to every CUI subcontractor receiving CUI from the organization.

2. Assumed Scrutiny Level: CMMC L2 Third-Party Assessment

CERG operates the CUI program at the level required to pass a CMMC Level 2 third-party assessment by an authorized C3PAO. CMMC L1 is treated as a strict subset that is automatically met when L2 is met.

Why Plan for L2 Third-Party as the Baseline

CMMC L2 with C3PAO assessment is the highest practical scrutiny most CUI primes face on a routine cadence. If the program is ready for that scrutiny, it is ready for the lesser ones. Designing to a lower level and hoping to “lift later” produces a program that drifts under audit pressure.

3. CUI Boundary: Finding It and Drawing It

The CUI boundary is the set of systems, people, processes, and physical spaces that store, process, or transmit CUI. Defining it is the first executable step; it drives everything else.

3.1 Discovery Method

1. Start from contracts. DFARS-flowed contracts identify CUI obligations and (often) the categories.
2. Add data discovery. Use DLP, data discovery tools, and labelled storage signals to locate CUI in environments that may have it.
3. Add process discovery. Interview business units that interact with contracts; identify where CUI enters the environment.
4. Validate via Architecture Review records. CERG-PRC-AR-001 should have intaken any system handling CUI; any CUI-handling system not in the AR record is a finding.
5. Reconcile against the CUI Category Register (Section 9).

3.2 Categories of CUI Currently In Scope

The CUI Category Register (Section 9) lists categories actually handled (e.g., Controlled Technical Information, Export Control, Procurement Sensitive). Categories not handled are explicitly noted as Not-In-Scope so future inquiries are unambiguous.

3.3 Boundary Statement (Example Skeleton)

The CUI boundary comprises:
  - <named CUI enclave> in <provider> (FedRAMP Moderate / equivalent)
  - <named on-prem CUI work area> in <facility>
  - <named CUI endpoints> assigned to <named groups>
  - <named CUI applications> with their associated identity, logging, and backup systems
Excludes:
  - General corporate IT
  - OT environments (separately governed by [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) / [CERG-PLN-CIP-001](CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md))
  - SOX-relevant systems that do not also handle CUI

4. SSP Template

The System Security Plan is the assessor-facing description of the CUI environment and how each 800-171 practice is implemented.

SYSTEM SECURITY PLAN - <CUI System / Enclave Name>     SSP-CUI-NNN

1. SYSTEM IDENTIFICATION
   System Name(s) / Aliases
   System Type            (enclave / app / hybrid)
   Operational Status
   Executive Sponsor / System Representative
   Authorizing Official (CISO)
   Information System Security Point of Contact (CMMC / Federal Compliance Manager or delegate)
   System Boundary Description (Section 3.3 instance)

2. SYSTEM ENVIRONMENT
   Architecture and components (reference Section 7 diagram)
   Hardware and software inventory
   Network topology (reference Section 7 diagram)
   Hosting / cloud / SaaS providers and FedRAMP / equivalency status (Section 14)
   Interconnections and authorized data flows (reference Section 8 map)

3. CUI CATEGORIES PROCESSED
   List of categories per Section 9 register
   Sensitivity considerations (export control, etc.)

4. SECURITY REQUIREMENT IMPLEMENTATION
   For each 800-171r3 practice (3.1.1 … 3.14.x):
     - Practice statement
     - Implementation status (Implemented / Partially / Inherited / Planned / N/A) per [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) Section 4
     - Implementation description (specific, system-specific text)
     - Inheritance source (if inherited; references Section 14)
     - Evidence pointer (system / artifact / location)
     - Cross-reference to CERG control / standard / procedure

5. ROLES AND RESPONSIBILITIES
   Named roles for system operations and security

6. CONTINUOUS MONITORING STRATEGY
   Detection coverage; vulnerability scanning; recertification; control test cadence

7. INCIDENT RESPONSE
   Reference to [CERG-PLN-IR-001](CERG-PLN-IR-001_Incident_Response_Plan.md) with CUI-specific notes (DC3 reporting, 72-hour notification)

8. APPROVALS
   Information System Security Point of Contact, Executive Sponsor / System Representative, CISO

Appendices:
  A. CUI Boundary Diagram (Section 7)
  B. CUI Data Flow Map (Section 8)
  C. 800-171 Practice Evidence Matrix (Section 10)
  D. POA&M (Section 5)
  E. Inheritance Evidence Packages (Section 14)

The SSP Is Specific, Not Aspirational

“Multi-factor authentication is implemented” is not implementation language. “Phishing-resistant MFA via Entra ID enforced by Conditional Access policy ‘CUI-Enclave-Privileged-MFA’ for all privileged role holders, with break-glass exception per CERG-PRC-AC-002 §7” is. C3PAO assessors read implementation language for specificity; vague text invites probing questions and findings.

5. POA&M Template

The Plan of Action and Milestones tracks Partially Implemented and Planned items toward closure.

POA&M is updated monthly at minimum; closures must include evidence acceptable at C3PAO assessment.

6. SPRS Score Worksheet

The Supplier Performance Risk System score is the self-reported NIST 800-171 maturity number reported under DFARS 252.204-7019. The worksheet:

The worksheet is reproduced from the public DoD methodology; CERG does not invent its own scoring weights.

7. CUI Boundary Diagram Template

The diagram is produced in the architecture tool used by CERG-PRC-AR-001. The required elements:

• The trust boundary of the CUI environment, clearly drawn.
• All CUI-processing systems inside the boundary.
• All entry / exit points with named identity, network, and encryption controls.
• External services that touch the boundary (FedRAMP / equivalency status annotated).
• Subcontractor connections (Section 13).
• Out-of-scope adjacent systems distinguished with shading or annotation.

A diagram is required at SSP submission and refreshed on any material change.

8. CUI Data Flow Map Template

The data flow map shows how CUI moves from contract intake → processing → archival, including:

• Each transit hop annotated with protocol and CERG-STD-CR-001 encryption details.
• Each transformation (where CUI is combined, derived, or labeled).
• Each storage location with classification label, retention, and access pattern.
• Each export (to a customer, a subcontractor, or a contracting officer) with delivery method.

The map is referenced from the SSP and from the boundary diagram.

9. CUI Category Register

Categories never handled are explicitly listed as Not-In-Scope so future inquiries are unambiguous.

10. 800-171 Practice Evidence Matrix

The matrix is the row-per-practice spine. It is the principal artifact a C3PAO uses to navigate the SSP.

The matrix is the artifact CERG ships with the SSP. It is updated whenever an evidence artifact is refreshed.

11. CMMC L2 Readiness Checklist

A pre-assessment self-check, repeated quarterly and aggressively in the 90 days before an assessment.

11.2 Mock CMMC Assessment Procedure

The Mock Assessment Procedure is scheduled 6 months before the target C3PAO assessment date. It simulates the full CMMC Level 2 assessment process using internal or partner assessors to identify gaps before the real assessment.

Scope Definition

Assessor Assignment

Independence Requirement

• No assessor may evaluate practices they personally own or operate.
• If the organization has only 2–3 CERG team members, use an external partner for at least the Lead Assessor role.
• Independence declarations are signed by each assessor before the mock begins.

Practice-by-Practice Evidence Review

The core of the mock assessment. Each CMMC Level 2 practice (ALL 110+) is reviewed against the Practice Evidence Matrix (Section 10).

Interview Simulation

Interviews simulate C3PAO assessor interaction with key personnel.

Findings Report

Remediation Timeline

Re-Test

12. C3PAO Assessment Logistics

Logistics that consistently surprise organizations on assessment day; CERG handles them ahead of time.

13. CUI Subcontractor Register

The register is maintained jointly by Governance, CUI and TPRM; the TPRM record is canonical for vendor data with this register adding CUI-specific fields.

14. FedRAMP Equivalency Evidence Checklist

For cloud / SaaS providers handling CUI that are not FedRAMP-authorized, the equivalency package required by CERG-PRC-TPRM-001 Section 14. Repeated here as a CUI-program reference.

15. Regulatory and Framework Alignment Summary

16. Document Control

Source: plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md · Download .md · View on GitHub