PM-17: Protecting Controlled Unclassified Information on External Systems

PM-17 requires you to set and run a policy-and-procedure program that ensures Controlled Unclassified Information (CUI) remains protected when it is processed, stored, or transmitted on any external system, in line with applicable legal and policy requirements ¹. Operationally, that means you must identify where CUI leaves your boundary, impose contractual and technical controls on those external environments, and retain proof that those controls operate.

Key takeaways:

• Treat “external systems” as a governed CUI ecosystem: inventory, approved pathways, and enforceable requirements.
• Build a repeatable intake and authorization workflow before any third party can touch CUI.
• Evidence wins audits: keep contracts, system boundaries, data flow maps, and control attestations tied to each CUI use case.

The pm-17: protecting controlled unclassified information on external systems requirement is a program management control. That matters because most CUI exposures happen at boundaries: a managed service provider working tickets, a SaaS collaboration platform, outside counsel reviewing files, a subcontractor receiving drawings, or a cloud environment operated by another entity. PM-17 forces you to stop treating those as “someone else’s problem” and instead define the rules, the approval path, and the proof that external handling meets the protection requirements that apply to your CUI.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing PM-17 is to translate it into three execution objects: (1) a written policy that defines when external systems may handle CUI and under what conditions, (2) procedures that implement those conditions consistently (intake, due diligence, contracting, onboarding, monitoring, offboarding), and (3) an evidence model that ties each external CUI pathway to artifacts an assessor can verify. PM-17 does not replace technical controls (encryption, access control, logging). It makes sure the organization reliably applies the right controls wherever CUI goes.

Regulatory text

Excerpt (framework requirement): “Establish policy and procedures to ensure that requirements for the protection of controlled unclassified information that is processed, stored or transmitted on external systems, are implemented in accordance with applicable laws, executive orders, directives, policies, regulations, and standards; and” ¹.

What an operator must do with this text:

• Write down the rules for CUI on external systems (policy).
• Make the rules executable through defined workflows and assigned responsibilities (procedures).
• Prove alignment with the applicable requirements that govern your CUI context (for many organizations this includes contractual requirements and federal program requirements; PM-17 explicitly expects alignment to “laws, executive orders, directives, policies, regulations, and standards”) ¹.
• Apply it to “external systems” broadly, including third-party-owned systems and systems outside your direct administrative control where CUI is processed, stored, or transmitted ¹.

Plain-English interpretation (what PM-17 is really asking)

If CUI touches a system you don’t fully control, you must have a governed way to decide:

1. whether that external system is allowed to handle CUI,
2. what security and handling requirements it must meet,
3. how you confirm it meets them before CUI is shared,
4. how you keep confirming it over time,
5. how you revoke access and recover/retain data at end of use.

PM-17 is less about choosing “the right tool” and more about preventing ad hoc CUI sharing through unmanaged channels.

Who it applies to

PM-17 applies in practice to:

• Federal information systems and the organizations operating them ¹.
• Contractor systems handling federal data, including organizations receiving, generating, processing, storing, or transmitting CUI as part of a federal contract or downstream relationship ¹.

Operational contexts where PM-17 typically becomes exam-relevant:

• Third parties supporting operations (IT managed services, SOC, help desk, payroll, HR platforms, eDiscovery providers).
• Cloud/SaaS platforms used for collaboration, ticketing, source code, design files, and document storage.
• Subcontractors and suppliers receiving CUI as inputs (drawings, specs, reports).
• External email, file transfer, and mobile/BYOD scenarios if those systems are not owned/managed by you.

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

1) Define what counts as CUI for your organization

• Document CUI categories you handle and the typical business processes that touch it.
• Establish labeling/marking expectations and minimum handling rules tied to those categories. Output: CUI data handling standard (or CUI annex) referenced by PM-17 policy.

2) Identify “external systems” and map CUI pathways

• Build an inventory of all third parties and platforms that can touch CUI.
• Create simple data flow diagrams: CUI source → transfer method → external system → users → storage/retention → return/destruction. Practical tip: Start with procurement/AP + SSO logs + top shared storage tools. You’ll find “shadow” pathways quickly. Output: External CUI system register + data flow maps per use case.

3) Establish a PM-17 policy with enforceable guardrails

Your policy should answer, in unambiguous language:

• When CUI may be processed/stored/transmitted externally.
• Who can approve new external CUI pathways (named roles, not departments).
• Minimum security conditions (e.g., access control, encryption expectations, incident reporting, subcontractor flow-down).
• Prohibited channels (personal email, consumer file sharing, unmanaged devices) unless formally authorized.
• Evidence requirements (what must be collected before onboarding and during monitoring). Output: “Protecting CUI on External Systems Policy” mapped to PM-17 ¹.

4) Implement a repeatable procedure: intake → due diligence → contract → onboard

Create an operational workflow that a non-GRC requestor can follow:

A. Intake (request stage)

• Requestor submits: purpose, CUI type, volume, users, geography, transfer methods, duration.
• GRC routes to InfoSec + Legal + Procurement for review.

B. Due diligence (risk stage)

• Validate the external system’s security posture against your CUI handling requirements.
• Confirm capability for access control, audit logging, secure transfer, and incident notification expectations that match your obligations.
• Record gaps and compensating controls, or reject the use case.

C. Contracting (commitment stage)

• Add CUI handling clauses to the master agreement and SOW, including:
  • Permitted uses, confidentiality, access restrictions.
  • Flow-down requirements to subcontractors.
  • Breach/incident notification and cooperation.
  • Data location/return/destruction terms.
• Tie contract language to the exact CUI pathway and system(s) approved.

D. Onboarding (enablement stage)

• Enforce SSO/MFA where applicable.
• Provision least-privilege roles and named user access.
• Configure approved sharing settings (disable public links, restrict external sharing).
• Train internal users on the “approved way” to share CUI with this third party. Output: Completed third-party onboarding checklist + system configuration records.

5) Monitor and reauthorize external CUI handling

PM-17 is a program requirement. You need ongoing operation:

• Track external systems approved for CUI and the control owner accountable for each.
• Monitor for scope creep (new projects, new regions, new subcontractors, new features enabled).
• Require periodic re-attestation or re-assessment triggered by change events (contract renewal, major incident, platform migration). Output: Reauthorization log + change tickets + periodic control attestations.

6) Offboard cleanly

• Remove access, revoke tokens/keys as applicable, and disable integrations.
• Confirm data return/destruction per contract.
• Retain the evidence package for audit and investigations. Output: Offboarding record + data disposition confirmation.

7) Assign ownership and an evidence cadence (make it auditable)

PM-17 regularly fails in audits because nobody “owns” it and evidence is scattered. Make the control real:

• Name a control owner (often GRC + Information Security + Procurement as defined roles).
• Define what evidence is produced per onboarding and per monitoring event.
• Store it centrally with a consistent naming scheme tied to the external system and CUI use case.

Daydream fits naturally here as the system of record for mapping PM-17 to a control owner, documenting the procedure, and generating a recurring evidence request list so audits don’t turn into inbox archaeology ¹.

Required evidence and artifacts to retain

Use this as your PM-17 evidence checklist:

Evidence artifact	What it proves	Where it usually lives
PM-17 policy and procedure	The organization established governance for CUI on external systems	GRC repository
External CUI system register	You know which external systems handle CUI	GRC/TPRM tool
CUI data flow diagrams per use case	You understand processing/storage/transmission points	Architecture/GRC
Third-party due diligence package	You evaluated controls before sharing CUI	TPRM records
Executed contracts/SOWs with CUI terms	Requirements are enforceable	Legal/CLM
Onboarding checklist + access approvals	Least privilege and configuration controls were applied	ITSM/IAM
Monitoring/reauthorization logs	Ongoing operation of the program	GRC/TPRM
Offboarding and data disposition confirmations	Access removed and data handled at end of engagement	ITSM/Legal

Common exam/audit questions and hangups

Expect assessors to press on these points:

• “Show me every external system that stores or transmits CUI.” If your inventory is incomplete, PM-17 will look non-operational.
• “How do you prevent users from using unapproved tools?” Policy alone is weak; show technical restrictions and procurement controls where possible.
• “Where are the contracts that bind the third party to CUI requirements?” Missing flow-down language is a common finding.
• “What triggers a re-review?” If you only reassess on a calendar, you may miss change-driven risk.
• “Prove this is done consistently.” One well-documented third party is not a program.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating PM-17 as a one-page policy.
   Fix: pair policy with an intake workflow, due diligence checklist, contract addendum templates, and an evidence folder structure.

2. Mistake: assuming cloud/SaaS is “internal” because you pay for it.
   Fix: classify any non-owned/non-administered environment as external for PM-17 purposes unless you can demonstrate full control.

3. Mistake: focusing only on storage, ignoring transmission and processing.
   Fix: map the whole pathway. Ticketing systems, chat exports, and support screen shares often process CUI.

4. Mistake: no linkage between CUI use case and contractual terms.
   Fix: tie the approved use case to the SOW and require an amendment when scope changes.

5. Mistake: evidence scattered across email and shared drives.
   Fix: create a single “PM-17 evidence pack” per external system in Daydream (or your GRC system) and require artifacts before go-live.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat PM-17 as an assessment and contractual compliance risk rather than a case-law-driven requirement. The practical risk is predictable: unmanaged external handling increases the chance of unauthorized disclosure, breach notification obligations, contract noncompliance, and loss of eligibility for work that requires disciplined CUI handling ¹.

Practical 30/60/90-day execution plan

Use phases instead of date math. Progress is driven by scope clarity, stakeholder alignment, and evidence readiness.

First 30 days (Immediate)

• Appoint the PM-17 control owner and backups.
• Draft/update PM-17 policy and procedure with clear approval authority ¹.
• Build the initial external CUI system register from procurement + IT + business leads.
• Select one high-risk/high-volume external CUI pathway and create the first complete evidence pack end-to-end.

Days 31–60 (Near-term)

• Roll out the intake workflow (ITSM form or GRC workflow) and require it for new external CUI sharing.
• Standardize contract language: CUI addendum + SOW clauses + subcontractor flow-down requirements.
• Require data flow diagrams for each approved external CUI use case.
• Implement monitoring triggers (contract renewals, scope changes, new integrations, incidents).

Days 61–90 (Operationalize and harden)

• Expand coverage to remaining external systems in priority order (highest CUI sensitivity and widest access first).
• Run a tabletop review: pick an external system, trace CUI handling from request to offboarding, and identify evidence gaps.
• Train procurement, IT, and program managers on the “no intake, no CUI” rule.
• Produce a PM-17 assessor packet: policy, register, sample due diligence package, sample contract, sample onboarding and monitoring proof.

Frequently Asked Questions

Does PM-17 mean CUI can never be placed on third-party cloud or SaaS systems?

No. PM-17 expects you to govern and evidence how CUI is protected on external systems in line with applicable requirements ¹. The practical requirement is documented approval, enforceable obligations, and proof of implemented controls.

What counts as an “external system” for PM-17?

Treat any system outside your direct administrative control as external for PM-17 purposes, including third-party platforms and third-party-operated infrastructure, when CUI is processed, stored, or transmitted ¹. Document your boundary assumption in the procedure so it is applied consistently.

What’s the minimum evidence auditors will expect?

Expect to show a PM-17 policy/procedure, an inventory of external systems handling CUI, and artifacts for at least one complete lifecycle (due diligence, contract terms, onboarding configuration, monitoring, and offboarding) ¹.

How do we handle subcontractors that our prime third party brings in?

Your procedure should require subcontractor disclosure and flow-down of CUI protection terms through contract requirements. Keep evidence that subcontractors were approved or that the prime is contractually obligated to impose equivalent protections aligned to your requirements ¹.

We already have a third-party risk program. What’s different for PM-17?

PM-17 is CUI-specific and boundary-specific: it focuses on external processing/storage/transmission of CUI and demands policy, procedures, and evidence tied to those specific data flows ¹. Many generic TPRM programs fail here because they don’t map assessments and contracts to concrete CUI use cases.

Can we satisfy PM-17 with a security questionnaire alone?

A questionnaire helps, but PM-17 expects implemented requirements and proof, not just collected answers ¹. Pair due diligence with contract obligations, technical onboarding steps, and monitoring records.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON