Limit system access to the types of transactions and functions that authorized users are permitted to execute
📖 What This Means
This control ensures that users can only perform actions and access functions within a system that they are explicitly authorized to use. Think of it like giving employees access only to the tools and files they need for their job—nothing more. For example, an accountant should only have access to financial systems, not HR records. This prevents accidental or intentional misuse of systems, such as deleting critical files or accessing sensitive data. In simpler terms, it’s about enforcing the principle of 'need to know' or 'least privilege' to keep systems secure.
🎯 Why It Matters
Restricting access to only necessary functions helps prevent unauthorized actions that could lead to data breaches, system damage, or compliance violations. For example, in the 2017 Equifax breach, hackers exploited an unpatched system vulnerability, but broader access controls could have limited the damage. The average cost of a data breach is $4.45 million (IBM, 2023), and unauthorized access is a leading cause. From a DoD/CMMC perspective, this control ensures that Controlled Unclassified Information (CUI) is protected from unauthorized access or misuse, which is critical for maintaining trust and compliance.
✅ How to Implement
- 1. Use AWS IAM roles or Azure RBAC to assign specific permissions to users based on their job functions.
- 2. Configure policies to restrict access to specific services, such as limiting S3 bucket access to read-only for certain users.
- 3. Enable logging for all access and transaction activities using AWS CloudTrail or Azure Monitor.
- 4. Regularly review and update permissions using tools like AWS IAM Access Analyzer or Azure Privileged Identity Management.
- 5. Implement multi-factor authentication (MFA) to add an extra layer of security for sensitive transactions.
📋 Evidence Examples
Access Control Policy
Permission Configuration Screenshot
Access Logs
Audit Report
Training Records
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For AC.L1-3.1.2 ("Limit system access to the types of transactions and functions that authorized users are permitted to execute"), 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 how access to CUI systems is controlled, including the specific IAM tools, policies, and processes used. Reference your Access Control Policy and identify the systems in scope. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"AC.L1-3.1.2 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to limit system access to the types of transactions and functions that authorized u.... 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']."
"AC.L1-3.1.2 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to limit system access to the types of transactions and functions that authorized u.... Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"AC.L1-3.1.2 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 access points to CUI systems (VPN, direct network, cloud portals)
- • Document which IAM system manages access (Azure AD, AWS IAM, on-prem AD)
- • Map user roles to system access levels
- • Ensure this control covers all systems within your defined CUI boundary where limit system access to the types of transactions and functions that authorized users are permitted to execute applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Access Control Policy
- 📄 IAM configuration documentation
- 📄 Access request and approval records
- 📄 Evidence artifacts specific to AC.L1-3.1.2
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will verify that access controls are implemented as described, test whether unauthorized users are blocked, and review access logs for evidence of enforcement.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Have you defined and documented user roles and permissions?
Question 2: Are permissions enforced based on job functions?
Question 3: Are access logs being monitored and reviewed regularly?
Question 4: Have unnecessary permissions been removed?
Question 5: Is MFA enabled for sensitive transactions?
⚠️ Common Mistakes (What Auditors Flag)
1. Overly broad permissions.
2. No logging or monitoring.
3. Outdated policies.
4. Inconsistent enforcement across environments.
5. Missing MFA for sensitive transactions.
📚 Parent Policy
This practice is governed by the Access Control Policy