-
Determine the NSS boundary and select the impact level
Before any other schema work, produce the NSS boundary determination memo required by SRF-L1-ACQ-009. The memo must cite 44 USC 3552(b)(6), document the factors the authorizing official considered, and state whether the system is NSS or non-NSS. This determination drives your security baseline choice (CNSSI 1253 for NSS; NIST SP 800-53 for non-NSS) and your IL selection.
Use this table as the canonical reference for IL and NSS combinations:
Impact level NSS tier Data type Cloud path IL4 Non-NSS CUI, no NSI Commercial cloud; DISA IL4 PA required IL5 Non-NSS Higher-sensitivity CUI (Privacy Act, law enforcement sensitive, export-controlled research) Government-only cloud region; DISA IL5 PA required IL5 NSS Unclassified NSS (intelligence, cryptology, command/control, weapons systems per 44 USC 3552(b)(6)) Government-only cloud region; CNSS Policy 22 and CNSSI 1253 apply IL6 NSS Classified up to and including SECRET Classified cloud only (AWS C2S, Azure Government Secret, Oracle NSR); no commercial path NSS determination is not automatic. Many DoD administrative, logistics, and healthcare systems are non-NSS even at IL5. The deploying component makes the boundary determination; document the rationale explicitly. An undocumented assumption is a finding in every ATO review.Once the IL is set, register the system in the CDAO AI registry per SRF-L1-ACQ-001 and designate the Responsible AI Officer per SRF-L1-ACQ-002 before proceeding.
-
Select the operating model and trace CC SRG inheritance from the DISA PA
Each AI system runs on one of four operating models. The choice determines which controls the component owns outright, which it shares with a contractor or CSP, and which it inherits through the DISA Provisional Authorization.
Operating model Description Inheritance posture AI-SaaS Commercial AI service accessed via API; DISA PA required before use with DoD data CSP holds L4/L5 PA; component owns L1-L3 and all DoD-side CRM rows AI-PaaS Component-built or fine-tuned model on a government-authorized platform (e.g., AWS GovCloud, Azure Government) Platform PA inherited for infrastructure controls; component adds application, data, and model governance layers Agent-Ops Agentic AI in operational workflows (logistics, ISR data triage, administrative processing) Component owns task boundary, oversight gate, and remedy controls; CSP or DISA shares platform controls Program-Embedded AI embedded directly in a weapon system or C2 program (ACAT program); subject to DoDI 5000.89 TEVV Component or prime contractor owns all layers; TEVV plan governs the test and acceptance cycle After selecting an operating model, open the DISA CC SRG for your IL and map the
responsibility_splitvalues in the JSON controls (dod-component,disa,contractor,csp,shared) to your Customer Responsibility Matrix. AI-specific controls not covered by the CC SRG are component-owned by default.For IL6 systems: Commercial cloud paths do not apply. Verify the classified cloud environment (AWS C2S, Azure Government Secret, or Oracle NSR) is the designated operational environment before beginning the inheritance mapping. The CC SRG does not cover classified enclaves in the same way; work with DISA directly to confirm the applicable control baseline.Document the inheritance chain per SRF-L3-ACQ-008. Inherited controls must be traceable to a named PA or ATO in the ATO package.
-
Map SRF personas to DoD roles
The schema uses six personas aligned to SRF layers, not DoD job titles. Use this table to assign ownership rows in the workpaper and to identify the officials responsible for each RAI principle area.
SRF persona DoD role(s) Office Primary layer(s) ai-system-governanceCDAO liaison, Program Executive Officer, Component RAI Officer CDAO; component CIO office L1 data-providerChief Data Officer, Privacy Officer, Records Officer, ISSO Component CDO; ISSO office L2 application-developerProgram Manager, system owner, software developer (FTE or contractor) Program office L3 agentic-platform-providerPlatform engineering team, ISSO Program office or DISA L3, L4 ai-platform-providerISSO, Authorizing Official, cloud program office; CSP for inherited controls Component AO office; DISA for DISA-split controls L4 model-providerContracting Officer, CDAO, prime contractor or AI vendor Contracting office; program office L5 The Persona Mapping sheet in the workpaper carries these assignments pre-populated. Adjust the office column to reflect your component's actual structure. Where a role spans multiple offices, name a primary official and a secondary.
Contracting Officer involvement: The CO is the primary actor for L5 controls requiring contract clauses (DoDI 5000.90 transparency card, data rights provisions, CMMC certification requirements, and vendor disclosure SLAs). Engage the CO early in the acquisition phase before the solicitation is issued. -
Set tier parameters by IL and operating model
Controls marked
tier-configurablecarry a parameter name (e.g.,TIER_AI_REGISTRY_COVERAGE_PCT) rather than a fixed threshold. Use the system's IL and operating model to set values in the Tier Parameters sheet of the workpaper.IL NSS tier Suggested threshold posture IL6 NSS Maximum thresholds across all tier-configurable parameters. Zero-tolerance controls apply without exception. IL6 evidence is classified; document artifact type and custodian role rather than URL. IL5 NSS NSS Maximum thresholds. CNSSI 1253 baseline governs security controls. CNSS Policy 22 applies. All zero-tolerance controls apply. IL5 Non-NSS Non-NSS Near-maximum thresholds. NIST 800-53 moderate baseline. DISA IL5 PA required. Human oversight gate required for consequential decisions. IL4 Non-NSS Recommended minimums in schema descriptions. Reduced cadence acceptable for some monitoring controls. Document any reductions with PM and ISSO approval. Zero-tolerance controls are not tier-configurable. Controls markedzero-tolerance(human oversight gate for use-of-force-adjacent decisions, NSS determination memo, DISA PA currency, IL6 personnel clearance, and others) must be met at every IL. They appear in the workpaper with locked thresholds.For IL6 classified environments: do not attempt to satisfy evidence requirements with public URLs or commercial SIEM exports. Record the document type (e.g., "TEVV report, classified, retained at SCIF"), the custodian role, and the access path (classified network or cleared facility). The OCSF evidence fields in the JSON are filled TBD for IL6 controls because the evidence exists but cannot be linked.
-
Assemble the evidence package
The DoD AI deployment evidence package combines: the TEVV artifacts required by DoDI 5000.89, the AI impact assessment, the ATO file with inherited control documentation, the CMMC evidence folder for contractor-operated components, and CDAO incident reporting records for operational systems.
Use the CMMC Evidence Log sheet in the workpaper to map each control to its evidence artifact. For controls with OCSF-mapped evidence, the OCSF class is the expected telemetry source; for governance documents, record the artifact ID and custodian.
Key evidence artifacts by lifecycle stage
Acquisition (ACQ)NSS boundary determination memo (SRF-L1-ACQ-009); DoD RAI compliance plan covering all five principles (SRF-L1-ACQ-004); AI use case registry entry with CDAO reporting confirmation (SRF-L1-ACQ-001); supply chain risk assessment (SRF-L1-ACQ-006, SRF-L5-ACQ-008); DoDI 5000.90 contract clauses verified by CO (SRF-L1-ACQ-005); model transparency card (SRF-L5-ACQ-001); DISA PA verification at required IL (SRF-L4-ACQ-001)TEVVTEVV plan approved before deployment (SRF-L1-TEVV-010); TEVV report signed by AO (SRF-L3-TEVV-001); AI impact assessment approved (SRF-L3-TEVV-002); operator override capability verified (SRF-L3-OVR-004); STIG compliance baseline verification (SRF-L4-ACQ-002); prompt injection detection coverage verified (SRF-L3-OPS-007)Operations (OPS)IL boundary enforcement logs (SRF-L2-OPS-002); ACAS scan coverage reports (SRF-L4-OPS-009); audit log completeness verification (SRF-L4-OPS-005); adversarial detection event log (SRF-L2-OPS-005); AI decision log retention confirmation (SRF-L2-OPS-007); availability SLA compliance report (SRF-L4-OPS-010)Human oversight (OVR)Human oversight gate operational log with zero bypass events (SRF-L3-OVR-003); operator override event log (SRF-L3-OVR-004); remedy and appeal procedure published and named reviewer designated (SRF-L3-OVR-005); CDAO incident reporting records (SRF-L1-OPS-008)CMMC (contractor)CMMC Level 2 C3PAO assessment with SPRS submission (SRF-L4-ACQ-007); CMMC Level 3 DIBCAC assessment for higher-value programs (SRF-L4-ACQ-008); contractor data isolation verification (SRF-L2-ACQ-008); personnel security clearance roster for IL6 access (SRF-L5-ACQ-007)For governance documents, store them in the program's authoritative records system and reference them by artifact ID in the workpaper. For controls with OCSF-mapped telemetry, configure your SIEM to emit the specified OCSF class before system acceptance. The OCSF attribute fields marked TBD require mapping to your specific platform's log schema after DISA finalizes the SIEM integration guidance.
CMMC and AI governance: CMMC 2.0 governs contractor cybersecurity for CUI but does not address AI-specific obligations. This schema extends the CMMC evidence folder to include AI governance artifacts. Organize the CMMC evidence log with a dedicated AI section that maps NIST 800-171 practices to the SRF controls that satisfy or extend them.
CMMC / TEVV workpaper