Continuous Assurance SaaS Platform · SOC 2 · PCI DSS · HITRUST · HIPAA · CMMC · Secured Buy™ Program · 80% Faster Time-to-Market · Continuous Assurance SaaS Platform · SOC 2 · PCI DSS · HITRUST · HIPAA · CMMC · Secured Buy™ Program · 80% Faster Time-to-Market

Automating Media Protection Controls for CMMC Readiness

Media protection is a practical test of whether an organisation can control sensitive information beyond its primary production systems. Removable drives, backup devices, printed documents, cloud exports, developer laptops and temporary files can all create exposure when teams move data between locations or systems.

For Australian businesses that support United States defence programs, the issue can be especially complex. A Canberra consultancy, a Melbourne software company or a Sydney-based managed service provider may handle Controlled Unclassified Information (CUI) while operating under Australian privacy, critical infrastructure and government security expectations.

The phrase “CMMC Level 4” also needs careful treatment. The original CMMC model included five maturity levels, with Level 4 focused on advanced and proactive practices. CMMC 2.0 changed the model to three levels. If a customer, prime contractor or legacy document refers to Level 4, the supplier should confirm the contractual requirement and map it to the current CMMC and NIST expectations rather than claiming a current Level 4 certification.

Automation helps turn media protection from a policy document into an operating system of controls. It can identify where sensitive data is stored, prevent unauthorised copying, enforce encryption, trigger approvals and preserve evidence for assessment. The goal is a repeatable control environment that works during ordinary engineering and business activity, not a manual exercise performed shortly before an audit.

Clarify The Applicable CMMC Baseline

Begin by confirming the contract, data type and assessment boundary. CMMC obligations usually flow from a Department of Defense contract or from a prime contractor. The applicable level depends on the information handled and the contract language. A supplier should identify whether it receives CUI, Federal Contract Information, export-controlled material, technical drawings, maintenance records or other defence-related content.

The legacy Level 4 concept generally pointed towards advanced protection, measurable performance and proactive threat management. Its media protection expectations were built on practices associated with NIST SP 800-171 and enhanced requirements in NIST SP 800-172. A modern implementation should therefore document the exact control sources being used, such as media access, marking, storage, transport, sanitisation, accountability and cryptographic protection.

This distinction matters during procurement. An Australian subcontractor that advertises “CMMC Level 4 certified” may create confusion if the buyer is working under the current three-level model. The safer approach is to maintain a crosswalk showing the contract requirement, the NIST practice, the implemented safeguard, the responsible owner and the evidence retained for review.

Build A Complete Media Inventory

Media protection begins with knowing what counts as media in the environment. The inventory should cover laptops, USB devices, external hard drives, backup cartridges, smartphones, virtual machine images, printed records, removable storage in manufacturing equipment and cloud exports. It should also include media used by contractors, field engineers and third-party support providers.

Automation can collect device and storage information from endpoint management, identity platforms, cloud APIs, backup systems and data loss prevention tools. Each asset should have an owner, location, classification, encryption state, retention period and disposal method. A storage device with unknown ownership should be treated as an exception rather than silently remaining outside the control boundary.

Classification rules should distinguish CUI from ordinary corporate information. For example, a developer repository may contain code that is commercially sensitive but not CUI, while an exported engineering drawing or test report may require stricter handling. Automated discovery can inspect file labels, repository paths, metadata and content patterns, then route uncertain matches to a security analyst instead of applying an overly broad block.

Australian businesses should account for where data is processed and stored. Major cloud providers operate regions in Sydney and Melbourne, but a workload may still send logs, backups or support data overseas. The Privacy Act 1988 and the Notifiable Data Breaches scheme add obligations for personal information, while defence contracts may impose separate restrictions on CUI. These requirements should be reflected in the media inventory and data-flow map.

Convert Protection Requirements Into Rules

A useful control design translates each requirement into a machine-enforced rule and a reviewable exception. For example, “restrict access to media containing CUI” can become an identity-based policy that permits approved users, managed devices and authorised applications while denying unknown endpoints. “Sanitise media before disposal” can become a workflow requiring a verified wipe record, an asset identifier and an approval from the media owner.

Media protection area Automated enforcement Evidence for assessment
Access Allow approved identities and managed devices only Access policy, decision logs and exception records
Marking Apply CUI labels to files, folders and physical media records Label configuration and sample records
Storage Require encryption, approved locations and restricted permissions Encryption status, storage policy and access reviews
Transport Block unapproved transfers and require tracked custody DLP events, transfer approvals and courier records
Sanitisation Trigger secure wipe or destruction workflows at end of life Wipe certificate, destruction record and asset history
Accountability Assign owners and retain an auditable chain of custody Inventory history and custody changes
External media Permit only registered, encrypted devices Device allow-list and endpoint event logs

Controls should use deny-by-default decisions for high-risk actions, but they also need a practical exception path. A field technician might require an encrypted drive to service equipment at a remote mine site, or a production team might need to transfer a large test file to a controlled facility. The request should capture the business reason, data classification, expiry time, approving authority and compensating safeguards.

Cryptography needs an explicit policy rather than a vague statement that “encryption is enabled”. Define approved algorithms, key ownership, rotation, recovery and revocation. Hardware encryption, full-disk encryption, encrypted object storage and encrypted transfer protocols serve different purposes. A device can be encrypted at rest while a file is exposed during an unprotected transfer, so the rules must cover the complete movement of the information.

Integrate Controls With DevOps Workflows

Media protection should be connected to the systems where engineering work already occurs. Endpoint management can enforce removable-media restrictions, while identity and access management can require phishing-resistant authentication for users handling CUI. DLP can inspect uploads to collaboration platforms, source control, ticketing systems and email. Cloud security tools can detect public storage, excessive permissions and unapproved replication.

Infrastructure-as-code provides a strong enforcement point for storage controls. A pipeline can reject a cloud resource that lacks encryption, uses an unauthorised region, permits public access or omits required retention settings. Container and virtual machine templates can include hardened storage defaults. Build systems can prevent deployment when a protected environment does not have logging, access reviews or approved key management.

The continuous assurance model brings these checks together by connecting controls, evidence and operational activity. This is useful when a security team needs to demonstrate that a policy is working continuously rather than presenting a manually assembled collection of screenshots. It also gives product engineering teams a clear route for resolving failed checks before a release reaches production.

Automation should be placed in the pull request and change-management lifecycle. A proposed storage configuration can be scanned before approval, and a failed rule can open a ticket with the affected resource, owner and remediation guidance. The same control can then verify the deployed state. This closes the gap between what a repository declares and what a cloud account or endpoint actually does.

Create Evidence And Exception Workflows

An assessor needs evidence that controls are designed, implemented and operating consistently. Useful evidence includes device restrictions, encryption reports, media inventories, access decisions, sanitisation certificates, transfer approvals, incident records and periodic reviews. Each record should show a timestamp, system source, relevant asset or user and the policy version that produced the decision.

Evidence collection should be automated wherever possible. Endpoint tools can report whether removable storage is disabled or restricted. Cloud platforms can provide configuration snapshots and access logs. A service desk can retain approvals and exception expiry dates. Security information and event management systems can correlate unusual copying, failed access attempts and large outbound transfers.

An exception should never become a permanent alternative control. Every exception needs a defined owner, a start date, an expiry date and a review trigger. If the expiry passes without renewal, the automated policy should revoke the permission or create an escalated incident. This is particularly important for contractors and temporary project teams whose access often remains active after a delivery milestone.

Run evidence tests at a regular cadence. Select a sample of media records, trace each one from creation through use and disposal, and check whether the expected logs exist. Test blocked USB transfers, lost-device response, encryption enforcement and secure deletion. These exercises reveal operational weaknesses that a policy review will not expose, such as an unmonitored lab computer or a backup appliance outside the central identity system.

Adapt The Programme For Australian Operations

Australian implementation must reflect how local teams actually work. Staff may connect from home over NBN services, move between offices in Sydney and Melbourne, or travel to a Canberra government site and a regional customer location in the same week. A media control that assumes a fixed corporate network will fail when a laptop is used from a home office, airport lounge or customer facility.

Supply-chain structure is another consideration. Australian defence work commonly involves a prime contractor in Canberra or Adelaide and several smaller engineering, software or manufacturing suppliers. A small subcontractor may have a lean security team but still need to protect CUI on a few endpoints. Cloud-based policy enforcement, managed detection and central evidence collection can provide consistency without requiring every supplier to build a large internal security operation.

Map CMMC media controls to Australian frameworks where appropriate. The ASD Essential Eight can support endpoint hardening, patching, application control, restricted administrative privileges and multi-factor authentication. The Information Security Manual can inform protective security decisions, while the Privacy Act 1988 applies when media contains personal information. Organisations in regulated sectors should also assess whether the Security of Critical Infrastructure Act 2018 creates additional cyber security obligations.

Everyday handling habits deserve attention. Employees may use USB-C hubs, personal phones, portable drives or printed packs because they are convenient during workshops and site visits. Replace informal workarounds with approved alternatives: managed transfer portals, encrypted corporate devices, secure print release and documented destruction bins. Training should explain the reason for each restriction in practical terms, including what to do when a customer hands over an unlabelled drive or asks for data to be copied urgently.

Measure Performance And Maintain Readiness

A mature programme measures whether controls reduce risk, not just whether policies exist. Useful indicators include the percentage of media with known owners, encrypted-device coverage, blocked unauthorised transfers, overdue sanitisation tasks, exception age, time to revoke access and the proportion of storage resources passing policy checks.

Metrics should be segmented by business unit and media type. A high compliance rate across office laptops can conceal weak controls on backup media, laboratory equipment or third-party systems. Review results with engineering, procurement, facilities and legal teams so that ownership remains shared. Media protection is a business process involving people, technology and physical operations.

Continuous monitoring also supports faster sales and contracting cycles. When a prospective prime contractor asks how CUI is protected, the organisation can provide a current control narrative, system boundary, evidence summary and exception register. This is more credible than promising that documentation will be prepared after the contract is signed.

The operating model should be reviewed whenever the contract changes, a new cloud service is introduced, a supplier is onboarded or an incident exposes a new transfer path. Confirm that the CMMC mapping remains current, validate automated rules against real workflows and remove controls that generate noise without improving protection. A disciplined cycle of discovery, enforcement, evidence and review keeps media protection effective as Australian teams and defence programmes evolve.