AC-20: Use of External Systems

What This Control Requires

AC-20 requires organizations to set terms, conditions, and trust boundaries for every external system that touches their data or connects to their network. Without those guardrails, contractor laptops, cloud applications, partner portals, and personally owned devices all become unvetted entry points into your environment.

In practice, you’ll need to decide which external systems authorized personnel can use to access organizational resources, process controlled information, or transmit sensitive data. You also need to define the highest security category of information those systems are allowed to handle, and where trust relationships are strong enough, document agreed-upon controls in a formal information exchange agreement.

The result is a binary choice for each class of external system. Either establish enforceable terms that align with your security posture, or ban the system outright. There’s no middle ground where an external system operates without documented expectations.

Why It Matters

External systems represent one of the fastest-growing categories of unmanaged risk in most organizations. Every software-as-a-service application, contractor device, and cloud platform that handles your data sits outside your authorization boundary and beyond your direct security oversight.

The result is significant audit exposure across multiple compliance frameworks, potentially leading to certification withdrawal, regulatory findings, or loss of authorization to operate. Federal agencies and their contractors face particular risk because external systems often span multiple authorization boundaries, each with its own set of controls and assessment timelines.

But in most environments, the scope of what qualifies as “external” is broader than many teams realize. It includes personally owned devices, systems managed by other divisions within the same organization but under different authorization boundaries, and cloud services where the provider holds its own separate authorization. Overlooking any of these categories creates gaps that auditors will flag and that attackers will find.

What Attackers Exploit

• Unvetted personal devices connecting to internal systems without endpoint controls
• Cloud applications processing sensitive data without contractual security terms
• Contractor systems with outdated or misconfigured security controls accessing production environments
• Partner connections where trust is assumed but never verified through formal agreements
• Shadow IT services adopted by employees without security team visibility or external attack surface monitoring

How to Implement

The most common failure mode for AC-20 is treating it as a policy-only exercise. Organizations write an acceptable use policy, reference external systems in passing, and never operationalize the control with inventories, technical enforcement, or ongoing verification.

For Your Organization

Step 1: Inventory all external system connections. Catalog every system that authorized personnel use to access your environment or handle organizational data. Include cloud platforms, contractor-managed systems, partner portals, personal devices, and systems from other organizational units with separate authorization boundaries. Assign an owner to each entry.

Step 2: Classify trust levels. For each external system, determine the trust relationship with the owning entity. Systems operated by organizations with existing information exchange agreements or shared governance frameworks sit at a higher trust tier. Systems with no formal agreement require explicit terms and conditions before any access is granted.

Step 3: Define terms and conditions. Document the specific types of applications that can be accessed from each class of external system. Specify the highest security categorization of information that can be processed, stored, or transmitted. Include requirements for endpoint security controls, encryption standards, and acceptable authentication methods.

Step 4: Enforce technical controls. Implement network segmentation, conditional access policies, and device compliance checks that enforce your documented terms. Use mobile device management or endpoint detection tools to validate external devices before granting access.

Step 5: Establish a prohibition list. Identify external system types that pose unacceptable risk and prohibit their use outright. Common examples include public kiosks for accessing controlled information and personal devices without organizational management software.

Common mistakes:

• Maintaining a policy without a current inventory of external systems
• Treating all external systems equally instead of differentiating by trust tier
• Failing to update terms and conditions when the external system’s security posture changes
• Allowing personal devices without any technical enforcement mechanism

For Your Vendors

What to ask in a security questionnaire:

• Does the vendor maintain a policy governing the use of external systems by their personnel?
• How does the vendor inventory and classify external systems that access your data?
• What terms and conditions does the vendor impose on contractor or partner systems that handle your information?
• Does the vendor prohibit specific categories of external systems, and if so, which ones?
• How does the vendor verify that external systems meet agreed-upon security controls?

Evidence to request:

• The vendor’s external system usage policy
• An inventory of external system types authorized to access your data
• Sample terms and conditions or connection agreements for external system owners
• Configuration documentation showing technical enforcement of external system restrictions

Red flags:

• The vendor has no documented policy for external system use
• Personal devices are permitted without endpoint management or compliance verification
• No prohibition list exists for high-risk external system categories
• The vendor can’t demonstrate how they verify external system controls

In practice, self-attestation alone isn’t sufficient. Request evidence that the vendor periodically reviews and updates their external system inventory. Ask for documentation of their most recent review cycle, and confirm that connection agreements include provisions for re-assessment when the external system owner’s security posture changes.

Evidence Examples

Cross-Framework Mapping

Related Controls

• AC-02 — Account Management: governs the lifecycle of user accounts that access organizational systems, including accounts used from external systems
• AC-03 — Access Enforcement: applies access control policies that constrain what authorized individuals can do once connected from an external system
• AC-17 — Remote Access: addresses the secure establishment of remote sessions, which often originate from external systems
• AC-19 — Access Control for Mobile Devices: covers mobile-specific controls that overlap with personally owned device restrictions under AC-20
• CA-03 — Information Exchange: manages the formal agreements between organizations that establish the trust relationships referenced by AC-20
• PL-02 — System Security and Privacy Plans: documents how the organization addresses external system governance within its broader security architecture
• PL-04 — Rules of Behavior: defines the acceptable use expectations imposed on authorized individuals accessing the system from external devices
• SA-09 — External System Services: addresses the acquisition and oversight of services provided by external system operators
• SC-07 — Boundary Protection: enforces the network perimeter controls that separate organizational systems from external connections

Frequently Asked Questions

What Is NIST SP 800-53 AC-20?

AC-20 requires organizations to establish terms and conditions for the use of external systems or to prohibit their use entirely. The control targets any system used by but not part of your organization, including contractor devices, cloud platforms, partner-managed systems, and personally owned equipment. You’ll need to define what information those systems can handle, what applications they can access, and what security controls must be in place before granting any connectivity.

What Happens if AC-20 Is Not Implemented?

Without AC-20, external systems connect to your environment with no formal security expectations, creating unmonitored pathways for data exposure and unauthorized access. Auditors assessing your access control family will flag missing connection agreements and absent prohibition lists as findings. For federal systems, a failed AC-20 assessment can block or revoke an authorization to operate, halting mission-critical activities until the gap is remediated.

How Do You Audit AC-20?

Auditors examine the external system usage policy, connection agreements with external system owners, and the documented list of application types accessible from external systems. They verify that formal documentation defines the maximum security categorization for information on external systems and that configuration settings enforce those limits. Interviews with personnel responsible for managing external system connections confirm that responsible staff periodically review trust relationships and actively enforce blocks on prohibited system categories rather than relying on documentation alone.

What Counts as an External System Under NIST 800-53?

An external system is any system used by but not directly controlled by your organization, where you can’t assess the implementation of required security controls. The definition includes personally owned devices, contractor laptops, cloud services, systems managed by other federal agencies under a different authorizing official, and even systems operated by other divisions within your own organization that fall under separate authorization boundaries. Public-facing interfaces accessed by external users are explicitly outside the scope of AC-20.