Automating CMMC Level 2 system and communications protection evidence
CMMC Level 2 requires organisations handling Federal Contract Information (FCI) or Controlled Unclassified Information (CUI) to demonstrate that security practices are implemented consistently. System and Communications Protection (SC) is a particularly evidence-heavy area because it covers network boundaries, transmission safeguards, encryption, mobile access, collaborative technologies and the protection of information in transit.
For security teams, the challenge is rarely the existence of a firewall or encrypted connection. The harder task is proving that controls operate across the environment, remain aligned with the System Security Plan (SSP), and produce reliable records that an assessor can inspect. Screenshots collected before an assessment provide limited assurance when configurations change every week.
Automation connects technical activity with compliance evidence. It can collect configuration states, link assets and services to SC practices, record review events, identify gaps and preserve an audit trail. When these processes run through engineering and security workflows, evidence becomes a by-product of normal operations rather than a last-minute documentation exercise.
This approach matters for Australian organisations supporting US defence programs from Canberra, Sydney, Melbourne, Adelaide or Brisbane. A company may have local obligations under the Australian Privacy Act, the Australian Signals Directorate’s Information Security Manual (ISM) and contractual requirements from a US prime. The evidence process needs to account for data residency, time zones, subcontractors and the practical realities of a distributed workforce.
Define the evidence required by each SC practice
The first step is to translate every relevant CMMC Level 2 SC practice into an evidence requirement. The CMMC Level 2 assessment objectives are based on NIST SP 800-171 Rev. 2, and the SC family includes practices such as monitoring and controlling communications at external and key internal boundaries, protecting the confidentiality of CUI in transit, terminating network connections at the end of sessions, and preventing remote devices from connecting to organisational systems without appropriate safeguards.
A useful evidence record should answer five questions: what control is operating, which asset or service is covered, who owns it, when it was checked, and what authoritative source proves its state. For example, a policy stating that TLS must be used is weaker than a continuously collected record showing approved protocols on production load balancers, certificates within validity periods and exceptions with named approval.
Evidence sources may include cloud security posture tools, firewall policies, VPN and zero-trust configurations, endpoint management platforms, identity providers, network diagrams, vulnerability scanners, ticketing systems and code repositories. The objective is not to collect every available log. It is to retain a defensible set of records that demonstrates implementation and supports the assessor’s sampling process.
A control-to-evidence matrix helps prevent common gaps. It should map each practice to its implementation statement, responsible owner, technical source, collection frequency, retention period and review status. Linking this matrix to the SSP also makes it easier to identify when a system change invalidates an existing description.
Connect communications controls to live infrastructure
Automation is most effective when it reads from systems that actually enforce security decisions. A firewall rule export, for instance, can show whether traffic is permitted between network zones, while an identity platform can verify multifactor authentication and conditional access for remote connections. Cloud-native environments require the same discipline across security groups, network access control lists, private endpoints, service meshes, API gateways and container ingress policies.
Encryption evidence should be specific enough to demonstrate protection of CUI during transmission. Records can confirm approved TLS versions, cipher suites, certificate ownership, mutual TLS settings, encrypted site-to-site tunnels and secure file transfer configurations. For collaboration platforms, evidence may include tenant settings, external sharing restrictions, session controls and policies governing the movement of sensitive files.
A mature workflow also detects drift. If an engineer opens a public ingress rule, downgrades a protocol, changes a VPN configuration or adds an unapproved third-party integration, the automation should flag the event and create a review record. The control owner can then remediate the issue, document an accepted risk or update the SSP when the change is legitimate.
This model fits well with DevOps practices. Infrastructure-as-code checks can block non-compliant configurations before deployment, while post-deployment scans confirm that the running environment matches the approved source. For organisations using AWS, Microsoft Azure or Google Cloud in Australia, policy-as-code can apply the same SC requirements across Sydney, Melbourne and other regions without relying on manual inspection.
Preserve trustworthy evidence for assessment
An assessor needs more than a dashboard showing a green status. Evidence should have provenance, timestamps, scope and enough detail to be independently understood. Automated records should identify the collection method, source system, account or service that produced the result, the relevant asset and any transformation applied to the data.
Immutable or access-controlled storage is important for audit defensibility. Retain configuration snapshots, event records, approval tickets and remediation history according to the organisation’s policy and contractual obligations. Where CUI or sensitive operational data could appear in logs, collection must be designed carefully so that evidence does not create an unnecessary secondary exposure.
The following structure can help teams define an automated evidence package for common SC activities:
| Control area | Useful automated source | Evidence to retain | Typical review signal |
|---|---|---|---|
| Boundary protection | Firewalls, cloud security groups, network ACLs | Approved rules, segmentation map, change history | Unauthorised route or open inbound service |
| CUI in transit | TLS scanners, VPN platforms, secure transfer tools | Protocol settings, certificates, tunnel status | Weak protocol, expired certificate or failed tunnel |
| Remote access | VPN, zero-trust access and identity provider | Access policy, MFA state, session records | Privileged access without required conditions |
| Mobile and remote devices | MDM, EDR and endpoint compliance tools | Device posture, encryption and connection status | Unmanaged or non-compliant device |
| Session termination | Identity, VPN and application logs | Idle timeout and disconnect configuration | Excessive session duration or failed termination |
| Collaborative services | SaaS administration and DLP tools | Sharing rules, external access and policy events | CUI shared outside approved tenant or group |
Retention should reflect the assessment period and the organisation’s operating model. A daily snapshot may prove current configuration, while event-driven records are better for demonstrating change management. A platform such as continuous assurance software can consolidate these signals, associate them with controls and provide a persistent view of readiness rather than a collection of disconnected exports.
Evidence quality also depends on access governance. Limit who can alter records, separate evidence administration from the people making production changes, and log exports used in assessment packages. Australian businesses should consider where evidence is stored and who can access it, especially when US contractual information is processed by a local team or a managed service provider.
Build evidence collection into engineering workflows
Security evidence becomes more reliable when it is generated at the point where a change is designed, reviewed and deployed. A pull request that modifies a network route can trigger automated checks for approved destinations, encryption requirements and segmentation rules. The review record then links the change, test results, approval and deployment event to the affected SC practice.
Security gates should be proportionate to risk. A production change that exposes an internet-facing endpoint may require a hard block unless a security owner approves an exception. A development change to a non-sensitive test network could generate a warning and create a follow-up task. Both paths should produce an auditable record, with the decision criteria defined in advance.
CI/CD pipelines can validate infrastructure-as-code against rules such as “no unrestricted administrative ports,” “CUI services must use encrypted transport,” and “external connections require an approved boundary.” Runtime validation remains necessary because a compliant template can be overridden by a manual console action, a vendor update or an emergency configuration change.
This is where governance platforms integrated with DevOps can support sales and delivery as well as compliance. When a prospective US defence customer asks for assurance, the organisation can present current control status, ownership and remediation history without pausing product work for a major evidence gathering exercise. The same workflow can support SOC 2, ISO 27001 or Australian ISM-aligned requirements when controls overlap.
Manage exceptions, suppliers and changing scope
No automated programme eliminates exceptions. Legacy applications may not support modern encryption, a supplier may require a narrowly defined connection, or an operational technology environment may need a compensating safeguard. The important point is to make the exception visible, time-bound and connected to risk ownership.
An exception record should include the affected asset, SC practice, business justification, risk assessment, compensating measures, approval authority, expiry date and remediation plan. Automation can alert the owner before expiry, verify that the temporary rule still exists, and close the exception when the underlying configuration is corrected. An exception without an end date quickly becomes an undocumented permanent state.
Third-party connections deserve particular attention. Managed service providers, cloud vendors, external developers and US prime contractors may handle systems that transmit or access CUI. Contracts should define security responsibilities, notification expectations, logging access and evidence availability. Automated supplier reviews can track attestations, connection status and overdue actions, but they should not replace technical verification of the connection itself.
Scope must be reviewed whenever the environment changes. Acquiring a company in Perth, opening a new engineering office in Melbourne or moving workloads to an Australian cloud region can change the boundary described in the SSP. A new SaaS collaboration tool can create a communications path that was absent during the original assessment. Asset discovery and service inventories should therefore feed into periodic scope reviews.
Teams preparing for assessment can use a recurring operating rhythm: continuous technical collection, weekly review of critical alerts, monthly control-owner attestations and quarterly validation of the SSP and network diagrams. Before an assessment, they should sample evidence across systems, confirm that timestamps and owners are clear, and test whether an independent reviewer can follow each record from practice to implementation.
Automating CMMC Level 2 system and communications protection evidence is ultimately a discipline of linking intent to operation. Policies describe the required safeguards, engineering systems apply them, monitoring tools verify them and governance workflows preserve the proof. With that connection in place, security teams can identify drift earlier, reduce manual evidence handling and show that communications protections remain effective throughout the assessment cycle.