03.01.20: Use of External Systems

03.01.20: use of external systems requirement means you must control how your workforce and third parties access, store, process, or transmit CUI on systems you do not own or directly manage. Operationalize it by defining “external systems,” approving allowed services, enforcing technical guardrails, and retaining evidence that CUI stays within authorized, protected environments ¹.

Key takeaways:

• Define and inventory “external systems” in your CUI workflows, including SaaS, personal devices, and partner portals ¹.
• Implement an allowlist + approval workflow tied to CUI data handling rules, then enforce it with identity, endpoint, and DLP controls ¹.
• Keep assessment-ready evidence: decisions, configurations, contracts, and recurring reviews that show the control operates in practice ¹.

External systems are where CUI control breaks down fastest: personal phones, “free” file-sharing accounts, ad hoc collaboration with subcontractors, and unmanaged SaaS used by business teams. 03.01.20: use of external systems requirement forces a simple discipline: if CUI touches a system outside your direct administrative control, you must explicitly authorize that use and apply protections equivalent to your internal CUI environment ¹.

For a CCO, GRC lead, or security compliance owner, the hard part is not the policy statement. It is turning policy into enforceable guardrails without freezing the business. The fastest path is to (1) define external systems in your environment, (2) decide which are allowed for CUI and under what conditions, (3) implement technical enforcement aligned to those conditions, and (4) build a repeatable evidence pack that proves the control operates continuously, not once ¹.

This page is written to help you operationalize 03.01.20 quickly: concrete scoping, decision points, step-by-step implementation, and the artifacts auditors ask for.

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.01.20 (Use of External Systems).” ¹

Operator interpretation: You must govern any system outside your direct control that is used to access, store, process, or transmit CUI. “Govern” means you set rules for what is allowed, require approvals for exceptions, ensure security conditions are met, and can show evidence that people follow those rules ¹.

What the operator must do: Establish a controlled approach for external systems so CUI does not end up on unmanaged endpoints or unapproved third-party platforms. Document the rules, enforce them technically where feasible, and keep proof for assessments ¹.

Plain-English interpretation (what 03.01.20 is really asking)

If you do not own it, fully manage it, or control its security configuration, treat it as an external system. If CUI goes there, it must be explicitly permitted and protected. If you cannot enforce protections, CUI cannot go there ¹.

Examples of “external systems” in practice:

• Personal devices used for work (BYOD) accessing email or files that may contain CUI.
• Non-corporate cloud storage or collaboration accounts.
• Third-party ticketing/CRM/project tools where staff paste CUI.
• Partner portals and subcontractor systems used for shared execution of a contract.
• Contractor-managed laptops that are not under your endpoint management ¹.

Who it applies to

Entities

• Federal contractors and subcontractors that handle CUI in nonfederal systems ¹.
• Any organization segment (subsidiary, program, division) that processes CUI, even if only a small group touches it ¹.

Operational context (where it shows up)

• Remote work and travel.
• Collaboration with third parties (subcontractors, consultants, joint teams).
• SaaS-heavy environments with business-managed apps.
• Incident response and customer support workflows where screenshots/logs may include CUI ¹.

What you actually need to do (step-by-step)

1) Define “external system” for your program boundary

Create a short, auditable definition you can apply consistently:

• Internal/managed: corporate endpoints, corporate tenant(s), systems with your admin control.
• External/unmanaged: anything else, including third-party platforms and personally owned endpoints unless enrolled in your management stack ¹.

Deliverable: a definition in your CUI handling policy and SSP/Program Plan mapping.

2) Map where CUI touches tools and endpoints

Build a CUI workflow map. Focus on real routes CUI takes:

• Create/receive CUI (email, portal download, shared drive).
• Store CUI (file shares, document management, case systems).
• Process CUI (engineering tools, analytics platforms).
• Transmit CUI (sharing, messaging, SFTP, support tickets) ¹.

Technique that works: run short interviews with contract owners plus IT, then validate with logs (CASB/SaaS audit logs, IdP app catalog, endpoint inventory) where available.

Deliverable: a “CUI system-of-record list” and a “CUI external touchpoints list.”

3) Establish an allowlist for external systems approved for CUI

Create an approval matrix for external systems. Keep it simple and enforceable:

External system type	Default stance for CUI	Approval authority	Minimum conditions
SaaS collaboration	Allowed only if approved	Security + data owner	SSO, MFA, logging, sharing restrictions
Personal device	Restricted by default	Security	MDM enrollment, encryption, remote wipe
Subcontractor environment	Allowed only with agreement	Contracts + Security	Written requirements, access controls, auditability
Consumer file sharing	Prohibited	N/A	N/A

The specific “minimum conditions” must match your control environment and risk decisions, but they must be written and testable ¹.

Deliverable: an “Approved External Systems for CUI” register with owners and configuration baselines.

4) Implement technical guardrails to make the policy real

Pick controls that block the most common failure modes:

• Identity controls: Require SSO and MFA for approved SaaS. Disable direct login where possible. Enforce conditional access for high-risk sign-ins ¹.
• Endpoint controls: Require managed devices for CUI access. If BYOD is permitted, require MDM and device encryption, and separate work data where possible ¹.
• Data controls: DLP policies for sharing outside approved domains, blocking uploads to unsanctioned cloud storage, and preventing CUI from entering unapproved collaboration spaces ¹.
• Network/application controls: Restrict access to CUI repositories from unmanaged devices and from unapproved geographies if that fits your risk posture ¹.
• Logging: Centralize audit logs for CUI-relevant systems, and ensure you can answer “who accessed what, from where” for external systems ¹.

Deliverable: configuration screenshots/exports and change tickets for each guardrail.

5) Contract and third-party due diligence for external systems that handle CUI

When a third party’s platform is an external system for your CUI, treat it as a third-party risk decision:

• Document the CUI use case and data types.
• Obtain security documentation relevant to your decision (security whitepaper, shared responsibility statement, audit reports if available).
• Add contract terms that align to your CUI handling requirements: data use limits, breach notification, subcontractor controls, secure disposal, and access restrictions ¹.

Deliverable: third-party risk assessment packet + executed contract addendum + system approval record.

6) Set an exception process (because someone will ask)

You need a fast exception workflow for business reality:

• Request form: system, business justification, CUI type, duration, compensating controls.
• Review: Security + data owner + Contracts (if third party involved).
• Decision: approve with conditions, or deny with an approved alternative.
• Expiration and revalidation: exceptions must end or be renewed based on evidence ¹.

Deliverable: exception log with approvals and expirations, plus evidence that exceptions are reviewed.

7) Operate and prove it continuously

Assessors will look for “operating effectiveness,” not just design:

• Periodic review of approved external systems and their configs.
• Monitoring for unsanctioned apps (shadow IT) through IdP logs, CASB, or finance/SaaS spend reviews.
• Spot checks: verify CUI is not present in prohibited tools (within legal/HR boundaries) ¹.

Deliverable: recurring review minutes, findings, remediation tickets, and closure evidence.

Required evidence and artifacts to retain

Keep an evidence pack tied directly to 03.01.20: use of external systems requirement:

1. Policies and standards

   • CUI handling policy with external systems rules ¹.
   • BYOD/remote work standard (if applicable) ¹.

2. Inventories and registers

   • Approved external systems list for CUI (system, owner, purpose, conditions) ¹.
   • Exception register and approvals ¹.

3. Technical configurations

   • SSO/MFA enforcement evidence (IdP policies, screenshots, exports) ¹.
   • DLP policies and block logs for unapproved services ¹.
   • MDM enrollment reports and device compliance policies ¹.

4. Third-party due diligence

   • Risk assessment notes and decision rationale for each third party external system that handles CUI ¹.
   • Contract clauses or addenda addressing CUI handling ¹.

5. Operational proof

   • Training/acknowledgments focused on “where CUI may and may not go” ¹.
   • Periodic access reviews and monitoring results ¹.

Practical note: Daydream is helpful here because it can map 03.01.20 to your policy, your implemented controls, and a recurring evidence collection plan so you do not rebuild the packet for every assessment ¹.

Common exam/audit questions and hangups

Assessors tend to press on these points ¹:

• “Define external system. What is in scope for this requirement?”
• “Show me the approved list. Who approves, and how do you enforce it?”
• “How do you prevent CUI from being stored in personal cloud accounts?”
• “Do subcontractors access your CUI? If yes, where does it live and what controls exist there?”
• “Show evidence that the control operates: logs, exceptions, and periodic review outputs.”

Hangup: teams can describe intent but cannot show enforcement artifacts (IdP policies, DLP blocks, MDM compliance, or a living approval register).

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance. Fix: pair every rule with an enforcement control (SSO/MFA, conditional access, DLP, MDM) and keep the config evidence ¹.
2. No agreed definition of “external.” Fix: write a boundary definition and apply it consistently in your system inventory and SSP mapping ¹.
3. Shadow IT ignored. Fix: implement an app discovery channel (IdP logs, CASB, procurement) and a rapid “approve or block” decision path ¹.
4. Third-party contracts lag reality. Fix: require a contract checkpoint before CUI goes into any third-party platform; if the business needs speed, pre-negotiate standard CUI clauses for common providers ¹.
5. Exceptions never expire. Fix: set expirations and revalidation triggers; treat exceptions as temporary risk acceptance with named owners ¹.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. From a risk perspective, weak control of external systems is a common root cause for CUI exposure because data leaves managed boundaries and enters environments where you cannot prove access control, retention, or secure deletion ¹.

Translate that into program risk statements a CCO can use:

• Unauthorized external systems can create contractual noncompliance risk if CUI handling terms require controlled environments ¹.
• External systems expand incident scope and complicate forensics because logs and administrative control may sit with a third party ¹.

Practical execution plan (30/60/90)

Your goal is fast control plus credible evidence.

First 30 days (stabilize)

• Publish the definition of “external system” and the default stance for CUI (allowed vs prohibited categories) ¹.
• Stand up an interim approval workflow and a simple approved-systems register (spreadsheet is acceptable if controlled) ¹.
• Identify the top external systems already touching CUI and decide: approve with conditions, migrate, or stop ¹.

Days 31–60 (enforce)

• Implement SSO/MFA and conditional access for approved SaaS used with CUI ¹.
• Put baseline DLP controls in place for obvious exfil paths (personal cloud storage, external sharing) ¹.
• Require managed endpoints (or MDM enrollment) for CUI access paths ¹.
• Add required contract language or documented risk acceptance for any third-party external system handling CUI ¹.

Days 61–90 (prove and harden)

• Run a first operational review: approved list accuracy, exceptions status, and evidence completeness ¹.
• Test the control: attempt CUI sharing to a prohibited destination and confirm the block and alerting work ¹.
• Package your evidence for assessment: policy, registers, configs, logs, and review outputs mapped to 03.01.20 ¹.
• If you use Daydream, automate the mapping and recurring evidence pulls so reviews become routine instead of a scramble ¹.

Frequently Asked Questions

Does “external systems” include employee personal devices if they only check email?

Yes, if CUI can be accessed or stored through that device, it is an external system unless you manage it to your required standard. Decide whether BYOD is permitted for CUI and enforce the decision with MDM and conditional access ¹.

Can we allow CUI in a third-party SaaS tool if it has SSO and MFA?

Possibly, but approval should also cover logging, sharing controls, retention, and contractual terms for CUI handling. Document the decision, required configurations, and who owns ongoing monitoring ¹.

How do we handle subcontractors who need access to CUI?

Treat the subcontractor environment as an external system. Require written conditions for access and handling, align contract terms, and keep evidence of access control and monitoring for the shared workflow ¹.

What evidence is most persuasive to assessors for 03.01.20?

A current approved external systems register, enforced identity policies (SSO/MFA), DLP/conditional access configurations, and an exception log with approvals and expirations. Add periodic review outputs that show the control keeps working ¹.

We already have a SaaS security review process. Is that enough?

Only if it explicitly covers CUI use cases and results in an allowlist decision plus enforceable technical conditions. Many SaaS reviews stop at questionnaires and do not produce configurations or ongoing evidence ¹.

What should we do if we discover CUI in an unapproved external system?

Treat it as a containment and governance issue: stop the data flow, remove or migrate the CUI to an approved system, document the incident and corrective actions, and update guardrails to prevent recurrence. Record the exception or remediation so you can show control improvement ¹.

Footnotes

1. NIST SP 800-171 Rev. 3