AC.L2-3.1.20[a] — Access Control (External Connections)Domain: Access Control (AC) | Practice: AC.L2-3.1.20 | Objective ID: 3.1.20[a] | Source: NIST SP 800-171 Rev. 2 / CMMC 2.0 Level 2 | Assessment Objective: Connection to external systems is identified. |
Executive Summary (For Leadership and the Board)
CMMC objective AC.L2-3.1.20[a] sits inside the Access Control domain (AC.L2-3.1.20 — External Connections) and reads: Connection to external systems is identified.. Identify and document all connections to external systems (partner networks, cloud services, third-party APIs, internet-facing interfaces) from CUI-processing environments. For organizations that handle Controlled Unclassified Information (CUI), this objective is part of the foundation that every downstream control depends on.
Under DFARS 252.204-7012, AC.L2-3.1.20[a] will be evaluated during a full third-party CMMC Level 2 assessment, Joint Surveillance Voluntary Assessment, or formal certification gating DoD CUI contract awards. Leadership and the board should be asking: Who owns this objective? When was it last reviewed? Where is the evidence stored? And what is our remediation plan if a C3PAO flags a gap? Failing this objective in isolation may be POA&M-able under CMMC 2.0; failing it in conjunction with related objectives in the same practice is typically not.
Business Question | What Leadership Must Confirm |
|---|---|
Do we have a documented, owned, and current implementation for the requirement that connection to external systems is identified? | A named control owner exists, the implementation is documented in the SSP, and a defined review cadence is in force. |
Can we produce evidence that this objective is operating effectively across every CUI-bearing system in scope? | Artifacts (logs, tickets, config exports, attestations) are collected on a defined cadence and tied back to AC.L2-3.1.20[a]. |
What happens if this control fails or drifts out of compliance? | A documented detection, escalation, and remediation path exists, with the vCSO as the executive backstop. |
Can we prove this objective to a C3PAO? | The evidence package — policy, configuration, monitoring output, and recertification records — is pre-built and mapped directly to AC.L2-3.1.20[a]. |
Executive Risk Lens: Failures against this objective routinely surface in Verizon DBIR and Mandiant M-Trends data as contributors to CUI exfiltration, ITAR-relevant data exposure, and engineering CUI loss to nation-state adversaries. A single weak point in External Connections can undermine every other access-control and integrity control in the CUI boundary.
How Authorization Should Flow
AC.L2-3.1.20[a] — External Connections Lifecycle (Request → Authorize → Provision → Recertify → Deprovision)
1. Request | HR / Sponsor | 2. Authorize | Manager + Data Owner | 3. Provision | IAM / Configuration | 4. Recertify | Periodic review | 5. Deprovision | Within SLA on exit / change.
AC.L2-3.1.20[a] — External Connections Lifecycle
Every step produces audit evidence the C3PAO will request. Source of truth: authoritative system-of-record (HRIS, IdP, CMDB, GRC).
Technical Deep Dive (For Engineers, IAM Admins, and ISSOs)
What the Objective Requires
NIST SP 800-171 derives AC.L2-3.1.20 from controls in the NIST SP 800-53 AC family. CMMC 2.0 splits the parent practice into discrete assessment objectives; AC.L2-3.1.20[a] is the specific objective requiring that Connection to external systems is identified. To pass — with artifacts — the implementation must demonstrate:
A documented control implementation specifically addressing the requirement that connection to external systems is identified, recorded in the System Security Plan (SSP) section for AC.L2-3.1.20.
A named control owner accountable for AC.L2-3.1.20[a], identified in the SSP and the RACI for Access Control.
Configuration of the supporting technology (where applicable) such that the control is enforced by default and cannot be silently bypassed by a user with normal privileges.
A monitoring and detection mechanism (log, alert, ticket, or recertification campaign) that produces evidence the objective is operating across all CUI-bearing systems in scope.
A documented review cadence — at minimum annual, ideally quarterly for high-risk objectives — with signed evidence of each review.
A defined remediation path (ticket, POA&M entry, or change request) when drift, failure, or exception is detected.
Mapping of AC.L2-3.1.20[a] to the corresponding NIST SP 800-53 Rev. 5 control(s) in the AC family, including any control enhancements adopted by the organization.
Cross-references to related Access Control objectives in the same practice so the C3PAO sees a coherent story rather than 14 disconnected artifacts.
Evidence Package the Assessor Will Request
Artifact | Where It Typically Lives | Common Gotchas |
|---|---|---|
Access Control Policy section covering AC.L2-3.1.20 | GRC platform / policy library | Policy is generic and does not name AC.L2-3.1.20[a]; no review date in the last 12 months. |
SSP narrative for AC.L2-3.1.20 — implementation paragraph for objective [a] | SSP master document (controlled copy) | Narrative says 'will be implemented' instead of describing the current implementation. |
Operational evidence (logs, configs, tickets, reports) for AC.L2-3.1.20[a] | Log aggregator / SIEM / ITSM / configuration management tool | Evidence covers a single point in time instead of a time-series; reviewer cannot show continuous operation. |
Most-recent review or recertification record for AC.L2-3.1.20[a] | GRC platform or signed manager attestation | Review was rubber-stamped (100% approve, no changes) or older than the policy review cadence. |
Remediation / POA&M entries tied to AC.L2-3.1.20[a] (if any) | POA&M tracker (Compliance-as-a-Service or spreadsheet) | Open POA&M items past their target date with no executive sponsor — first thing a C3PAO will dig into. |
Reference Architecture
Authoritative Authorization Architecture for CMMC Level 2 (Users, Processes, Devices)
HRIS / Asset Mgmt / Vault / Contractor → Identity & Asset Authorization Plane (Entra ID / Okta / CyberSecureID, CMDB, ITSM) → CUI File Shares / GCC High / Engineering / VPN-ZTNA.
Every CUI-bearing system MUST consume identity, asset, and authorization data from the authorization plane. No local accounts. No shadow IT. No exceptions.
Real-World Examples — What Goes Wrong
Example 1 — The Drift That Was Never Caught
During a Cyberwatch engagement, a mid-tier defense supplier discovered that the identity control supporting AC.L2-3.1.20 had quietly drifted out of compliance over six months. The team assumed the control still operated as documented in the SSP, but spot-checks showed IAM gaps across three production systems handling CUI. The C3PAO was scheduled in 90 days; remediation became an all-hands fire drill.
Lesson: The SSP is not the implementation — the implementation is the implementation. AC.L2-3.1.20[a] requires evidence of the control as it operates today, not as it was designed two SSP revisions ago.
Example 2 — The Evidence That Did Not Match the Policy
a defense prime contractor produced its policy binder for AC.L2-3.1.20 during a Joint Surveillance Voluntary Assessment. The policy said the control was reviewed quarterly. Operational evidence showed the most recent access-list review was 14 months old. The assessor flagged it immediately because the discrepancy is a hallmark sign of paper-only compliance.
Lesson: If the policy says quarterly, the evidence binder must show four reviews per year. This is the simplest, fastest test an assessor performs against AC.L2-3.1.20[a].
Example 3 — The Acquisition That Inherited the Gap
After a Tier 2 aerospace subcontractor acquired a small competitor, leadership assumed the new entity inherited the parent's compliance program. In reality, the acquired environment had its own identity stack, no documented control owner for AC.L2-3.1.20[a], and no evidence trail. When the CUI boundary was redrawn to include the acquired environment, the entire AC.L2-3.1.20 package failed to map cleanly.
Lesson: Mergers, acquisitions, and even significant infrastructure changes reset the clock. Compliance with AC.L2-3.1.20[a] must be re-established for any new system or environment that touches CUI.
How Northern Data Solutions Helps You Pass AC.L2-3.1.20[a]
Service Offering | What It Does for AC.L2-3.1.20[a] |
|---|---|
Cyberwatch — Risk Identification | Independent third-party penetration testing, validation, and vulnerability identification surfaces external connections weaknesses tied to AC.L2-3.1.20[a] before a C3PAO does. Cyberwatch produces an external attestation that the control as deployed actually meets the assessment objective. |
Cyberwatch Advanced | Operationalizes the control: Identity & Access Management with adaptive MFA (CyberSecureID), Principle of Least Privilege enforcement, Zero Trust Architecture, attack-surface visibility, password management & rotation, and the cybersecurity training platform with employee attestation. Together these produce the continuous evidence stream AC.L2-3.1.20[a] requires. |
Compliance-as-a-Service | Manages your SSP, POA&Ms, control evidence, and recertification campaigns inside a single platform. Maps every artifact directly to AC.L2-3.1.20[a] and the surrounding Access Control objectives so you walk into your CMMC Level 2 assessment with the binder pre-built and the gap report already burned down. |
vCSO (Virtual CSO) | Executive-level guidance for boards and leadership on scope decisions (CUI boundary), C3PAO selection, control-design trade-offs across CMMC, FTC Safeguards, and PCI, and remediation prioritization aligned with contract-award timelines. |
Engagement model: Most clients begin with a Cyberwatch baseline assessment (1–2 weeks), then move into Cyberwatch Advanced and Compliance-as-a-Service to remediate and harvest evidence ahead of their CMMC Joint Surveillance or full L2 assessment.
Related Articles in CyberKnowledge
External References & Authoritative Sources
NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems
DFARS 252.204-7012 — Safeguarding Covered Defense Information
Are You Ready for the C3PAO? — 10-Point Readiness Check
We can produce, on demand, the documented implementation of AC.L2-3.1.20[a] from the SSP.
A named owner is accountable for AC.L2-3.1.20[a] and is reachable by the C3PAO during the assessment.
The control supporting AC.L2-3.1.20[a] is in fact configured and operating today (not just documented).
Operational evidence covers at minimum the last 12 months and shows the control operating continuously, not as a point-in-time snapshot.
The most recent review or recertification of AC.L2-3.1.20[a] is within the cadence stated in policy.
All open POA&M items related to AC.L2-3.1.20[a] have an executive sponsor and a credible target date.
Cross-references to sibling Access Control objectives are present in the SSP and consistent.
For every CUI-bearing system in scope, the implementation of AC.L2-3.1.20[a] is the same — no special-cases hiding non-compliance.
The Cyberwatch baseline assessment for Access Control has been run within the last 12 months and any findings are remediated or POA&M'd.
A vCSO has reviewed the package against the CMMC Assessment Guide Level 2 v2.13 for AC.L2-3.1.20[a].
Next Step: If you cannot confidently check all 10 boxes above, contact your Northern Data Solutions vCSO to schedule a Cyberwatch assessment. We will deliver a gap report mapped directly to AC.L2-3.1.20[a] and the surrounding Access Control objectives.
Tags: AC.L2-3.1.20[a], cmmc, level-2, domain-ac