PM-17 CUI on external systems: requirements and evidence

What PM-17 asks for and why the policy alone is not enough

If a contract, agency or assessor asks how controlled unclassified information leaves your boundary, the short answer is that PM-17 is a policy and procedures control. It requires an organization to have documented policy and procedures ensuring that the requirements for protecting CUI processed, stored or transmitted on external systems are implemented as laws, regulations and policies require, and to review and update that policy and those procedures at a defined frequency. The control does not, by itself, pick a cloud provider, set an encryption standard or approve a file transfer service. Those decisions belong to the controls that sit under the policy. NIST points to 32 CFR Part 2002, where the CUI safeguarding requirements are codified, as the source of the obligations the policy must reflect. Confirm the current text of that regulation with your contracting officer or compliance lead rather than relying on a summary.

PM-17 is a program management control. SP 800-53B places it among the organization-wide controls that support the information security program, deployed once for the whole organization rather than allocated to each system. It is not part of the low, moderate or high baselines, but it is included in the privacy baseline, which applies regardless of system impact level. The control's related controls in the Release 5.2.0 catalog are CA-6 and PM-10, which is a useful pointer: authorization decisions and security assessments are where an external system's handling of CUI is actually tested. SP 800-53A assesses PM-17 through four determination statements using the examine and interview methods, looking at the CUI policy and procedures and at the personnel who carry CUI responsibilities.

Assessors find gaps when the policy describes obligations that never reach the external systems people actually use. A typical finding is a CUI policy that names external storage and transmission, paired with no procedure that tells a system owner how to confirm a cloud service or file-sharing tool meets the policy before CUI is loaded. Before the next assessment, ask the policy owner to show how an external system is approved for CUI, who signs off, where that decision is recorded and when it was last reviewed. Your policy and procedures should be traceable to the controls that enforce them. The policy alone will not show that the organization follows it.

Which external systems, CUI flows and teams fall under PM-17

PM-17 is an organization-wide policy control, so its scope is set by where CUI goes, not by a single system boundary. The cards below cover the scoping decisions that determine which external services, contracts, teams and baseline assumptions the PM-17 policy and procedures must reach.

External services that touch CUI

Any external system that processes, stores or transmits CUI sits inside PM-17's policy scope, including SaaS collaboration tools, email gateways, managed backups and hosted ticketing. Build the list from data flows rather than from the procurement catalog, because shadow services often carry CUI without appearing in any approved inventory. For each service, record what CUI type it receives and whether the organization or the provider controls the encryption keys. Confirm the list with system owners before drafting the procedures.

CUI flows across organizational boundaries

Map every path CUI takes out of the organization, including file transfers to subcontractors, API integrations, replication to offsite sites and support access by vendor staff. Each hop is a point where the requirements for protecting CUI on external systems must still hold. Document the flow, the transfer mechanism and the party at each end. Flows that exist only in engineering runbooks are the ones most often missed in a PM-17 review.

Contracts and agreements that bind providers

Contract owners decide whether external providers accept the safeguarding obligations that CUI requires, and PM-17 policy must reflect the terms actually signed. Review each agreement for CUI handling clauses, incident notification duties, subcontractor flow-down and data return or destruction at exit. A provider without these terms is a scoping gap, even if its technical controls are strong. Ask procurement to flag every new external service that will receive CUI before it is approved.

Teams that own approvals and exceptions

Responsibility for PM-17 is split across security, legal, procurement, privacy and the business units that use external services. Name a single accountable owner for the policy and assign approvers for new external CUI use, exception requests and periodic review. Without a named approver, teams adopt external tools informally and the policy cannot show that requirements were implemented. Record these roles in the policy itself so an assessor can trace each interview statement to a person.

Privacy baseline status changes applicability

PM-17 is not allocated to the low, moderate or high baseline, but SP 800-53B includes it in the privacy baseline, which applies regardless of system impact level. If a system falls in the privacy baseline, PM-17 applies to its external CUI handling even when the impact level is low. Confirm with the privacy office whether any system processing PII is in scope before deciding that PM-17 covers only the security baselines. Record the decision and the reasoning in the scope statement.

Related controls that set the scope boundary

PM-17 is linked to CA-6 (authorization) and PM-10 (authorization process), so decisions about who may authorize external CUI use affect how far PM-17 reaches. Check whether an external system is covered by an existing authorization decision and whether that decision names CUI as a data type. A system authorized without considering CUI should be flagged for review under PM-17 rather than assumed compliant. Use these related controls as the cross-check for the scope list.

How an assessor tests PM-17 under SP 800-53A

This table maps the parts of the SP 800-53A assessment for PM-17 to what the assessor does, what they look at and where organizations usually fall short. Read it as a preparation checklist: each row names a piece of the assessment and the material to have ready before the assessor arrives.

Assessment element	What the assessor does	What to have ready
Determination statements (4)	Checks each of the four PM-17 statements separately, so a policy that covers only part of them fails the control	A mapping from each statement to the policy or procedure section that addresses it
Examine method (policy)	Reads the CUI policy and confirms it covers requirements for CUI on external systems, as laws, regulations and policies require	A current CUI policy that names external systems, cloud services and third-party hosting explicitly
Examine method (procedures)	Reviews the CUI procedures and checks that they describe how the policy is put into practice	Step-by-step procedures with owners, approval points and links to the systems they govern
Interview method	Asks personnel with CUI responsibilities to explain their duties and how external systems are used for CUI	Role descriptions and training records so staff can name their responsibilities consistently
Review frequency	Checks that the policy and procedures were reviewed and updated at the frequency the organization defined	Document version history, review dates and recorded approvals, kept under version control
Common finding: stale policy	Flags policy that has not been reviewed within the defined frequency or still describes retired external systems	A review calendar with named owners and evidence of the last completed review
Common finding: interviews fail	Records a gap when staff cannot name their CUI duties or the rules for external systems	Short awareness material and a sign-off record showing each role received the relevant guidance
Common finding: unclear scope	Notes when no inventory links CUI to the external systems that process, store or transmit it	A current list of external systems that handle CUI, kept alongside the policy

Implementing PM-17 step by step

This sequence turns the PM-17 requirement into a CUI policy and set of procedures for external systems that has named owners, a review cycle and trained staff, with each step leaving a record an assessor can examine. It follows the order in which an organization would normally work through the control.

Confirm the applicable CUI requirements
The compliance lead lists the laws, regulations, contract clauses and agency policies that govern CUI in your environment, starting with the CUI program requirements codified in 32 CFR 2002 as the PM-17 discussion points to them. Legal, contracting and the information security office confirm which external systems, such as cloud services, managed providers and partner platforms, process, store or transmit CUI. The output is a signed requirements register that names each requirement and the external systems it applies to.
Draft or update the external systems CUI policy
The policy owner writes or revises the CUI policy so it states how CUI may be placed on external systems, which safeguards must be in place before that happens, and who may approve exceptions. The draft should map each requirement from the register to a policy statement, so an assessor can trace the policy back to its source. The output is a draft policy with a requirement-to-statement traceability table.
Write the procedures for external systems
Operational teams write procedures that show how the policy is carried out for each external system: onboarding checks, configuration of protections, handling of CUI when a service ends, and escalation when a provider cannot meet a requirement. Procedures should name the system owner for each step and the record created at each step. The output is a set of procedures that a new staff member could follow without asking the author.
Assign owners and accountable roles
Leadership names one accountable owner for the policy, owners for each procedure and a contact for each external system that handles CUI. The assignments should be written into the policy or a role register and accepted by the people named. The output is a signed role register that shows who answers an assessor's interview questions about CUI on external systems.
Set the review frequency and approve the policy
The policy owner records the review frequency and the triggers for an off-cycle review, such as a change to the CUI requirements or a new external provider. Senior management then reviews and approves the policy and procedures, and the approval is dated and recorded. The organization must confirm its own review frequency because PM-17 requires a defined interval and the NIST text leaves it to the organization. The output is an approved policy with a stated review interval and approval record.
Publish the policy and train responsible staff
The policy and procedures are published to the people who handle CUI or manage external systems, and those staff complete training on their responsibilities. Training records should show who was trained, on which version, and when. The output is a published, version-controlled document set and a training record that matches the role register.
Record each review cycle
At each scheduled review, the owner checks the policy against current CUI requirements, changes to external systems and any findings from earlier reviews, then records what changed and why. Open items go into the plan of action and milestones process where they are tracked to closure. The output is a dated review record and an updated policy version that an assessor can compare with earlier versions.

Evidence that passes a PM-17 assessment

A PM-17 assessor checks whether a documented CUI policy and external-systems procedure exist, whether they are reviewed on schedule, and whether the people responsible know them. The cards below cover the records that prove each of those points and how to keep them current between assessments without padding the file.

Approved CUI policy for external systems

This is the organization-level policy stating how CUI processed, stored or transmitted on external systems must be protected, aligned with the laws, regulations and contract terms that apply to your organization. The assessor will look for a named owner, an approval by an accountable official, and a clear link to the requirements in 32 CFR 2002. Check that the policy names the external systems in scope, such as cloud services and third-party platforms, and that its wording matches what engineers actually do.

Procedures for external system use

Procedures turn the policy into steps: how a new external system is evaluated for CUI handling, who approves its use, how CUI is labeled and moved, and how exceptions are recorded. Write them so a practitioner can follow them without the author present. Keep one procedure per workflow rather than one long document, and link each to the policy section it implements so the traceability is visible at a glance.

Review and update records

PM-17 requires the policy and procedures to be reviewed and updated at a defined frequency, so the assessor will ask for proof that the review happened on time. Keep a short review log that records the date, the reviewer, what changed and the decision to approve or revise. If nothing changed, record the review anyway with a note confirming the content was checked. This is the record most often missing at assessment time.

Version history and approval trail

A wiki or document system with version control lets you show what each revision changed, who made it and when, and which version was in force during a given period. Confirm that your platform keeps this history and that approvals are captured in the record rather than in email. Export or retain the history at each review cycle so you can demonstrate the policy in effect on any past date without reconstructing it from memory.

Role descriptions and interview readiness

The assessor will interview personnel with CUI responsibilities, so each role named in the policy needs a current description covering its CUI duties, decision rights and escalation path. Confirm that the people who hold these roles can explain the external-system rules in their own words. Store role descriptions with the policy so they are reviewed together, and update them when staff change.

Training and access permissions records

Training records show that personnel with CUI responsibilities were briefed on the policy and procedures, with dates and the content covered. Pair them with the access permissions that govern who can edit the policy and who can read CUI-related procedures. In a self-hosted knowledge base, check that role-based permissions are assigned as intended and that changes to them are logged, so the record shows both the training and the controls over who can change the rules.

What meeting PM-17 costs in money and effort

This table breaks down the cost components of meeting PM-17, who is paid for each, whether the cost is one-time or recurring, and what drives it up or down. NIST does not estimate compliance costs, so no figures appear here; use the rows to build a scope and ask vendors and advisors for written quotes against each line.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives the cost
CUI policy drafting	Internal compliance lead, or an outside consultant if engaged	One-time, then revised	Number of CUI categories handled, existing policy maturity, and how many external systems the policy must cover
Procedure development	Engineering and compliance staff who define how CUI is protected on external systems	One-time, then revised	Number of external system types (cloud, SaaS, managed services) and the number of distinct handling workflows
Legal and contract review	Counsel or contracts team reviewing the policy against applicable laws, regulations and customer agreements	One-time per policy version	Number of governing contracts and whether 32 CFR Part 2002 requirements are reflected in your agreements
Periodic policy and procedure review	Policy owner and reviewers at the frequency the organization defines for PM-17	Recurring	Frequency set in your own policy, changes in contracts or regulations, and the number of approvers required
External review of the policy	Outside reviewer or consultant, when the organization chooses to use one	Optional, one-time or recurring	Scope of the review, whether it covers procedures as well as policy, and the reviewer's rate basis
Assessor time for PM-17	Independent assessor examining the policy and interviewing CUI responsibility holders	Per assessment cycle	Assessment scope, number of interviews, and how well evidence is organized before the assessor arrives
Evidence preparation and version history	Platform or documentation team maintaining approvals, revision history and access records	Recurring	Whether documents are kept under version control and whether approval records are retrievable on request

Keeping PM-17 policy current with version history and roles

The PM-17 policy and procedures for protecting CUI on external systems are only as defensible as their review trail. An assessor will ask who wrote the current version, when it was last reviewed, what changed since the last cycle, and who approved it. Wiki and documentation platforms can answer the mechanical part of those questions. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. Used for the PM-17 policy and its procedures, that history gives the reviewer a record of each revision rather than a reconstruction from memory. Confirm with your own deployment which page history and retention settings apply before you rely on it as evidence.

BookStack controls who can do what through the roles assigned to each user, and its permissions can be overridden per role at the shelf, book, chapter or page level. For PM-17 this lets you separate the people who draft procedures for handling CUI on external systems, the reviewers who check them against the organization's CUI obligations, and the approvers who sign off. A practical check is to confirm that the editor role cannot approve its own changes and that only the designated approvers can mark a version as current. Record that mapping in the policy itself so an assessor can see who holds each responsibility at the time of review.

The platform records change, but it does not decide anything. The organization owns the decisions that matter for PM-17: the review frequency it defines, whether a change to its CUI requirements is needed after a regulatory update, whether an external system is acceptable for CUI, and whether the policy is approved. Those decisions should be documented as approvals with names, dates and the version they applied to, and that record should live where the version history can point to it. An implementation partner can configure the platform and document the workflow, but the accountable official, not the tool or the partner, must make and sign these decisions.

Who owns PM-17: your team, a partner and the auditor

PM-17 asks for policy and procedures that make sure requirements for protecting controlled unclassified information on external systems are implemented as laws, regulations and policies require. The organization owns that policy. Leadership must decide what external systems are in use, who is accountable for CUI on them, and how the policy is approved and reviewed at the frequency the organization defines. A partner can help write the text, but the decisions behind it belong to your people.

Policy ownership: An accountable official approves the CUI policy and procedures and records that approval.
Scope decisions: Your team identifies which external systems, cloud services and contractor environments may process, store or transmit CUI.
Operational follow-through: Staff who handle CUI apply the procedures day to day and report exceptions.
Review cadence: Your team sets and runs the review frequency for the policy and procedures.
Interview readiness: The people named in the CUI responsibilities must be able to explain their role when an assessor asks.

Before any engagement starts, confirm who signs the policy, who answers assessor interviews and where the approved versions are stored.

Where PM-17 programs usually fall short

PM-17 is assessed mostly through documents and interviews, so most shortfalls appear on paper before they appear in systems. The cards below cover the gaps assessors tend to find first, from policy wording and review cycles to approval records and unclear ownership, each with a closing action the organization can take before an assessment begins.

Policy that omits external systems

A CUI policy that covers on-premises systems but says nothing about external systems leaves the core of PM-17 unaddressed. The policy should state which external systems may process, store or transmit CUI, what conditions apply to them, and how requirements flow down to providers. Check whether a cloud service, managed platform or contractor environment is named or clearly covered by a defined category. Action: add a section that defines external systems for CUI and lists the permitted categories.

Procedures that stop at policy

Assessors look for procedures that show how the policy is carried out, not only a statement that it exists. Many programs have a policy but no working steps for approving an external system, checking its CUI safeguards, or recording exceptions. Without those steps, staff cannot show consistent practice. Action: write a short procedure for each external system request that names the reviewer, the checks and the record kept.

Undefined review frequency

PM-17 requires the policy and procedures to be reviewed and updated at a defined frequency. Programs often leave that frequency unstated, or set it in one document and ignore it in another. When reviews slip, the assessor finds a policy that no longer reflects current external services. Action: state one review interval in the policy and track the next review date in a calendar or ticket queue.

Missing approval and version records

A reviewed policy still needs evidence of who approved it and when. Programs frequently keep the current draft in a shared folder with no approval signature, no change history and no record of the prior version. Version control in a documentation platform can hold this history, and it helps to confirm that the approver is the official accountable for the program. Action: store each approved version with its approver, date and change summary in a version-controlled wiki.

Unclear CUI responsibilities

In interviews, assessors ask personnel with CUI responsibilities what they do. Vague answers, or answers that differ between the security, contracts and IT teams, show that ownership is not settled. The gap is often between the team that signs external contracts and the team that configures the systems. Action: write a responsibility matrix that names one owner for each external CUI decision and confirm each owner can describe it.

Access to CUI procedures

Procedures are only useful if the right people can find and use them. Some programs restrict the wiki or shared drive so tightly that system owners cannot read the CUI steps, while others leave the documents open to anyone. Role-based permissions let the procedure owners edit, reviewers comment and system owners read, so the record stays accurate and controlled. Action: map each CUI document to the roles that need read, review or edit rights and apply those roles in the platform.

Questions buyers ask about PM-17

Is PM-17 required for my system if it is not high impact?

PM-17 is not allocated to the low, moderate or high baselines, because SP 800-53B treats Program Management controls as organization-wide and independent of system impact level. It does appear in the SP 800-53B privacy baseline, which applies to systems regardless of impact level. So whether it applies to you depends on whether your systems fall under the privacy baseline and on the laws, contracts or agency requirements that govern your CUI. Confirm with the requester which baseline or contract clause they are applying, and check whether the privacy baseline is in scope for your processing of personal information.

What drives the cost of meeting PM-17?

The cost of PM-17 is mostly the cost of writing and maintaining one organization-wide CUI policy and its procedures, then making sure every external system that touches CUI follows them. The main cost drivers are the number of external systems that process, store or transmit CUI, how many laws, regulations and contract clauses the policy must reflect, how many teams handle CUI, and whether policies already exist that can be extended. Policy work is usually one-time, while review and updates at the defined frequency, staff interviews and evidence collection recur. Ask any provider to price these components separately and state which ones are in scope.

How long does it take to put a PM-17 policy in place?

No researched duration exists for PM-17, so any timeline you are given should be checked against the work it covers. The schedule depends on how many governing requirements apply, whether a CUI policy already exists, how many external systems must be brought under it, and how quickly leadership approves the document. A reasonable plan separates drafting, review and approval, rollout to staff and an evidence check before an assessor arrives. Ask for milestones tied to written deliverables instead of a single end date.

What does the organization need to supply before the work starts?

The organization owns PM-17. It must supply the laws, regulations, contract clauses and agency policies that govern its CUI, an inventory or description of the external systems that handle CUI, the names of the people with CUI responsibilities, and the decision-makers who will approve the policy and procedures. Existing records such as data classification rules, third-party agreements and prior assessment findings save time. Without these inputs, any policy written by an outside party will describe requirements the organization has not confirmed.

Can we do PM-17 in-house without an outside partner?

Yes, if you have people who understand both your CUI obligations and your external system landscape. The SP 800-53A assessment for PM-17 looks for CUI policy and procedures and for interviews with personnel who hold CUI responsibilities, so the work is largely documentation, role assignment and staff awareness rather than engineering. Many teams handle this internally and bring in help only for a gap review or for the technical controls on external systems. Be honest about whether your staff have time, and whether someone can keep the policy current at the frequency you define.

What does an implementation partner do for PM-17, and what does it not do?

A DeployOpen-style implementation partner can help prepare the systems, documentation and evidence that support PM-17, such as drafting procedures for review, organizing the records an assessor will examine, and setting up self-hosted platforms that hold the policy under version control with approval history. The partner does not own the control, does not decide which laws apply, and does not issue an assessment result. Only an independent assessor or certification body issues findings or certificates. Agree the deliverables in writing before work starts, since engagements are usually fixed-scope.

Which evidence will an assessor ask to see for PM-17?

For PM-17, the assessment method names two activities: examining the CUI policy and CUI procedures, and interviewing personnel with CUI responsibilities. Evidence therefore includes the approved policy, the procedures that implement it on external systems, dated revision history, and records showing that the people named in the policy understand their duties. Keeping the document set in a wiki with version history and role-based permissions makes it easier to show who changed what and who could approve it. Confirm the exact assessment objects and determination statements in SP 800-53A before you assemble the package.

Does PM-17 depend on other controls I need to plan for?

Yes. The SP 800-53 catalog links PM-17 to CA-6 and PM-10, so the authorization process and the security assessment process should be aligned with your CUI policy. In practice, that means the authorizing official's decisions about external systems should reference the CUI requirements, and the procedures should match what authorization packages say. Check these related controls in the catalog before finalizing scope, because a policy that ignores them tends to produce findings during authorization reviews.

How PM-17 connects to CA-6 and PM-10

The NIST SP 800-53 Release 5.2.0 catalog lists two related controls for PM-17: CA-6 (authorization) and PM-10 (authorization process). PM-17 sets the organization-wide policy and procedures for protecting controlled unclassified information on external systems, while CA-6 and PM-10 are where that policy turns into decisions about specific systems. An authorizing official deciding whether an external system may process, store or transmit CUI needs a clear, written answer to the question the PM-17 policy poses: does this external system meet the CUI requirements that laws, regulations and policies impose? Without that policy in place, authorization decisions for external systems have no stable reference point and tend to be made case by case.

In practice, the link runs in both directions. Under PM-10, the organization manages the security state of systems through an authorization process and assigns the risk management roles that carry it out, so the PM-17 procedures should name who reviews an external system, which evidence that reviewer needs and who can accept the residual risk. Under CA-6, the authorizing official reviews the assessment results and decides whether to authorize operation. Confirm with your own assessor and authorizing official which documents they expect for external CUI systems, such as the external system's own security documentation, the agreements that govern CUI handling and the assessment results that show the requirements are met. Check that the policy and the authorization records use the same definitions of external system and CUI.

A practical check is to pick one external service that already handles CUI, trace its authorization record back to the PM-17 policy and confirm each step can be shown. If the trace breaks, for example because no authorization decision cites the external-system requirements, that gap belongs in the plan of action and milestones before the next assessment. The SP 800-53A assessment procedures for PM-17 focus on examining the CUI policy and procedures and interviewing the personnel who hold CUI responsibilities, so the authorization records and the people who sign them are the evidence an assessor will ask to see.

PM-17 Protecting controlled unclassified information on external systems