Sparx EA gives US defense contractors the governed architecture environment to model their CMMC 2.0 system boundary, map all 110 NIST SP 800-171 practices to implementing systems and processes, and track their POA&M remediation progress: transforming CMMC compliance from a documentation burden into a live architecture governance activity.
CMMC (Cybersecurity Maturity Model Certification) is mandatory for US defense contractors and subcontractors handling CUI (Controlled Unclassified Information). Following the CMMC 2.0 revision, the framework consolidates around three levels, with Level 2: requiring implementation and third-party assessment of all 110 NIST SP 800-171 practices: applying to the vast majority of defense industrial base (DIB) companies handling CUI on DoD contracts. The System Security Plan (SSP) and Plan of Action and Milestones (POA&M) are the primary compliance artifacts, and they require exactly what enterprise architecture provides: a documented system boundary, a mapping from controls to implementing systems and processes, and a governance mechanism for tracking remediation. Sparx EA is the modeling environment that makes CMMC compliance architecture rigorous, auditable, and maintainable. This article explains how to build CMMC compliance architecture in Sparx EA, configure the MDG for CMMC practice governance, and connect CMMC architecture to DoDAF operational views in defense programs.
Key Takeaways
- CMMC 2.0 Level 2 requires all 110 NIST SP 800-171 practices: identical to the DFARS 252.204-7012 self-attestation requirements but now subject to mandatory third-party (C3PAO) assessment.
- The CMMC system boundary defines the scope: all systems, infrastructure, and people that process, store, or transmit CUI.
- Sparx EA models the CUI environment as a Technology layer boundary, with each NIST practice as a
«CMMC Practice»Requirement element linked to implementing systems. - The POA&M is managed as
«POA&M Item»elements in Sparx EA, with remediation dates and responsible parties tracked as tagged values. - CMMC architecture artifacts (SSP, network diagrams) are produced alongside DoDAF operational views in defense program contexts.
CMMC 2.0: What Defense Contractors Must Know
CMMC 2.0 (effective November 2021, with DoD contract clauses rolling in from late 2024) restructures the original five-level model into three levels:
Level 1 (Foundational): 17 practices from FAR 52.204-21, focused on basic safeguarding of Federal Contract Information (FCI). Annual self-attestation by a company official. Applies to contracts handling FCI but not CUI.
Level 2 (Advanced): 110 practices aligned exactly to NIST SP 800-171. For most contracts involving CUI, Level 2 applies. The assessment model depends on criticality: some programs require triennial third-party assessment by a C3PAO (Certified Third-Party Assessment Organization); others permit annual self-attestation by a senior company official. DoD is the determining authority on which assessment model applies to each program.
Level 3 (Expert): 110 NIST SP 800-171 practices plus selected NIST SP 800-172 practices. Reserved for contractors on the highest-priority programs (critical infrastructure, most classified program supply chains). Assessed by DCSA (Defense Contract Management Agency’s Defense Industrial Base Cybersecurity Assessment Center).
The vast majority of CMMC compliance work in the defense industrial base is Level 2, which is the focus of this article.
NIST SP 800-171: The 110 Practices
NIST SP 800-171 Rev 2 organizes its 110 security requirements into 14 families:
- Access Control (AC): 22 requirements
- Awareness and Training (AT): 3 requirements
- Audit and Accountability (AU): 9 requirements
- Configuration Management (CM): 9 requirements
- Identification and Authentication (IA): 11 requirements
- Incident Response (IR): 3 requirements
- Maintenance (MA): 6 requirements
- Media Protection (MP): 9 requirements
- Personnel Security (PS): 2 requirements
- Physical Protection (PE): 6 requirements
- Risk Assessment (RA): 3 requirements
- Security Assessment (CA): 4 requirements
- System and Communications Protection (SC): 16 requirements
- System and Information Integrity (SI): 7 requirements
Each requirement has a specific, actionable statement. For example: 3.1.1 (AC): “Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).” 3.13.8 (SC): “Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.” 3.14.6 (SI): “Monitor organizational systems including inbound and outbound communications traffic to detect attacks and indicators of potential attacks.”
Modeling the CMMC System Boundary in Sparx EA
The CMMC system boundary: the CUI environment: encompasses every system, person, and location that processes, stores, or transmits CUI in any form. Defining this boundary accurately is the most consequential decision in CMMC compliance architecture: too broad and control implementation becomes unmanageable; too narrow and the C3PAO will expand it during assessment, requiring remediation of previously excluded systems.
In Sparx EA, the CUI environment is modeled as a Technology layer boundary container: a package or boundary element that groups all in-scope components. Within the boundary:
Application Components represent systems that touch CUI: the contract management system (often where CUI first enters the organization), the engineering document management system (where CUI technical data is stored), the email system (if CUI is communicated by email), the collaboration platform (if CUI is shared via Teams, SharePoint, or similar), the ERP system (if CUI is in contract data, pricing, or technical requirements), and any specialized defense program systems.
Technology Nodes represent infrastructure: servers hosting CUI applications (whether on-premises or in cloud), network segments, endpoint devices (workstations, laptops, mobile devices used to access CUI), removable media devices, and cloud services hosting CUI data.
People and Processes: while not ArchiMate Technology elements, the people who access CUI (the workforce in scope for CMMC training, personnel screening, and access control requirements) are modeled as Business Actors linked to the Application Components they use. This supports the Personnel Security (PS) and Awareness and Training (AT) practice implementations.
External Service Providers: Cloud service providers, managed service providers, and other third parties that process CUI on the contractor’s behalf are modeled as Application Components outside the boundary, connected by Data Flow relationships. Each ESP must itself meet CMMC Level 2 requirements (or equivalent) for the CUI they handle: a tagged value on the ESP Application Component records their CMMC compliance status.
The CMMC MDG: Practice Stereotype Configuration
The «CMMC Practice» MDG stereotype extends the Requirement element in Sparx EA with the following tagged values:
Practice ID: e.g., 3.1.1, 3.13.8, 3.14.6Practice Text: the NIST SP 800-171 requirement statementCMMC Domain: the practice family (AC, AT, AU, CM, IA, IR, MA, MP, PS, PE, RA, CA, SC, SI)CMMC Level: 1 / 2 / 3 (practices at Level 1 are a subset; Level 2 includes all 110)Implementation Status: Not Implemented / Planned / Partially Implemented / Implemented / Not ApplicableImplementation Type: Policy / Technical Control / Physical Control / HybridResponsible Party: the team or individual accountable for implementationImplementation Date: when the practice was fully implementedAssessment Objective: the specific determination objectives from NIST SP 800-171A (the assessment methodology)Evidence Pointers: references to documentation, screenshots, logs, or other evidence of implementation
Realisation relationships link each «CMMC Practice» Requirement to the specific Application Component or Technology Node elements that implement it. Practice 3.1.1 (Access Control: Limit system access) is realized by the Identity Provider (Azure AD/Okta), the role-based access control configuration on each CUI-handling Application Component, and the network access control technology (802.1X, VPN). This traceability: from regulatory requirement to implementing technology: is the core architectural contribution of the CMMC model.
POA&M Management in Sparx EA
The Plan of Action and Milestones (POA&M) documents practices that are not yet fully implemented: the deficiencies identified either through self-assessment or formal assessment. The POA&M is a living document: it is updated regularly as remediation progresses and must be maintained throughout the CMMC assessment lifecycle.
In Sparx EA, POA&M items are modeled as «POA&M Item» elements linked to the «CMMC Practice» Requirement they address. Tagged values on the POA&M item record:
Weakness Description: what specific aspect of the practice is not implementedRemediation Plan: the specific steps to achieve full implementationMilestones: intermediate completion milestones (numbered)Scheduled Completion Date: when full implementation is expectedResources Required: budget, personnel, or technology neededRemediation Status: Not Started / In Progress / CompletedPoint of Contact: the individual responsible for remediation
A Power BI dashboard via EA GraphLink provides the POA&M status view: open items by domain, average days to scheduled completion, items past their scheduled completion date, and remediation velocity (items closed per month). This dashboard is the tool that the CMMC program manager uses for weekly status reporting and the CISO uses for board-level CMMC governance reporting.
CUI Flow Mapping: Where Does CUI Actually Go?
A critical component of CMMC compliance architecture is CUI flow mapping: documenting how CUI enters the organization, where it is stored, how it flows between systems, and where it exits (to subcontractors, cloud services, or customer portals).
In Sparx EA, CUI Data Objects are modeled at the Information layer with a «CUI» stereotype. Tagged values record the CUI category (from the CUI Registry: Defense, Export Control, Procurement and Acquisition, Technical Data, etc.) and the handling requirements.
ArchiMate Data Flow relationships connecting Application Interfaces show the CUI movement: CUI enters via the customer program portal (a DoD system outside the boundary), is ingested into the contract management system, flows to the engineering document management system for technical data, and is transmitted to approved subcontractors via encrypted email or a secure file transfer system. Each flow is documented.
This CUI flow map directly supports several CMMC practices: 3.13.1 (SC): “Monitor, control, and protect communications at the external boundaries and key internal boundaries of organizational systems”: requires knowing where all CUI communication boundaries are. 3.13.16 (SC): “Protect the confidentiality of CUI at rest”: requires knowing where CUI is stored at rest.
Connecting CMMC Architecture to DoDAF Operational Views
Defense contractors producing CMMC compliance architecture often do so alongside DoDAF operational views for the programs they support. These two architecture workstreams are connected in Sparx EA through the program repository structure.
DoDAF OV-2 (Operational Resource Flow Description) documents the operational information flows between the contractor’s systems and the DoD customer: these information flows carry CUI. The CUI identified in the OV-2 informs the CMMC CUI scope: if the OV-2 shows CUI flowing into a specific system, that system is in scope for CMMC.
DoDAF SV-1 (System Interface Description) documents the system interfaces that carry the operational information flows: these become the technical interfaces that CMMC SC (System and Communications Protection) practices must secure.
DoDAF TV-1 (Technical Standards Profile) documents the technical standards applicable to the program: encryption standards, network protocols, authentication standards. These standards directly map to CMMC technical practice implementations.
In Sparx EA, cross-references between DoDAF views and CMMC practice Requirement elements are modeled as Correspondence relationships: the same mechanism used in NAFv4 cross-view traceability. An architect can navigate from a DoDAF SV-1 system interface to the CMMC SC practices that govern its security implementation.
FAQ
Q1: What is the difference between CMMC Level 2 self-attestation and C3PAO assessment? For CMMC Level 2, DoD determines whether each contract requires self-attestation or third-party C3PAO assessment based on the criticality and sensitivity of the CUI involved. For most contracts, DoD is requiring C3PAO assessment for programs involving critical technology, export-controlled information, or programs on the DoD Critical Technology list. Self-attestation is permitted for lower-sensitivity CUI programs. The determination is made at the contract level: contractors must verify the requirement for each specific contract they hold.
Q2: How does CMMC apply to subcontractors and the supply chain? CMMC flows down the supply chain: prime contractors must require CMMC compliance from subcontractors who handle CUI. In Sparx EA, subcontractors who receive CUI from the prime are modeled as External Service Provider Application Components outside the primary boundary. The prime contractor must document the CMMC compliance level required of each subcontractor and verify their compliance. Tagged values on the ESP component record the required CMMC level, the subcontractor’s assessed status, and the assessment date.
Q3: Can a defense contractor use cloud services (Microsoft 365 Government, AWS GovCloud) and still be CMMC compliant? Yes, but the cloud service must meet CMMC Level 2 equivalent requirements. Microsoft 365 Government (GCC High) and Azure Government are FedRAMP High authorized and meet the technical requirements for CUI handling. AWS GovCloud is similarly authorized. The key requirement is that the cloud service be FedRAMP Moderate or High authorized (or equivalent) and listed in the SSP as an external service provider. Practices implemented by the cloud provider are documented as “inherited” in the SSP: the contractor does not re-implement controls the cloud provider already implements.
Q4: How does CMMC interact with ITAR (International Traffic in Arms Regulations)? ITAR and CMMC address different but related concerns. ITAR controls the export of defense articles, services, and related technical data: it is a regulatory and licensing framework. CMMC addresses the cybersecurity protection of CUI (which may include ITAR-controlled technical data). A company handling ITAR-controlled technical data electronically is handling CUI and therefore subject to CMMC. The CMMC system boundary for an ITAR-handling company typically includes the systems that store, process, or transmit ITAR technical data. CMMC compliance protects that data from cyber threats; ITAR compliance governs its authorized disclosure.
Q5: What is the CMMC scoping guidance for remote work and BYOD (Bring Your Own Device)? CMMC scoping guidance (from the CMMC Scoping Guide) addresses remote work: personal devices (BYOD) used to access CUI are generally not recommended: the security controls required for CUI handling are difficult to implement and verify on employee-owned devices. The preferred approach is to provide managed endpoints (company-owned or managed service) for CUI access, with those endpoints in scope for CMMC. In Sparx EA, the remote access architecture (VPN or ZTNA, managed endpoint, MDM) is modeled with the relevant SC and AC practices linked to the implementing technology elements.
Q6: How do we handle CMMC for a small defense contractor with limited IT resources? Small contractors often struggle with CMMC Level 2 because the 110 practices were designed with larger organizations in mind. Practical approaches for small contractors include: using FedRAMP-authorized cloud services (Microsoft 365 GCC High, Google Workspace for Government) that implement many technical controls at the platform level, reducing the contractor’s own control implementation burden; engaging a Managed Security Service Provider (MSSP) that specializes in CMMC compliance for small contractors; and using a CMMC RPO (Registered Provider Organization) for compliance guidance. Sparx EA helps small contractors document the architecture they have, identify gaps clearly, and produce the SSP that shows compliance without requiring architectural expertise they may not have in-house.
Q7: How is the CMMC SSP produced from a Sparx EA model? The SSP is produced using Sparx EA’s document generation capability. A CMMC SSP template defines the sections required by CMMC: System Overview (from the boundary model), System Components Inventory (from Application Component and Technology Node lists), CUI Data Flows (from Data Flow relationships), Control Implementation Narratives (from Practice Requirement elements and their linked implementing systems), and POA&M (from POA&M item elements). The template pulls tagged values into the document automatically: control status, responsible party, implementation date: creating a machine-generated SSP that is consistent with the authoritative Sparx EA model.
Q8: What Sparx Services engagement is recommended for a defense contractor preparing for C3PAO assessment? The Amplify engagement is designed for defense contractors building a CMMC compliance architecture capability in Sparx EA. It delivers: the CMMC MDG configuration, the system boundary architecture model, all 110 practice Requirements pre-populated, CUI flow mapping, and the initial POA&M based on a self-assessment gap analysis. The resulting Sparx EA model supports SSP production and provides the live compliance register needed throughout the C3PAO assessment and ongoing ConMon. Amplify starts at $45,000.
Work With Sparx Services
CMMC Level 2 assessment requires documented compliance architecture, not a spreadsheet. Sparx Services’ Amplify engagement builds your CMMC compliance architecture in Sparx EA: system boundary, 110 practice requirements, CUI flow mapping, POA&M tracking: giving your C3PAO assessors the rigorous architecture documentation they need.
Amplify from $45,000. Contact us to discuss your CMMC compliance architecture program.