03.01.20 Use of external systems: requirements and evidence

What 03.01.20 use of external systems asks for in plain terms

03.01.20 asks the organization to block use of external systems unless it has specifically authorized that use, to set the security requirements those external systems must meet, and to allow access to the system or handling of CUI only after those requirements have been verified and an approved connection or processing agreement is in place. It also requires restricting use of organization-controlled portable storage devices on external systems. If your staff reach CUI from personal laptops, partner networks or SaaS tools, this requirement is where you must show that each path was decided on, not simply tolerated.

The risk is CUI leaving the boundary you control. An unmanaged endpoint, a personal device with a synced folder, or a partner environment that processes CUI without written terms all move data outside the monitoring and access controls the rest of your system relies on. The difficulty is usually discovery rather than policy. Teams adopt browser-based tools and personal devices without telling anyone, so the first task is an inventory of how people actually connect, not a review of what the policy says. You also have to set the organization-defined parameter, which is the security requirements an external system must satisfy before anyone uses it. NIST does not supply that value, so the organization must define it and be able to defend it to an assessor.

Rev. 3 folded the former 3.1.21, which covered portable storage on external systems, into this requirement, and NIST classifies the change from Rev. 2 3.1.20 as significant, with more detail and foundational tasks. Confirm with your assessor how they will treat evidence for the portable storage element under the Rev. 3 wording, and confirm which Rev. 2 version your contract currently references, because the scoring and assessment context differ between the two.

Which external systems and data fall under 03.01.20

Under 03.01.20, the first question is not whether a system is external but whether it can reach the organizational system or handle CUI. Each card below is a scoping decision the organization must settle and record, usually in the system security plan, before anyone is allowed to connect or store CUI on a system it does not control.

Personal devices and home PCs

An employee's personal laptop or home desktop is an external system the moment it opens a session to the CUI environment or saves a CUI file. The decision is whether personal devices are prohibited outright or permitted only after the organization sets security requirements for them and verifies those requirements. If permitted, define what a compliant device looks like, such as managed disk encryption, current patches and screen lock, and confirm that the check runs before each access is granted. Note that the organization owns this decision even if the federal agency has not assigned the ODP values.

Contractor and partner systems

When a subcontractor, shared-services provider or research partner connects to your system, its environment is external to your boundary. Decide whether that party may connect at all, and if so, which security requirements its systems must meet before the first connection. Keep the approved connection or processing agreement on file, and make sure it states who verifies the requirements and how often. Confirm with each partner who holds the CUI on their side, since that answer determines whether their systems fall inside your scoping analysis.

SaaS tools and cloud services holding CUI

A SaaS collaboration tool, ticketing system or cloud storage account that stores or processes CUI is an external system even when it is widely used across the business. Decide whether each service may handle CUI, then document the terms and security requirements it must satisfy, such as encryption and administrator access controls. Check whether the service is authorized for CUI under the requirements the contract imposes, and confirm this with the provider rather than assuming it from marketing material. Services that only hold non-CUI business data may fall outside this decision.

Third-party processing of CUI

A payroll processor, print vendor or analytics provider that receives CUI for processing is a different case from a tool your staff log into. The decision is whether the processing relationship is authorized, what security requirements the provider must meet, and where the agreement records them. Ask the provider where CUI is processed, which of its own systems and staff touch it, and how it reports incidents. Record the answers in the processing agreement so the assessor can trace each external processing path back to an approved agreement.

Portable storage moved between systems

A USB drive or external hard disk that moves CUI between your system and an external computer is a common gap in this requirement. The decision is whether organization-controlled portable storage may be used on external systems at all, and if it may, under what conditions. Many organizations prohibit it on external systems and document that rule in the access control procedures. Confirm that the restriction is enforced technically where possible, and that staff know which devices count as organization-controlled.

Where 03.01.20 ends and 03.16.03 external service providers begins

03.01.20 governs the act of using an external system, while 03.16.03 governs the service provider relationship itself. An assessor reading 03.01.20 asks whether people who reach the organizational system or handle CUI from an external system do so only under an authorization, only after the organization has verified the security requirements it set, and only under an approved connection or processing agreement. The subject is the user's activity and the organization's gatekeeping of it. Whether the organization is buying a managed service, a hosted tool or a cloud platform is a separate question that 03.16.03 addresses, and the Rev. 3 discussion of 03.01.20 points readers there for that relationship.

In practice, the two requirements meet at a few decisions. Before an employee logs in from a personal laptop, a partner's cloud tenant or a vendor's support portal, the organization must have decided that the external system is permitted, defined the requirements it has to satisfy (the ODP value for 03.01.20), and verified them. Those verification results belong to 03.01.20. The contract terms, security obligations and incident commitments a provider accepts when the organization buys its service belong to 03.16.03. A useful check is to list every external system people actually use for CUI, then confirm for each whether a use agreement exists, whether the organization can point to a verification record, and whether a separate acquisition record covers the provider. Confirm with your assessor how they expect those records to be cross-referenced, since the boundary is drawn by the assessment objectives in SP 800-171A Rev. 3 and by your own system security plan.

The overlap matters for scoping and for planning work. A provider can satisfy the acquisition expectations in 03.16.03 and still be a system your users must not reach from unmanaged endpoints, so 03.01.20 controls remain necessary. Conversely, a well-governed user access process does not replace a provider review. Assign the two to clearly named owners, usually the security or compliance lead for use decisions and the procurement or vendor management function for provider obligations, and make sure each owner can show evidence to the assessor without relying on the other. Ask an implementation partner to map your external system inventory against both requirements before the assessment, so gaps appear in your own records rather than during the assessor's examination.

How an assessor tests 03.01.20 and what they ask to see

This table maps each assessment element for 03.01.20 to the SP 800-171A Rev. 3 methods an assessor uses, the evidence they will request, and the findings that most often appear. Read it as a checklist you can run against your own external system use before an assessor arrives. The main takeaway is that policy alone does not pass: assessors look for proof that the security requirements are enforced before each external system is used.

Assessment element	Method and objects	Evidence requested	Common findings
Policy and terms for external systems	Examine the access control policy, procedures for the use of external systems and the terms and conditions for their use	Current policy and procedures, signed terms and conditions, revision history and the approval record	Policy exists but does not name who may approve external systems or what the terms must cover
Prohibition of unauthorized use	Examine procedures and interview personnel with information security responsibilities about how unauthorized external systems are blocked or reported	Documented authorization list of permitted external systems, examples of requests denied or escalated	No defined authorization step, so staff use personal email, file sharing or unmanaged devices to handle CUI
Security requirements set for external systems	Interview personnel responsible for defining terms, conditions and security requirements, and examine the documented requirements	Written security requirements for external systems and the value assigned to the organization-defined parameter	Requirements are generic, or the organization-defined parameter value is missing, which fails the ODP check
Verification before use or access	Test the mechanisms that enforce the security requirements, and examine records showing verification before each authorized use	Verification records per system, configuration evidence, dated sign-offs before first access	Requirements are written but never checked, so access is granted before verification is recorded
Connection or processing agreements	Examine the approved connection or processing agreements and interview the people who sign and maintain them	Executed agreements for each external system used to access the system or handle CUI, with review dates	Agreements exist for major providers only, or they lapsed and no one tracked renewal
Portable storage restriction on external systems	Test the mechanisms that restrict organization-controlled portable storage devices on external systems, and examine the restriction rules	Device control settings, rule exports, and records of exceptions and approvals	Restriction is documented but not enforced on personal or contractor-owned external systems
Organization-defined parameter defined	Examine the parameter value for the security requirements to be satisfied before external system access	Stated ODP value in the system security plan or policy, with the date and approver	ODP left blank or described vaguely, such as 'appropriate security', which an assessor cannot test

How to implement 03.01.20 in the order that produces evidence

This sequence moves from defining what an external system must satisfy to proving that rule was applied to each connection, so an assessor can trace policy, verification, agreements and storage restrictions back to specific records. Each step closes with an artifact the organization owns and can show during a review.

Define the ODP security requirements for external systems
Start by choosing the security requirements an external system must satisfy before any authorized person may use it or reach the system. 03.01.20 has one organization-defined parameter for this, and if the federal agency you contract with has not specified values, your organization must assign them. The system owner and security lead should agree the list, then record it in a signed ODP value record that names each requirement, its owner and the date it was approved. This step is done when the record exists and the system security plan points to it.
Write the prohibition and authorization rule
Write the rule that prohibits use of external systems unless a specific authorization is granted, and define who can grant it and how. The rule should cover access to the system and any handling of CUI on external systems, because the requirement treats both the same way. Keep the rule in the access control policy and the procedures for using external systems, since an assessor will examine both. This step is done when the approved policy and procedure documents are published and the authorization steps are written down.
Build the verification checklist for external systems
Turn the ODP requirements into a checklist that someone can complete before granting access. Each item should state what is checked, the evidence collected and who signs off. Typical items include whether the external system is managed, whether its access controls and encryption meet the ODP values and whether the user's own device or environment is covered. Use the checklist before the first use and again when the external system changes materially. The output is a completed, dated checklist for each external system, kept with the access request. Confirm with your assessor which level of detail they expect.
Set up connection or processing agreements
For each external system that connects to your system or processes CUI, put an agreement in place that states the security requirements, the permitted use and the terms for handling data. Approval should happen before any connection is used. Record each agreement in an agreement register that shows the external system, the owner, the approval date, the ODP requirements it covers and the review date. Ask your legal and contracts team to confirm the agreement language, since requirements for external service providers also appear in the system and services acquisition family. The register is the artifact an assessor will ask to see first.
Restrict organization-controlled portable storage on external systems
Write a rule that prevents organization-controlled portable storage devices, such as USB drives, from being used on external systems unless the authorization process allows it. Configure endpoints and the management tools you control to enforce the rule where possible, and document any exceptions with the reason and approver. Keep a record of the configuration settings and test results that show the restriction works. Confirm the technical method with your platform team, because the enforcement depends on the operating system and device management tools you run. The output is a restriction standard, its configuration evidence and an exceptions log.
Set up recurring review of external system use
Establish a review cycle that checks whether each external system still meets the ODP requirements, whether its agreement is current and whether any portable storage exceptions remain justified. Use the agreement register and the verification checklists as the inputs. Record each review with the reviewer, the findings and the actions taken, and feed open items into your plan of action and milestones. Set the review frequency in your own policy and confirm it with your assessor, since the requirement does not fix one. The evidence is a dated review log that shows the cycle is operating.

Evidence that passes a 03.01.20 review

An assessor testing 03.01.20 looks for a policy, a working process, and records that show the process ran. The cards below cover the artifacts that connect those three, and each one needs a review date and version history so it still reflects the environment at assessment time.

Access control policy and external system procedures

The policy states that external systems are prohibited unless specifically authorized, and the procedures explain how a person requests that authorization and who approves it. An assessor will examine both documents, so check that the procedures name the real steps used today, not the steps from the last rewrite. Set a review date on each document, record the approver, and keep prior versions so you can show what the rule was on any earlier date.

Approved external systems list

This register names each external system people may use to reach the system or handle CUI, the business owner, the verification date, and the approval status. Verification records should show when the security requirements were checked and by whom, so the list is more than a set of names. Review it on a fixed schedule and remove systems whose agreements have ended, because stale entries are a common reason an assessor questions the list.

Signed connection and processing agreements

Each external system used under 03.01.20 should have a retained connection or processing agreement that the authorized parties have signed. The agreement should state the security requirements the external system must meet and the conditions for handling CUI. Keep a register of agreements with expiry and renewal dates, and confirm that the terms still match the current requirements when an agreement is renewed.

Portable storage rules and enforcement logs

Organization-controlled portable storage devices must be restricted on external systems, so the rule itself and the technical control that enforces it both need evidence. Logs from endpoint, USB or data loss prevention tools show whether the restriction actually blocked or recorded use. Confirm which tool produces these logs, which device classes it covers, and how often someone reviews the exceptions.

Role descriptions for people who set terms

Assessors interview the people who define terms, conditions and security requirements for external systems, and they check that those people understand their role. Write role descriptions that name the responsibility, the decision rights, and the information security duties tied to external system use. Review them when reporting lines change, and keep the version history so each interview answer can be matched to the role as it stood at that time.

ODP value record

03.01.20 has one organization-defined parameter: the security requirements an external system must satisfy before anyone is allowed to use or access it. NIST does not assign that value, so the organization must define it and show the definition is in place. Record the chosen requirements, the approver, and the date, and review the value whenever the requirement set changes or a federal agency specifies its own values.

What meeting 03.01.20 costs in money and effort

This table breaks down the cost and effort components of meeting 03.01.20 for external systems, showing who does the work, whether each cost is one-time or recurring, what drives it up, and how to keep it down. No figures are supplied for this requirement, so use the table to structure quote requests and internal budgeting rather than to estimate totals.

Cost component	One-time or recurring	Cost drivers	How to keep it down
Policy and procedure drafting for external system use	One-time, with periodic review	Number of external system types in use, existing access control policy maturity, and how many approval paths exist	Reuse the access control policy and extend it with one external-system section rather than writing a standalone document
Verification work for each external system	Recurring per system and per re-verification	Count of external systems, how many security requirements are defined, and whether checks are manual questionnaires or technical tests	Define a standard requirement set and a tiered review so low-risk systems need less evidence
Agreement negotiation and legal review	One-time per agreement, with renewals	Number of providers, contract leverage, and whether terms for use and CUI handling are standard or custom	Maintain a template connection or processing agreement and ask counsel to review it once
Enforcement tooling or licenses	Often recurring (subscription or support); open-source options may have no license fee	Choice of commercial versus self-hosted tools, boundary and firewall capacity, logging volume, and staff to operate them	Use self-hosted open-source firewall, web application and wiki tools where they meet your needs, and confirm each capability before relying on it
Staff time for exceptions and approvals	Recurring	Frequency of requests for unauthorized or temporary external system use, and how quickly approvers respond	Publish clear criteria for authorized use so most requests are answered from policy
Restrictions on portable storage on external systems	One-time setup, recurring monitoring	Number of removable media devices, endpoint management maturity, and whether external systems are unmanaged	Block or restrict organization-controlled removable storage through existing endpoint controls where the platform supports it
Auditor sampling and evidence requests	Recurring at each assessment cycle	Number of external systems sampled, how well agreements and verification records are indexed, and interview time	Keep one register of external systems with agreement, verification date and owner so samples can be pulled quickly
Outside review or implementation support	One-time or retainer, by written scope	Scope of systems, existing documentation gaps, and whether the organization needs help preparing evidence	Agree deliverables and scope in writing before work starts and ask for a quote that separates each component

Which self-hosted open-source tools support the external system evidence

No open-source tool satisfies 03.01.20 by itself, because the requirement is about the organization's decisions on external systems. The four tools below each produce a different piece of evidence an assessor may examine: enforced connection paths, a version history for agreements and policy, role-based authorization records, and web entry point protection.

OPNsense for connection paths

OPNsense (BSD-2-Clause) is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases let you group the approved external system addresses once and reuse them in rules. Enabling logging on each rule match gives you a record of which external connections were actually permitted. Confirm in your own environment that the rule set matches the external systems your authorization process approved, and that logs are retained long enough for an assessor to sample them.

XWiki for agreement and policy history

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. You can compare any two versions and roll back to an earlier one. This supports a register of security requirements for external systems, connection agreements and the procedures for approving their use, because an assessor can see when each term was set and who approved the change. Confirm that your deployment retains the full history and that approval records live in the same place as the documents they support.

BookStack for documented authorization

BookStack (MIT) assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. You can use this to restrict who may edit the external system authorization list and the security requirements that external systems must meet. Keep the role model aligned with the people your policy names as responsible for approving external use. Confirm the permission settings in your own instance, because an assessor will compare the documented role model with the actual access granted.

Coraza for web entry points

Coraza (Apache-2.0) is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It inspects web traffic for attacks such as SQL injection, cross-site scripting and code injection, and integrates with Caddy, HAProxy, Traefik and Nginx. It protects the web entry points that people use to reach your system, but it does not govern which external systems may be used or what they must satisfy. Treat it as supporting evidence for boundary protection, and document the authorization decision separately.

Who owns each part of 03.01.20 and where the auditor stops

Your organization owns the decisions that 03.01.20 is built around. Leadership and the system owner must decide which external systems may reach the organizational system or handle CUI, what security requirements those systems must satisfy, and which individuals may approve their use. These choices are the organization's to make and to defend, and an assessor will ask who made them and when.

Policy and terms: Approve the access control policy and the terms and conditions for external system use, and keep them current with the actual environment.
ODP values: Assign the security requirements that external systems must satisfy before use. NIST does not supply these values, so the organization must define them unless a federal agency has specified them.
Approval decisions: Record each authorization to use an external system, with the approver's name, date and the requirements verified.
Agreements: Own and sign the connection or processing agreements, and retain them with the system security plan.
Ongoing review: Re-check approvals when systems, providers or CUI flows change.

Confirm that a named role can produce the policy, the ODP values, the approval records and the signed agreements on request, without relying on a consultant to locate them.

Questions buyers ask about 03.01.20 before hiring help

How long does work on 03.01.20 take, and what drives the timeline?

The timeline depends mostly on how many external systems your people already use, how many of them have written terms, and how many security requirements you still need to define. Requirement 03.01.20 is a single requirement, but it touches policy, procedures, agreements and technical enforcement at the same time, so the work is rarely just a document update. Ask any implementation partner for a written scope that lists the external systems in question, the agreements to review, and the technical checks to build, then compare the timeline against that list. Confirm the required evidence and sequencing with your contracting agency or assessor before work starts.

Can a small team handle 03.01.20 without outside help?

A small team can often write the policy and collect the agreements itself, provided someone owns the decision on which external systems are authorized. The harder parts are defining the security requirements an external system must meet, verifying them before access, and enforcing the portable storage restriction on systems you do not control. Those steps need people who can read configurations and test them, so many teams split the work: internal staff own the decisions and outside specialists prepare the technical evidence. Whichever path you choose, the organization remains responsible for its controls, and an independent assessor decides whether the evidence meets the requirement.

Does the federal agency set the organization-defined parameter for 03.01.20?

Sometimes, and you must confirm it. Requirement 03.01.20 has one organization-defined parameter: the security requirements an external system must satisfy before authorized individuals may use it or access it. NIST does not assign that value. If the federal agency with the contract does not specify it, the nonfederal organization has to assign it to complete the requirement. Ask the contracting officer or the agency's program office in writing whether they publish ODP values, and record the answer in your system security plan. If no value comes from the agency, the value you choose should be documented and reviewed by the assessor before the assessment.

Can personal devices ever be allowed under 03.01.20?

Personal devices can be allowed only when your policy specifically authorizes them and they meet the security requirements you defined for external systems. The requirement prohibits external system use unless it is specifically authorized, so a blanket permission for personal devices does not satisfy it. Before authorization, verify that the device meets your settings, and confirm that CUI cannot be copied to organization-controlled portable storage on it. Many organizations decide that personal devices may reach only a restricted set of services and never store CUI. Confirm your agency's expectations on this point, since the answer shapes both the policy and the technical controls.

What does a readiness review for 03.01.20 cover?

A readiness review checks whether the evidence an assessor would examine, interview about and test for 03.01.20 already exists and is current. In practice, that means reviewing the access control policy and procedures, the procedures for using external systems, the terms and conditions for their use, the list of authorized external systems, the signed connection or processing agreements, and the mechanisms that enforce the security requirements and the portable storage restriction. The review should also identify gaps, such as an external service with no agreement or a storage restriction that is documented but not enforced. Ask the reviewer to state the method and scope in writing, and confirm with your assessor which artifacts they expect.

Does DeployOpen issue the assessment result for 03.01.20?

No. DeployOpen plans, implements and documents the systems, controls and evidence that support 03.01.20, but it does not issue audit reports, attestations or certifications. Only an independent assessor or certification body, selected by you and recognized by the relevant program, can issue the result. DeployOpen's work is delivered under a fixed scope with agreed deliverables, so you can see exactly which evidence is prepared and which decisions remain yours. Before engaging anyone, ask your contracting agency which assessment methods and assessor types it accepts, because those requirements determine who can deliver the final determination.

What must our team supply before an implementation partner can start?

The partner needs access to people, documents and systems that only your organization can provide. Expect to supply a list of the external systems staff currently use, the agreements or terms of service that govern them, the current access control policy and procedures, and the names of the people who approve external system use. Technical access matters too: the partner will need read access to the relevant configurations, identity and logging settings, and endpoint management tools, plus a named contact who can decide on scope questions. Ask for a written list of required inputs in the scope document, and confirm the access model and data handling rules before any system is connected.

How DeployOpen scopes and prepares 03.01.20 evidence

DeployOpen works on 03.01.20 by preparing the systems, rules and records that show when external systems may reach the organizational system or handle CUI. The organization owns the policy and the decision to authorize each external system, and an independent assessor reaches the conclusion on compliance.

How we scope

Inventory every external system that could reach the organizational system or handle CUI, including personal and partner devices.
Confirm the organization-defined security requirements for external systems, since 03.01.20 requires them to be set before any use is allowed.
Agree deliverables, boundaries and timelines in writing; engagements are fixed-scope, and ongoing support is available as a retainer.

How we build

Configure access controls and boundary rules so that only approved external systems can connect, using the organization's chosen platforms.
Set up logging of external system connections so the organization can show that requirements were verified before access.
Test the enforcement mechanisms that block unapproved use, including portable storage restrictions on external systems, and record the results.

How we hand over

Document the external system policy, procedures and terms of use in a form an assessor can examine and trace to 03.01.20.
Keep a register of approved connection and processing agreements with the date each was reviewed and the owner who approved it.
Confirm with the organization's assessor which artifacts they expect before handover, since the assessor alone decides what evidence is sufficient.

How we support

Review new external system requests against the documented requirements and update the approved list as services change.
Retest enforcement mechanisms and refresh evidence when platforms are upgraded or when external services are added.
Provide ongoing support, upgrades and continuous testing through a retainer if the organization wants them after the initial work.

03.01.20 Use of external systems