CMMC Compliance Architecture: Modeling Cybersecurity Maturity in Sparx EA

CMMC compliance asks for exactly what enterprise architecture already produces: a documented system boundary, a mapping from controls to the systems and processes that implement them, and a governance mechanism for tracking remediation. Treat the System Security Plan and POA&M as documents and they rot; model them in Sparx EA and CMMC compliance becomes a live architecture governance activity — rigorous, auditable, and maintainable.

CMMC (Cybersecurity Maturity Model Certification) is mandatory for US defense contractors and subcontractors handling CUI (Controlled Unclassified Information). CMMC 2.0 consolidates the framework around three levels, with Level 2 — requiring implementation and 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. This article covers how to build CMMC compliance architecture in Sparx EA, configure the MDG Technology for practice governance, and connect CMMC architecture to DoDAF operational views in defense programs.

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:

Level 1 (Foundational): 17 practices from FAR 52.204-21, focused on basic safeguarding of Federal Contract Information (FCI), with annual self-attestation. 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 official. DoD determines which model applies to each program.

Level 3 (Expert): 110 NIST SP 800-171 practices plus selected NIST SP 800-172 practices, reserved for the highest-priority programs and assessed by the DoD's DIBCAC.

The vast majority of CMMC work in the defense industrial base is Level 2, 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), Awareness and Training (AT, 3), Audit and Accountability (AU, 9), Configuration Management (CM, 9), Identification and Authentication (IA, 11), Incident Response (IR, 3), Maintenance (MA, 6), Media Protection (MP, 9), Personnel Security (PS, 2), Physical Protection (PE, 6), Risk Assessment (RA, 3), Security Assessment (CA, 4), System and Communications Protection (SC, 16), and System and Information Integrity (SI, 7).

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"; 3.13.8 (SC) — "Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission"; 3.14.6 (SI) — "Monitor organizational systems, including inbound and outbound traffic, to detect attacks and indicators of potential attacks."

A CMMC readiness scorecard

Before modeling control implementations, gauge where your compliance architecture stands across the dimensions that determine assessment readiness. Score each from 0 to 4 using the scale below, then let the low scores drive your build sequence.

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 it 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, forcing remediation of previously excluded systems.

In Sparx EA, the CUI environment is modeled as a Technology-layer boundary container — a package or boundary element grouping all in-scope components. Within it:

• Application Components represent systems that touch CUI — the contract management system, the engineering document management system, email and collaboration platforms (if CUI flows through them), the ERP, and specialized defense program systems.
• Technology Nodes represent infrastructure — servers hosting CUI applications, network segments, endpoint and mobile devices, removable media, and cloud services hosting CUI.
• People and processes in scope are modeled as Business Actors linked to the Application Components they use, supporting the Personnel Security (PS) and Awareness and Training (AT) practices.
• External Service Providers — cloud and managed-service providers handling CUI on the contractor's behalf — are modeled as Application Components outside the boundary, connected by Data Flow relationships, with a tagged value recording their CMMC compliance status.

The CMMC MDG: practice stereotype configuration

The «CMMC Practice» MDG stereotype extends the Requirement element with tagged values that turn a static control list into a queryable register: Practice ID (3.1.1, 3.13.8, ...), Practice Text, CMMC Domain (the family), CMMC Level, Implementation Status (Not Implemented / Planned / Partially Implemented / Implemented / Not Applicable), Implementation Type (Policy / Technical / Physical / Hybrid), Responsible Party, Implementation Date, Assessment Objective (from NIST SP 800-171A), and Evidence Pointers.

Realization relationships link each «CMMC Practice» Requirement to the specific Application Component or Technology Node elements that implement it. Practice 3.1.1 (Access Control) is realized by the identity provider, the role-based access control configuration on each CUI-handling component, and the network access control technology. 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 documents practices not yet fully implemented — the deficiencies identified through self-assessment or formal assessment. It is a living document, updated as remediation progresses, and must be maintained throughout the assessment lifecycle.

In Sparx EA, POA&M items are modeled as «POA&M Item» elements linked to the «CMMC Practice» Requirement they address, with tagged values recording the Weakness Description, Remediation Plan, Milestones, Scheduled Completion Date, Resources Required, Remediation Status (Not Started / In Progress / Completed), and Point of Contact.

Because the POA&M lives in the model, its status can be surfaced live to a reporting dashboard — open items by domain, average days to scheduled completion, items past due, and remediation velocity (items closed per month). That dashboard is what the CMMC program manager uses for weekly status reporting and the CISO uses for board-level governance.

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. In Sparx EA, CUI Data Objects are modeled at the Information layer with a «CUI» stereotype, with tagged values recording the CUI category (from the CUI Registry) and handling requirements.

ArchiMate Data Flow relationships connecting Application Interfaces show the movement: CUI enters via the customer program portal, is ingested into the contract management system, flows to the engineering document management system, and is transmitted to approved subcontractors via encrypted email or secure file transfer. This map directly supports several SC practices — 3.13.1 (monitor and protect communications at boundaries) requires knowing where all CUI communication boundaries are; 3.13.16 (protect CUI at rest) requires knowing where CUI is stored.

Connecting CMMC architecture to DoDAF operational views

Defense contractors producing CMMC architecture often do so alongside DoDAF operational views for the programs they support. The two workstreams connect through the program repository structure:

• DoDAF OV-2 (Operational Resource Flow) documents the operational information flows between contractor and DoD systems — flows that carry CUI. CUI identified in the OV-2 informs CMMC scope.
• DoDAF SV-1 (System Interface Description) documents the system interfaces carrying those flows — the interfaces that CMMC SC practices must secure.
• DoDAF TV-1 (Technical Standards Profile) documents applicable technical standards — encryption, protocols, authentication — that map to CMMC technical practice implementations.

In Sparx EA, cross-references between DoDAF views and CMMC practice Requirements are modeled as Correspondence relationships — the same mechanism used in NAFv4 cross-view traceability — so an architect can navigate from a DoDAF SV-1 interface to the CMMC SC practices governing its security.

Frequently asked questions

Build CMMC compliance as architecture, not paperwork

CMMC Level 2 assessment requires documented compliance architecture, not a spreadsheet. Sparx Services helps you build it in Sparx EA — the system boundary, all 110 practice requirements, CUI flow mapping, and POA&M tracking — giving your C3PAO assessors the rigorous documentation they need. The Configure the Solution engagement configures the CMMC MDG, establishes the boundary model, and produces the initial gap analysis; see how it fits the wider enterprise architecture discipline.