Managing CMMC Level 2 access control for system and information integrity

CMMC Level 2 is a practical security requirement for organisations that handle Federal Contract Information (FCI) or Controlled Unclassified Information (CUI) in the United States defence supply chain. For Australian technology companies, manufacturers, consultants, and managed service providers, the standard can become relevant when bidding for US Department of Defense work or supporting a prime contractor that does.

Access control is central to the assessment because a system cannot protect sensitive information if users, applications, contractors, or connected devices can reach more than they need. The objective extends beyond creating user accounts. Organisations must control access throughout the identity lifecycle, restrict privileged actions, secure remote connections, and preserve trustworthy records of what happened.

System and information integrity adds another layer. Approved users should not be able to introduce unauthorised changes, weaken security settings, run unapproved software, or alter evidence needed for an investigation. A well-designed programme therefore joins identity governance, endpoint security, logging, vulnerability management, and change control rather than treating them as separate compliance tasks.

For an Australian business operating from Sydney, Canberra, Melbourne, or Brisbane, the work often sits alongside the Essential Eight, ISO 27001, privacy obligations, customer security questionnaires, and contractual requirements from global partners. The language may be different, but the operational expectation is familiar: know who can access important systems, why they can access them, and whether that access remains appropriate.

Define the environment and information boundary

CMMC Level 2 begins with scope. The organisation needs to identify where CUI is received, stored, processed, transmitted, or accessed, along with the systems that protect those activities. That can include cloud tenants, engineering workstations, source code repositories, ticketing platforms, backup services, collaboration tools, mobile devices, and third-party support systems.

A system security plan should describe the CMMC assessment scope in language that matches the real environment. If an Australian software firm has a dedicated tenant for a US defence customer, the boundary may be narrower than the whole corporate network. Segmentation can reduce assessment effort, but only when technical controls genuinely prevent CUI from moving into ordinary business systems.

Data flow diagrams and asset inventories should be kept current. They need to show administrator paths, service accounts, application programming interfaces, remote support tools, wireless networks, and external connections. A spreadsheet that lists only laptops and servers will not explain how a developer in Adelaide reaches a production database hosted in the United States.

Information classification also supports access decisions. CUI repositories, build pipelines, security consoles, and evidence stores should have defined owners and handling rules. Retention, encryption, backup, and disposal requirements should be documented so that access control protects both the information and the places where compliance records are kept.

Apply least privilege throughout the identity lifecycle

CMMC access control expects organisations to enforce approved authorisations for users, processes, and devices. In practice, this means using role-based access control, separating standard and administrative accounts, and granting permissions according to current duties. A developer may need source code and a test environment without receiving production database privileges or security administrator rights.

Joiner, mover, and leaver processes are critical. Human resources or contract management should trigger account creation, role changes, and removal of access. Departing staff, temporary workers, and vendors should lose access promptly, including access through personal tokens, SSH keys, API credentials, shared mailboxes, and remote management platforms.

Privileged access should require stronger safeguards. Multi-factor authentication, just-in-time elevation, approval workflows, session logging, and regular reviews help reduce the risk of a compromised administrator account. Shared privileged accounts make accountability difficult and should be replaced with named identities wherever the technology allows.

Reviews should test actual permissions rather than simply asking managers to approve a list. An owner might approve access to a repository without noticing that the same group also grants access to CUI. Automated identity governance can compare HR records, directory groups, cloud roles, and application entitlements, then flag dormant, excessive, or conflicting permissions.

Secure remote, cloud, and external access

Remote access is a significant consideration for distributed teams and suppliers. CMMC controls require remote sessions to be managed and protected, with authorisation, encryption, monitoring, and defined connection methods. Remote desktop services should not be exposed directly to the internet, and administrative access should pass through a controlled gateway or zero-trust access service.

Cloud environments need the same discipline as on-premises infrastructure. Organisations should document who administers the tenant, how identities are federated, which regions hold CUI, and how the provider supports incident response and audit evidence. Conditional access policies can require a managed device, approved location, strong authentication, and a compliant endpoint before a session is allowed.

External systems deserve explicit treatment. A contractor’s laptop, a customer-managed environment, or a supplier’s support account should not be assumed to meet internal standards. Contracts should specify security responsibilities, access duration, logging, incident notification, and evidence retention. Where practical, use isolated workspaces and brokered connections instead of copying sensitive material to a supplier’s own device.

Australian organisations often have staff working across state borders, while US customers may expect data to remain in a particular jurisdiction. A Melbourne engineer supporting a client in Virginia may need approved cross-border access, but convenience is not a sufficient authorisation. Access policies should account for location, time, device posture, data residency, and export-control conditions.

Protect integrity across endpoints and delivery pipelines

Access control loses value if an authorised account can modify systems without meaningful safeguards. Integrity controls should cover operating systems, applications, configurations, build artefacts, scripts, and security records. Secure configuration baselines, application allowlisting, endpoint detection, patch management, and vulnerability remediation reduce the chance that a legitimate access path becomes a route for malicious change.

Development teams should separate code creation, review, testing, release, and production administration. Pull requests, peer approval, protected branches, signed commits, and controlled deployment pipelines create a traceable chain from change request to running software. No single developer should be able to silently alter code, approve it, and deploy it to a CUI-connected environment.

Security alerts and flaw reports need owners and response times. A vulnerability scanner may identify an outdated library, but the organisation must show how it evaluates risk, assigns responsibility, tests remediation, and verifies closure. Threat intelligence, vendor notifications, endpoint alerts, and customer reports should enter a managed workflow rather than being handled through informal messages.

Endpoint integrity also depends on recovery. If a device is lost, compromised, or has important files deleted, the response process should preserve evidence while restoring approved data from trusted sources. A documented remote recovery process can support this planning, provided recovery actions are authorised, logged, and tested rather than performed ad hoc.

Make monitoring and evidence reliable

CMMC assessors need evidence that controls operate consistently. Access reviews, authentication events, privilege changes, failed connection attempts, configuration updates, malware detections, and administrative actions should feed centralised logging. Logs need accurate timestamps, protected storage, appropriate retention, and restricted write access so that an attacker cannot easily erase their trail.

Log review should be risk-based and assigned to named personnel or monitored services. High-value events, such as a new administrator, a change to a firewall rule, or access to a CUI repository from an unusual location, deserve prompt investigation. Retention schedules should reflect contractual requirements, incident response needs, and the ability to reconstruct activity after a delayed discovery.

The same discipline used for payment environments can inform CMMC operations. Guidance on log review practices illustrates how event collection, review responsibilities, alert thresholds, and retention decisions can be connected rather than managed as isolated tasks. The control objectives differ, but the operational lesson is useful.

Evidence should be generated as work happens. Screenshots collected months later, manually edited spreadsheets, and one-off exports are difficult to trust. A continuous assurance platform can capture control status, policy acknowledgements, identity review results, vulnerability tickets, configuration changes, and audit trails with a clear owner and timestamp.

Turn compliance into an operating discipline

A mature programme maps each access and integrity requirement to a responsible control owner, a technical implementation, a policy statement, and supporting evidence. The mapping should distinguish between a control that exists in a platform and a control that has been configured, tested, reviewed, and maintained.

Continuous monitoring is particularly valuable where cloud services and software deployments change daily. Automated checks can identify public storage, inactive accounts, missing MFA, excessive permissions, unencrypted connections, unsupported operating systems, or logging gaps. Security and engineering teams can then address exceptions through normal ticketing and release workflows.

For organisations serving US defence customers from Australia, CMMC preparation can complement local frameworks rather than compete with them. Essential Eight maturity measures provide a useful baseline for patching, MFA, application control, backups, and administrative privileges. ISO 27001 can support governance, while IRAP alignment may matter when selling to Australian government customers. The evidence still needs to be mapped carefully because a local certification does not automatically satisfy CMMC.

The commercial impact is substantial. A Canberra consultancy or Queensland manufacturer that can demonstrate controlled access, reliable audit records, and protected delivery pipelines is easier for a prime contractor to assess. Clear evidence can shorten security reviews, reduce repetitive questionnaires, and prevent a promising contract from stalling while access records are reconstructed.

Cloud audit evidence should cover more than application activity. Identity-provider events, infrastructure changes, administrator sessions, CI/CD actions, container activity, and security alerts may all be relevant. Organisations designing a broader evidence model can draw on approaches to cloud audit log automation, adapting the depth to their CMMC Level 2 scope and risk profile.

The strongest outcome is a repeatable operating model: access is approved before use, reduced when duties change, removed when relationships end, and reviewed against real activity. System changes are attributable, integrity events are investigated, and evidence remains available without a last-minute scramble. That combination gives CMMC Level 2 access control practical value for both compliance and the security of sensitive engineering and defence information.