AC-20 Use of external systems: requirements and evidence

What AC-20 requires before personal and contractor devices touch your systems

AC-20 requires that, before anyone accesses your systems from a device or service you do not control, or processes your information on one, you either set terms and conditions for that use or identify the controls you assert the external system already has. Consistent with trust relationships, the choice is yours, but one of the two paths must be documented and in place first. The control also requires you to name the types of external systems that are prohibited outright, such as personal email accounts for sending regulated data or unmanaged file-sharing services. If an assessment is coming, or a bring-your-own-device or contractor policy is being questioned, start by checking whether each access path has a documented answer to the question of which path applies.

The hard part is ownership. The control assumes you can say who owns the external system, what it is trusted to do and which of its controls you rely on. In practice, contractors often run their own laptops, ticketing tools and file transfer services, and nobody in the organization has written down which of those tools touch your data. Shadow SaaS compounds this, because a team may connect a personal account to an internal workflow without a review. Before drafting terms, ask the owners of each business process to list every device and service their people or contractors use to reach or handle information, then sort them into systems you assert controls for, systems covered by contract terms, and systems that fall under a prohibition.

Scope matters for the assessment. AC-20 is selected in the low, moderate and high baselines of SP 800-53B Release 5.2.0 but not in the privacy baseline. Its enhancement AC-20(1), which limits authorized use of external systems, and AC-20(2), which restricts portable storage devices, apply at the moderate and high baselines. Confirm with your system security plan which baseline your system is in and whether the enhancements have been tailored in or out, because an assessor will test the enhancements that your baseline selects and the documented justification for any deviation.

Which external systems and access paths fall under AC-20

AC-20 applies whenever authorized people reach organizational systems from equipment the organization does not control, or process organizational information on it. The cards below cover the scoping decisions that determine which terms or asserted controls you need, and why each decision changes the evidence you must keep.

Personal devices used for access

Employees and contractors who reach email, file shares or internal applications from personal laptops and phones fall under AC-20 because the organization cannot configure or inspect those devices. The control requires either terms and conditions for that access or a statement of the controls asserted on the device before access is allowed. Check which applications are reachable from personal equipment, whether browser-only access is distinguished from local data storage, and whether the terms cover device patching, screen lock and reporting of lost devices.

Contractor-managed systems

When a contractor connects its own managed workstations or servers to your environment, those systems sit outside your control even though your people depend on them. The trust relationship, not ownership, determines what terms or asserted controls you need. Confirm which contractor systems can reach your network, what the contract says about their security configuration, and who approves the list of permitted contractor equipment. Contract clauses and the related controls in SA-9 and PS-7 usually carry much of this evidence.

Third-party SaaS that processes organizational information

A SaaS tool that stores or processes organizational data is an external system even when your staff only use it through a browser. AC-20 asks whether the organization has terms for that processing or has identified the controls the provider asserts. Ask for the provider's security documentation, list the data categories it receives, and record which controls you rely on the provider to meet. This is the decision most often missed, because the tool is usually bought by a business unit rather than reviewed by security.

Portable storage devices under AC-20(2)

AC-20(2) limits the use of portable storage devices on external systems, and it is selected in the moderate and high baselines. Once a USB drive or external disk from an outside system can hold organizational data, the restriction applies. Decide whether to block, restrict or permit portable storage on external equipment, then enforce that decision through policy and technical settings. Your evidence should show the rule, the configuration that enforces it and any exceptions approved for specific roles.

Systems the organization cannot inspect

Some external systems will not let you examine their configuration, logs or patch status. For these, the control's option of identifying asserted controls matters most, because you cannot verify them directly. Record what the provider or partner has committed to in writing, which parts of the assertion you cannot test, and what compensating limits you place on what the system may access or hold. Assessors will ask how you decided to accept that residual risk and who approved the decision.

How an assessor tests AC-20

This table maps the three SP 800-53A determination statements for AC-20 to the examine, interview and test methods an assessor uses, along with the objects they inspect and the evidence they request. Read each row as a question the assessor will ask, then confirm your own documents answer it before the assessment starts.

Assessment element	What the assessor checks	Evidence usually requested	Common finding
Determination statement 1: terms and conditions or asserted controls	Whether the organization set terms and conditions for access from, and processing on, external systems, or identified the controls it asserts on them, consistent with trust relationships	Signed terms of use, contractor or partner agreements, asserted-control definitions tied to each trust relationship	Terms exist for some external parties but not for personal devices or contractor laptops
Determination statement 2: timing before access or processing	Whether the terms or asserted controls were in place before authorized individuals first accessed the system or processed information from external systems	Dates on agreements, onboarding records, first-access logs for external sources	Agreements signed after access began or never dated
Determination statement 3: prohibited system types	Whether the organization defined the types of external systems it prohibits and whether that list matches what it actually enforces	Written list of prohibited system types, enforcement settings or access rules, exception records	Prohibited types are not defined, or the list names types the organization cannot enforce
Examine: external systems terms and conditions	Content, scope, approval and currency of the terms, including who they bind and which systems they cover	Terms documents with version history, approval records, review dates	Terms are undocumented, unapproved or unreviewed since the system changed
Examine: list of application types accessible from external systems	Which applications may be reached from external systems and whether that list is current and authorized	Application access inventory, access policy by application, system security plan entries	No inventory exists, so the assessor cannot confirm which applications are exposed
Interview: personnel who define terms for external system use	Whether the owners of the terms understand the trust relationships, the asserted controls and how they are reviewed	Named role assignments, interview notes, evidence of who approves changes to terms	Responsible staff cannot explain the asserted controls or who verifies them
Test: asserted controls or terms in practice	Whether access from external systems is limited as the terms state, where the organization relies on the external system's own controls	Sample access records, configuration evidence, results of checks on the asserted controls	Terms require controls on external devices that the organization never verifies
Related controls the assessor may trace	Consistency with AC-2, AC-17, SA-9 and SC-7 for accounts, remote access, external services and boundary protection	Cross-references in the system security plan and links to those control records	AC-20 is documented in isolation and conflicts with remote access or external service records

How to implement AC-20 in sequence

This sequence turns AC-20 from a policy statement into a working record of which outside systems can reach or handle organizational information, on what terms, and under which asserted controls. Each step produces an artifact that an assessor can examine and that the organization can maintain as its environment changes.

Inventory external access paths
Identify every way people reach organizational systems or handle organizational information from systems the organization does not control. Include personal devices, contractor-managed machines, partner portals, web-based SaaS accounts used for work, and removable media. Owners are typically the system owner with input from IT operations, HR and procurement. The output is a register listing each external system type, the users who connect from it, the data it touches and the access method. The step is done when the register is reviewed against identity logs and remote access records, so that known gaps are visible.
Classify trust relationships
Group each entry in the register by the trust relationship behind it, such as employee-owned devices, contractor-managed systems, business partner systems and public web services. Record who contracts with whom, what the organization can verify, and what the external party is willing to commit to. AC-20 expects the trust relationship to drive the choice of mechanism, so this classification is the basis for every later decision. The output is a trust classification table with one row per class, reviewed by the control owner and linked to the entries in the inventory.
Choose terms or asserted controls per class
For each trust class, decide whether the organization will set terms and conditions the external party must accept, or identify the specific controls it asserts are in place on that external system before access or processing is allowed. Terms suit classes where the organization can require commitments but cannot inspect the system. Asserted controls suit classes where the organization needs named safeguards, such as disk encryption or endpoint protection, to be in place. Legal and procurement staff usually draft the terms, while security staff define the asserted controls. The output is a decision record per class, stating the chosen mechanism and the reason for it.
Define prohibited system types
List the types of external systems that may not be used to access organizational systems or process organizational information, such as unmanaged public file-sharing services, personal email accounts for work records or devices without supported operating systems. Base the list on data classification and on the risks identified in the trust classes. The security owner approves the list, and the list is written in terms specific enough that users and assessors can tell whether a system falls inside it. The output is an approved prohibited-types list that feeds the acceptable use guidance and the technical block lists.
Set limits on authorized use and portable storage
Define what authorized users may do from external systems: which applications they may use, which data classes they may access, and whether any data may be stored locally. AC-20(1) and AC-20(2) address these limits in the moderate and high baselines, covering authorized use limits and restricted use of portable storage devices. Confirm each limit with the platform team, since some limits depend on what the self-hosted platform can enforce, such as session restrictions or download controls. The output is a limits specification that names permitted applications, data classes and portable storage rules for each trust class.
Document and communicate the decisions
Write the outcome into the access control policy and procedures, the system security plan and the rules of behavior, so each decision is traceable to the trust class, mechanism, prohibited types and limits. Obtain acceptance of the terms from external parties, and brief internal users on what they may and may not do from external systems. Keep records of who accepted what and when. The output is a signed or recorded acceptance set, updated procedures and a communication record that an assessor can examine alongside the register.
Confirm the sequence with an independent assessor
Before relying on the sequence in an assessment, have the organization's assessor or the independent auditor check that each output exists, matches the inventory and is in use. The implementation partner can prepare the register, decision records and technical configuration evidence, but only an independent assessor or auditor issues findings or reports. Confirm with the assessor which examine, interview and test methods they will apply, since these follow the SP 800-53A assessment procedures for AC-20. The output is the assessor's list of questions and evidence requests, which the team uses to close any gaps before the formal assessment.

How the terms and asserted controls work in practice

The two AC-20 paths differ in who does the checking. On the terms and conditions path, the organization writes the rules itself: which external systems may be used, what authorized individuals may access from them, what information may be processed there, and which applications are reachable. Nothing is assumed about the external system's security. On the asserted controls path, the organization identifies the specific controls it relies on the external system to have in place, such as encryption of stored data or device management, and records that reliance. The organization still has to establish that the assertion is credible, because it is accepting someone else's control environment as part of its own risk picture. Trust relationships decide which path fits. A contractor's managed workstation that the organization can contract to protect is usually a candidate for asserted controls. A personal device, or a consumer cloud service with no contractual relationship, usually calls for terms and conditions, or for a prohibition on use altogether.

The related controls show where each path gets its inputs and where its outputs go. AC-2 governs the accounts that let people reach the system from outside, so the list of authorized external users must match what the terms permit. AC-17 covers remote access, and AC-19 covers organization-controlled mobile devices, so an external device that connects through those mechanisms needs the connection requirements those controls set. CA-3 governs information exchange agreements, which is where a contractor's or partner's obligations are normally written down and kept current. PL-2 is where the system security plan records the external systems in use and the controls asserted on them. SA-9 governs external system services and sets the expectations placed on providers, including how their controls are monitored. The practical check for a reader is to trace each external system through these records: is there an agreement, a plan entry, a named account population and a documented reason for the path chosen?

A useful first step is to inventory every external system that touches organizational data or accounts and tag each one with its trust basis. Confirm with your assessor how they expect the terms and assertions to be evidenced, since the required artifacts depend on the organization's own risk decisions and the authorization boundary. Expect the work to be mostly documentation and agreement management, with a smaller technical component in verifying that remote and mobile connections follow the rules set. Where DeployOpen implements a self-hosted platform, it can prepare the account structures, connection settings and documentation that match these records. The organization still decides which trust basis applies to each external system, and an independent assessor determines whether the resulting evidence meets the control.

Which evidence passes an AC-20 assessment

An assessor testing AC-20 looks for a documented decision about each external system that touches organizational information, backed by the terms, asserted controls and restrictions that decision relied on. The cards below cover the artifacts that carry that decision, and the routine that keeps each one current between assessments.

External system terms and conditions

These are the written terms that govern how authorized individuals may access organizational systems from an external system or process organizational information on it. Assessors examine them against the organization's own requirements, so the terms should name the access permitted, the data classes allowed and the obligations on the external party. Check that each term set has an owner, a version date and a link to the system it covers. Review them whenever a provider changes its service or a new device type is approved.

Asserted control statements

When the organization relies on controls implemented by the external party instead of negotiating terms, it must identify those controls in writing. Each statement should name the control, the external system it applies to and the evidence the organization received, such as an independent report or a configuration summary. Confirm that each assertion matches the trust relationship recorded for that system. Stale assertions are a common gap, so set a review date for each one and record who accepted the residual risk.

List of prohibited system types

AC-20 requires the organization to prohibit defined types of external systems, so the prohibited list must be specific enough to test. Examples include unmanaged personal devices, public file-sharing services or systems outside approved jurisdictions, but the actual list depends on the organization's risk decisions. Assessors check that the list is approved, published to staff and reflected in technical blocks where those exist. Review it when new system types appear and log each exception with an expiry date.

List of application types accessible from external systems

This inventory records which applications may be reached from external systems and under what conditions, such as web mail or a read-only portal. Assessors use it to confirm that the access restrictions match the decisions in the terms and asserted controls. Each entry should name the application owner, the permitted external system types and any data restrictions. Regenerate the list from identity and access configuration, not only from memory, so it reflects what is actually enabled.

Contractor agreements and portable storage rules

Contractor systems and portable storage devices are two places where external processing commonly happens without a central record. Contractor agreements should state which contractor systems may access organizational systems, the controls they must maintain and the right to audit. Portable storage rules, the subject of the AC-20(2) enhancement in the moderate and high baselines, should define when removable media may be used, how it is encrypted and how its use is logged. Keep both current by tying renewal dates to the contract calendar.

Records of the trust relationship decision

Each approval to use an external system should leave a record of the trust relationship decision: the risk assessment, the reviewer, the conditions attached and the outcome. This record connects the terms, assertions and restrictions to a specific decision, which is what an assessor asks to see first. Store decisions in a system with version history so changes can be traced. Set a recurring review, and trigger an earlier review when the external system's ownership, location or service scope changes.

What meeting AC-20 costs in money and effort

The first cost is building the foundation: an inventory of every external system path that touches organizational information, drafted terms and conditions or asserted-control statements for each trust relationship, and written definitions of the prohibited system types. The organization pays its own staff for most of this, because the people who know which contractors log in from which devices and which personal devices reach email or file shares are inside the business. Legal or procurement review of terms adds cost that depends on how many agreements already exist and how much negotiation is needed.

Inventory of external paths: Staff time to find remote access routes, contractor accounts, personal device use and third-party platforms that handle organizational data.
Terms and conditions drafting: Legal and security effort to write or update the rules for each class of external system, or to define the controls you require the external party to assert.
Prohibited type definitions: Security time to decide which system types are barred, such as unmanaged personal devices for privileged functions, and to document the reasons.
Application list for external access: Effort to list which applications may be reached from external systems, which the assessment procedure expects you to examine.
Implementation partner support (optional): If you engage an implementation partner, ask for a fixed-scope quote naming the deliverables, such as the inventory, the policy text and the evidence set.

Ask any provider to state which of these items are included in the fixed scope and which remain with your own staff.

Where AC-20 programs usually fall short

AC-20 programs tend to fail on paperwork that never reaches operations: lists that were never built, terms that no one enforces and rules that assume the organization controls a device it does not own. The cards below cover the gaps assessors most often find, each with a closing action the team can take before the assessment begins.

No inventory of external systems

AC-20 cannot be applied to systems nobody has listed. Many organizations know their own data centers and cloud accounts but not the contractor portals, vendor-hosted collaboration tools and personal devices that staff use to reach internal applications. Assessors typically ask for the list of external systems and the types of applications accessible from them, so an incomplete inventory fails the first examination. Close the gap by building the list from identity provider logs, network access records and contract registers, then assigning each entry an owner.

Terms that stop at the contract

Some organizations rely on a sentence in a vendor agreement and assume AC-20 is met. The control allows either defined terms and conditions or identified controls asserted on the external system, but the terms must be in force before anyone accesses the system or processes organizational information on it. A signed contract that nobody checks against actual access patterns does not show that the terms are operating. Close the gap by mapping each agreement to the specific access and processing it permits, and confirming that the asserted controls are written down.

Personal devices without a prohibition

Staff often reach email, file shares or internal dashboards from home computers and personal phones without any rule against it. AC-20 asks the organization to prohibit defined types of external systems, so silence is a finding even when no one has misused a device. The prohibition should name the device classes and applications it covers, and it should match what the access control stack can actually block. Close the gap by writing the prohibited system types into the access control policy and testing whether conditional access rules enforce them.

Portable storage rules missing at moderate

Moderate and high baselines add AC-20(2), which restricts the use of portable storage devices on external systems. Many programs written for the low baseline never add it, so USB drives and similar media can move organizational data onto systems the organization does not control. Assessors check whether the restriction is defined, who may use removable media and how the restriction is enforced in practice. Close the gap by defining the permitted use of portable storage, configuring endpoint controls to match, and recording exceptions.

Authorized use limits never defined

AC-20(1) requires limits on how authorized individuals may use external systems to access organizational systems or process information on them. Programs often state that access is allowed without saying for what purposes, from which locations or with which data classes. Without those limits, the organization cannot show that its terms were actually defined and that users were told about them. Close the gap by writing short use limits for each external system category and tying them to the data classification scheme.

Terms and lists never reviewed

External systems, vendors and personal device practices change faster than most policies. A list that was accurate at the last audit can miss new SaaS tools, retired contractors and vendors whose hosting has moved. Assessors look for evidence that the external systems list, terms and prohibitions were reviewed on a defined schedule and after material changes. Close the gap by setting a review date for each entry, assigning a reviewer, and keeping the dated review records with the policy set.

Questions buyers ask about AC-20

What does AC-20 cost to meet and what drives the effort?

No supplied source gives a price for AC-20, and NIST states it does not estimate compliance or certification costs. The effort depends mostly on how many external systems your staff and contractors use, how many types of those systems you need to prohibit, and whether you already have signed terms of use or documented asserted controls. Costs fall into two groups. One-time work includes inventorying external systems, drafting terms and conditions or control assertions, and defining prohibited system types. Recurring work includes reviewing agreements as trust relationships change and producing evidence for each assessment. Ask any provider for a fixed-scope quote that lists the systems in scope, the documents to be written, and who signs off on each one.

How long does AC-20 work take to finish?

The duration depends on how many external system types you have, how many agreements already exist, and how quickly approvers can review them. NIST does not set an implementation timeline for AC-20. Federal timelines come from OMB Circular A-130, and NIST's risk management FAQ leaves them to that guidance. Under FISMA, Inspectors General assess agency security independently and report to OMB, which is a separate step from your own readiness work. For a commercial program, ask the provider to split the schedule into inventory, document drafting, approval and evidence collection, and confirm which dates depend on your internal reviewers.

What does AC-20 require from our internal staff?

AC-20 needs people who can speak for the business, not only for IT. SP 800-53A points assessors to personnel who define the terms and conditions for using external systems to reach organizational systems, so those owners must be named and available. Expect to involve the policy owner, the system owners who approve access, HR or the contract team for contractors and personal devices, and the security team that reviews assertions. Staff also need to supply inventory data, such as which applications are reachable from outside systems, and confirm that prohibited types are blocked in practice. Plan for their time before the engagement starts.

Can our own team implement AC-20 without an outside partner?

Yes, an internal team can write and maintain the AC-20 documents if it has the authority to define terms, the time to inventory systems, and someone who understands the trust relationships involved. Many organizations do this in-house for small populations of external systems. A partner becomes useful when the inventory is large, when several business units each use different contractor or personal device arrangements, or when the team lacks the time to collect evidence consistently. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own environment and prepares systems and evidence for assessment, but it does not own your controls or issue assessment results.

What does an independent auditor check for AC-20?

An independent assessor tests AC-20 using the examine, interview and test methods in SP 800-53A. The assessor reads the terms and conditions or asserted-control documents, examines the list of application types accessible from external systems, and interviews personnel who define those terms. The assessor then checks whether the documents match actual practice, such as whether prohibited system types are blocked. Only the assessor issues the findings. Your partner can prepare the evidence, but the independent party decides whether the control is satisfied. Ask your assessor which artifacts they expect before you finalize the documents.

How does AC-20 relate to CSF 2.0 subcategories ID.AM-02 and ID.AM-04?

NIST's crosswalk from CSF 2.0 to SP 800-53 Release 5.2.0, posted in November 2025, maps AC-20 to ID.AM-02 and ID.AM-04. ID.AM-02 concerns the inventory of software, services and systems managed by the organization, and ID.AM-04 concerns the inventory of services provided by suppliers. An AC-20 inventory of external systems can support both, but the crosswalk is not comprehensive, as NIST states, so it should not be treated as proof that either subcategory is met. Confirm the mapping against the crosswalk itself and document how your external system inventory serves each subcategory.

Which evidence should we keep to show AC-20 works?

Keep the signed terms and conditions or the documented asserted controls for each external system type, the list of prohibited system types, and the list of application types accessible from external systems. Retain approval records, review dates and records showing who defined each term. Versioned documents help assessors see what changed and when. For example, a wiki with version history such as XWiki can show revision history, and BookStack's role-based permissions can limit who edits approved content. Both are illustrative tools you may evaluate, and you should confirm their fit for your environment before relying on them.

How DeployOpen prepares AC-20 evidence

DeployOpen's part of AC-20 work starts with a written scope that names the external system types in question, such as personal devices, contractor-managed endpoints, partner environments and third-party SaaS tenants that touch organizational information. The organization decides which of these it will prohibit, which it will allow with terms and conditions, and which it will allow only when specific controls are asserted, and that decision is the input the rest of the work depends on. DeployOpen then prepares the technical side: it configures the self-hosted platforms so that access from outside systems is routed through the controls the organization has chosen, documents the connection paths, and records the list of application types that can be reached from external systems. Deliverables and timelines are agreed in writing before work begins.

The evidence an assessor will ask for usually includes the signed or approved terms and conditions for external system use, the list of prohibited system types, the asserted-control statements for each permitted external system class, and records showing that those statements were reviewed against the trust relationship. DeployOpen can prepare working drafts of these artifacts in a self-hosted wiki so that each change is versioned, and it can set up a page inventory of external access paths that the client's owners review and approve. Confirm with your assessor which formats they accept and who must sign the terms, because those decisions belong to your organization and its legal function, not to the implementation partner.

Ownership stays with the organization throughout. The client owns its controls, decides which external systems are authorized, and accepts residual risk. DeployOpen does not issue audit reports, attestations or certifications. Those come only from independent assessors or certification bodies, who examine the artifacts, interview the personnel named in the procedures and test whether the configured limits hold. Ask any partner to state this division of responsibility in the statement of work, and ask which assessment activities, if any, sit outside the agreed scope. DeployOpen can support the client's own controls after the assessment through retainer-based reviews, but it cannot sign off that the control is satisfied.