Mapping CMMC Evidence Across Certification Levels With Continuous Compliance
For organisations supplying the US defence industrial base from Australia, Cybersecurity Maturity Model Certification (CMMC) can feel like a moving target. A single business may need to demonstrate different controls for different contracts, while its software, cloud services, suppliers and engineering practices continue to change every day. Treating compliance as a periodic paperwork exercise creates gaps between the environment assessed and the environment actually operating.
Continuous compliance provides a more practical model. It connects policies, technical safeguards, system boundaries, ownership and audit evidence so that one change can be evaluated against several CMMC requirements at once. The result is a reusable evidence base that supports Level 1, Level 2 and, where applicable, Level 3 preparation without creating three completely separate compliance programmes.
Australian defence technology companies face additional considerations. A team in Canberra may develop products for a US prime contractor, while infrastructure runs in Sydney or Melbourne and staff work from Brisbane, Perth or regional locations. Data residency, export restrictions, subcontractor access, cloud authorisation and time-zone differences can all affect how evidence is collected and how a system boundary is defined.
Understanding The Three CMMC Levels
CMMC Level 1 is the entry point for organisations handling Federal Contract Information (FCI). It is built around 15 basic safeguarding practices derived from FAR 52.204-21, including access control, system and information integrity, media protection, incident reporting and physical protection. Organisations generally complete an annual self-assessment, although the exact contract requirement remains decisive.
Level 2 applies to organisations handling Controlled Unclassified Information (CUI). Its 110 security requirements align with NIST SP 800-171 Rev. 2 and cover areas such as access control, awareness and training, configuration management, identification and authentication, risk assessment, security assessment and system communications protection. Depending on the contract and acquisition language, a company may need a third-party assessment by an authorised C3PAO or an annual self-assessment.
Level 3 is intended for environments facing the most serious threats and adds selected protections from NIST SP 800-172. It is not simply Level 2 with a longer checklist. The organisation must demonstrate stronger resilience, enhanced monitoring, threat hunting, data protection and protection against advanced persistent threats. Government-led assessment arrangements and stricter evidence expectations mean that Level 3 planning should begin with architecture and threat modelling rather than with document collection.
The levels are cumulative in practice. A Level 2 environment still needs the foundational protections represented by Level 1, and a Level 3 environment must retain the Level 2 baseline while implementing additional safeguards. A common control library therefore provides greater value than isolated level-specific spreadsheets.
Building A Cross-Level Evidence Model
The first step is to create a control taxonomy that separates the requirement, the implementation statement, the responsible owner, the system component and the evidence source. For example, multifactor authentication can map to Level 1 access protection, multiple Level 2 access control requirements and Level 3 enhancements involving privileged access, identity assurance or resistance to credential compromise.
This model should distinguish between common controls and level-specific controls. Identity lifecycle management, endpoint protection, vulnerability remediation, logging and security awareness may support every level, but the required strength, scope and evidence frequency can change. A control that is sufficient for a Level 1 self-assessment may require stronger monitoring, documented analysis or independent validation at Level 2.
The system security plan (SSP) should be linked to this structure rather than maintained as a static narrative. Each SSP statement should identify the relevant assets, people, facilities, services and data flows. A Plan of Action and Milestones (POA&M), where permitted, should connect to specific gaps, owners, target dates, compensating measures and residual risk. Evidence should show both implementation and ongoing operation.
A useful evidence record contains a timestamp, source system, control relationship, scope, reviewer and retention period. Automated evidence might come from identity providers, endpoint management, cloud configuration, ticketing platforms, vulnerability scanners, source control or security information and event management systems. Manual evidence still has a place, especially for interviews, board-approved policies, incident exercises and supplier reviews, but it should be clearly labelled rather than mixed with machine-generated records.
Connecting DevOps Activity To CMMC Requirements
Continuous compliance works best when security checks enter the same workflows used to build and release products. Infrastructure-as-code can be checked for insecure storage, excessive permissions and unapproved regions before deployment. Pull requests can trigger dependency scanning, secrets detection and software composition analysis. Build systems can record who approved a release, which tests ran and whether a security exception was authorised.
This approach is especially relevant to Australian software companies selling through US primes. A product team in Sydney may release several times a week, while a compliance manager works with a customer in Virginia and an assessor operates in another time zone. Evidence collected at commit, build and deployment stages reduces reliance on last-minute screenshots and makes the audit trail easier to review.
Application and infrastructure exposure should be considered together. An application security posture management capability can help connect code risks, cloud configuration, vulnerabilities and ownership, giving compliance teams a clearer view of whether a control is operating across the product estate. The objective is not to scan everything indiscriminately; it is to tie findings to the systems, CUI flows and requirements that matter.
Security exceptions must also follow the delivery lifecycle. If a team temporarily permits a vulnerable library because a customer release is urgent, the exception should record the affected asset, business reason, risk acceptance, compensating control and expiry date. That record can support a POA&M or risk decision, while automated reminders prevent temporary decisions from becoming permanent weaknesses.
Organisations designing their control automation can also benefit from a practical implementation guide when translating technical requirements into repeatable engineering procedures. The specific method matters less than establishing a consistent connection between a change, a control test, an owner and retained evidence.
Mapping Evidence Without Duplicating Effort
A crosswalk should begin with the control objective, then identify how each maturity level changes the expectation. Consider audit logging. At a basic level, the organisation may need to generate and retain event records. At Level 2, it must define relevant events, protect log data, review it appropriately and support incident analysis. At Level 3, enhanced monitoring, correlation and detection of sophisticated activity may be expected.
The same pattern applies to awareness and training. Level 1 may require basic security awareness for personnel handling FCI. Level 2 expands the scope and depth of training for CUI responsibilities, incident reporting and role-specific duties. Level 3 may require more advanced training for privileged users, defenders and personnel responsible for identifying sophisticated attacks. A central learning record can support all three levels if courses, attendance, refresh cycles and role assignments are mapped accurately.
Training should account for distributed teams and contractors. An organisation with personnel in Adelaide, Auckland and the United States should record local working arrangements, remote access expectations and the handling of customer information across jurisdictions. For organisations preparing this area, NIST 800-171 training automation can provide useful context for connecting role-based learning with defence contractor obligations.
Supplier and cloud evidence also needs careful treatment. A vendor’s SOC 2 report may support part of a control narrative, but it does not automatically prove that the customer has configured the service correctly or that the vendor’s scope matches the CUI environment. Evidence packages should identify inherited controls, customer responsibilities, contract terms, data locations and the process for reviewing supplier changes.
Australian businesses should pay particular attention to cloud region selection and cross-border access. A system hosted in Sydney may still be administered by personnel overseas, and a US customer may impose contractual requirements beyond Australian privacy obligations. The evidence map should therefore document administrative access, encryption keys, support channels, subcontractors and the relationship between CMMC scope and other obligations such as the Privacy Act and Essential Eight practices.
Operating A Continuous Assessment Programme
A continuous programme needs defined review rhythms. Technical telemetry can be collected daily or continuously, while control attestations may be reviewed monthly, access certifications quarterly and policies annually. The cadence should reflect the risk and volatility of each control. A stable physical security procedure does not need the same frequency as privileged access or cloud configuration.
A control dashboard should show coverage, evidence freshness, failed tests, open remediation tasks and changes to scope. It should also distinguish between an unavailable data source and a failed control. That difference is important during an assessment: missing evidence may indicate a collection problem, while a failed test may indicate an actual security weakness.
Ownership must extend beyond the compliance team. Engineering leaders should own secure build and deployment practices, IT should own endpoint and identity controls, legal and procurement should support supplier obligations, and executives should approve risk acceptance. A platform such as Tauruseer can help bring these responsibilities into a continuous assurance workflow, including the Secured Buy™ model that connects governance with CI/CD and DevOps activity.
The programme should be tested through internal assessments before an external review. Sample a control, follow its evidence back to the source, verify that the scope is correct and check whether a person unfamiliar with the system can understand the result. Conducting this exercise in Australia before a US customer or C3PAO review can expose gaps in terminology, time stamps, evidence retention and responsibility for inherited services.
Recommended operating practices include:
- Maintain one authoritative control library with mappings to Levels 1, 2 and 3, NIST SP 800-171 and relevant organisational policies.
- Assign every control to an accountable owner and a technical evidence source, with a named backup for leave and staff turnover.
- Automate evidence collection from identity, endpoint, cloud, ticketing, source control and learning systems where practical.
- Review CUI boundaries whenever a product, supplier, cloud region, office or remote-access arrangement changes.
- Run periodic evidence walkthroughs that test both technical operation and the quality of the audit narrative.
| Compliance area | Level 1 focus | Level 2 focus | Level 3 focus | Continuous evidence examples |
|---|---|---|---|---|
| Access control | Basic restriction of system access | CUI scoping, least privilege, remote access and approved connections | Stronger privileged access, monitoring and threat resistance | Identity logs, access reviews, MFA records, privilege changes |
| Awareness and training | General security awareness | Role-based CUI and incident responsibilities | Advanced training for defenders and privileged roles | Learning records, course assignments, completion reports |
| Configuration management | Basic system configuration safeguards | Baselines, change control and flaw remediation | Enhanced hardening, monitoring and resilience | Configuration scans, pull requests, change tickets |
| Incident response | Reporting and basic response capability | Documented procedures, testing and CUI incident handling | Advanced analysis, containment and recovery | Incident tickets, exercise results, forensic records |
| Assessment and monitoring | Annual self-assessment evidence | SSP, POA&M and assessment-ready evidence | Deeper validation and enhanced continuous monitoring | Control tests, dashboards, remediation history |
A well-designed mapping does more than prepare an organisation for an assessment date. It makes the security state visible between assessments, shows where one control supports multiple requirements and highlights when a product change affects certification scope. For Australian companies participating in global defence supply chains, that visibility can support customer due diligence, reduce repeated evidence requests and create a more reliable path from Level 1 foundations to higher CMMC expectations.