CM.L2-3.4.5: Define, document, approve, and enforce physical and logical access restrictions

📖 What This Means

This practice requires organizations to clearly define and document who has access to their physical and digital systems, how that access is approved, and how it is enforced. This means creating policies that outline who can enter certain areas, use specific devices, or access sensitive data. For example, only authorized IT staff should have access to server rooms, and only certain employees should have access to financial records. The goal is to prevent unauthorized access that could lead to data breaches or other security incidents. Think of it like having a guest list for a party—only those on the list are allowed in, and there’s someone checking IDs at the door.

🎯 Why It Matters

Unrestricted access to physical and logical systems is a major security risk. Without proper controls, unauthorized users can easily gain access to sensitive information or critical infrastructure. For instance, in 2017, a breach at Equifax exposed the personal data of 147 million people due to lax access controls. The financial cost of such breaches can run into millions, not to mention the damage to reputation and loss of customer trust. From a DoD perspective, ensuring that only authorized personnel can access Controlled Unclassified Information (CUI) is crucial for national security. This control helps mitigate these risks by ensuring that access is tightly regulated and monitored.

✅ How to Implement

1. Define access policies for cloud resources using IAM roles and policies.
2. Document these policies in a centralized repository.
3. Use multi-factor authentication (MFA) for all cloud accounts.
4. Regularly review and update access permissions.
5. Implement logging and monitoring for access attempts.
6. Ensure that access approvals are documented and auditable.
7. Use encryption for data at rest and in transit.

⏱️

Estimated Effort

Implementation typically takes 2-3 days for small to medium organizations, requiring intermediate IT security skills.

📋 Evidence Examples

Access Control Policy

Format: PDF/DOC

Frequency: Annually or when significant changes occur.

Contents: Detailed description of access restrictions, approval processes, and enforcement mechanisms.

Collection: Policy document from HR or IT department.

Access Logs

Format: CSV/Log

Frequency: Daily or weekly.

Contents: Records of all access attempts, including successful and failed attempts.

Collection: Export from security information and event management (SIEM) system.

Approval Records

Format: PDF/DOC

Frequency: As needed.

Contents: Documentation of access requests and approvals.

Collection: Access request forms and approval emails.

Training Records

Format: PDF/DOC

Frequency: Annually.

Contents: Records of employee training on access control policies.

Collection: Training management system.

Configuration Screenshots

Format: PNG/JPG

Frequency: Quarterly.

Contents: Screenshots of IAM settings and access control configurations.

Collection: Manual capture from cloud or system consoles.

📝 SSP Guidance

Use this guidance when writing the System Security Plan (SSP) narrative for this control.

How to Write the SSP Narrative

For CM.L2-3.4.5 ("Define, document, approve, and enforce physical and logical access restrictions"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe your configuration management process, including baseline configurations, change control procedures, vulnerability management, and how configuration compliance is monitored and enforced. Be specific -- name your actual products, settings, and responsible personnel.

Example SSP Narratives

Cloud (Azure/AWS)

"CM.L2-3.4.5 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to define, document, approve, and enforce physical and logical access restrictions. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."

On-Premise

"CM.L2-3.4.5 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to define, document, approve, and enforce physical and logical access restrictions. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."

Hybrid

"CM.L2-3.4.5 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."

System Boundary Considerations

• Identify all system types within the CUI boundary requiring baselines
• Document configuration management tools and CMDB
• Map change control workflow from request to implementation
• Ensure this control covers all systems within your defined CUI boundary where define, document, approve, and enforce physical and logical access restrictions applies
• Document any systems where this control is not applicable and explain why

Key Documentation to Reference in SSP

📄 Configuration Management Policy
📄 Baseline configuration documents
📄 Change management records
📄 CMDB/asset inventory
📄 Evidence artifacts specific to CM.L2-3.4.5
📄 POA&M entry if control is not fully implemented

What the Assessor Looks For

The assessor will compare actual system configurations against documented baselines, review change tickets for proper approval workflow, and verify vulnerability remediation within SLA.

💬 Self-Assessment Questions

Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.

Question 1: Do you have a documented access control policy?

✅ YES → Proceed to Q2

❌ NO → GAP: Draft and approve an access control policy within 2 weeks.

Remediation:

Consult with HR and IT to create a comprehensive access control policy.

Question 2: Are access permissions reviewed regularly?

✅ YES → Proceed to Q3

❌ NO → GAP: Schedule a review of all access permissions within 1 week.

Remediation:

Use IAM tools to audit and update access permissions.

Question 3: Is multi-factor authentication (MFA) enabled for all accounts?

✅ YES → Proceed to Q4

❌ NO → GAP: Enable MFA for all accounts within 1 week.

Remediation:

Configure MFA settings in your identity management system.

Question 4: Are access logs maintained and monitored?

✅ YES → Proceed to Q5

❌ NO → GAP: Implement logging and monitoring for access attempts within 2 weeks.

Remediation:

Set up a SIEM system to collect and analyze access logs.

Question 5: Are access approvals documented and auditable?

✅ YES → Compliant

❌ NO → GAP: Implement a process to document and audit access approvals within 2 weeks.

Remediation:

Create access request forms and approval workflows.

⚠️ Common Mistakes (What Auditors Flag)

1. Lack of regular access reviews

Why this happens: Often overlooked due to resource constraints or lack of awareness.

How to avoid: Schedule quarterly reviews and automate using IAM tools.

2. Inconsistent access policies across environments

Why this happens: Different teams managing cloud and on-premise systems.

How to avoid: Use centralized identity management solutions.

3. Inadequate documentation of access approvals

Why this happens: Manual processes that are not consistently followed.

How to avoid: Implement automated workflows for access requests and approvals.

4. Failure to enable MFA

Why this happens: Perceived complexity or inconvenience.

How to avoid: Educate staff on the importance of MFA and simplify the setup process.

5. Not monitoring access logs

Why this happens: Lack of tools or expertise.

How to avoid: Invest in a SIEM system and train staff on its use.

📚 Parent Policy

This practice is governed by the Configuration Management Policy

View CM Policy →

📚 Related Controls

AC.L2-3.1.1 - Limit system access to authorized users, processes acting on behalf of authorized users, and devices. AC.L2-3.1.2 - Limit system access to the types of transactions and functions that authorized users are permitted to execute. AC.L2-3.1.20 - Verify and control/limit connections to and use of external information systems.