PT-1 Policy and procedures: requirements and evidence

What PT-1 asks for and why a privacy team cannot skip it

PT-1 requires a written PII processing and transparency policy, plus procedures that put it into practice, and both must be disseminated to defined roles, owned by a designated official, and reviewed and updated at a defined frequency and after defined events. For a privacy or compliance lead, this is the control that proves the organization has decided how personally identifiable information is handled before an assessor asks how any single system does it. The policy has to address purpose, scope, roles, responsibilities, management commitment, coordination among entities and compliance, and the procedures must show how each of those points is carried out.

The risk PT-1 addresses is familiar: PII is collected, shared or retained through habit rather than decision, and the written policy describes a process nobody follows. Teams often find that privacy notices, data inventories, consent records and processing authorities sit in different tools with different owners, and that the policy was approved once and never revisited after a new product, a new data source or a reorganization. Those gaps are what an assessor will test first, because the examine and interview methods in SP 800-53A Rev. 5 look for a policy that matches what personnel with PII responsibilities actually say and do.

The privacy baseline applies to a system regardless of its security impact level, so PT-1 is needed even where the system would otherwise sit in the low baseline. Confirm with your assessor and your own privacy program plan which PT-1 parameters your organization has defined, then check the related controls PM-18, PM-20, PM-27 and SI-2, since they draw on the same policy, plan and review cycle. Before you start, decide who owns the policy, which events trigger an out-of-cycle review, and where the approved version and its change history will live.

Which systems, teams and third parties PT-1 reaches

PT-1 only works if the policy reaches the right scope. Before drafting, the organization decides the level at which the policy applies, which systems fall in the privacy baseline, who is accountable, and how processors are bound. Each card below is one of those decisions and what it changes for the policy and its procedures.

Choosing the policy level

PT-1 lets the organization set the PII processing and transparency policy at the organization, mission or business process, or system level. An organization-wide policy is easier to keep consistent, while a system-level policy suits a single high-risk processing activity. Many programs use one enterprise policy with procedures per business process. Decide the level in writing and confirm that the privacy program plan names it, because assessors check that the policy and procedures match the scope the organization declared.

Mapping systems to the privacy baseline

SP 800-53B places the PT family in the privacy baseline, which applies to systems regardless of impact level. A low-impact system that processes PII still needs PT-1 coverage, even though its security baseline is lighter. Build an inventory of systems that process PII and tag each one, so the policy's scope matches the systems actually in the privacy baseline. Ask the system owners to confirm the inventory each review cycle.

Naming the privacy officer

The policy must be managed by a designated official, and the organization should name a single accountable privacy officer in writing. That person owns the policy text, approves procedures, and answers assessor interviews on PT-1. Confirm the officer has authority over system owners and budget, not only advisory status, since assessors look for a role that can enforce the policy rather than one that only comments on it.

Assigning system owners and data stewards

System owners carry out procedures for the systems they run, and data stewards maintain the accuracy of the PII those systems hold. Write both roles into the procedures with their duties named, such as keeping processing purposes current or flagging a new data category. Without named stewards, procedures tend to exist on paper while no one reviews the data they describe. Record who holds each role for every in-scope system.

Bringing HR and legal into scope

HR and legal shape several PT inputs, including employee PII, the wording of privacy notices, and how the organization responds to legal authority questions. The policy should assign them specific roles, such as HR owning workforce data processing and legal reviewing the authority basis for each activity. Confirm these functions sign off on the procedures, since an assessor interviewing HR or legal staff will expect them to describe their part.

Binding processors and service providers

Third parties that handle PII on the organization's behalf fall under the policy only if the contracts say so. Identify each processor and service provider that touches in-scope PII, then require them to follow the purposes and restrictions in the policy through contract terms and data processing agreements. Keep the list current when a provider changes, since a policy that stops at the organization's own boundary leaves outsourced processing unexamined.

How an assessor tests PT-1 under SP 800-53A

This table compares what an assessor does for each part of PT-1 under the SP 800-53A procedure, what evidence they request and where findings usually arise. Read it as a preparation checklist: the policy and procedures and privacy program plan are examined, and the people who run PII processing are interviewed to confirm the documents match practice.

Assessment area	Test approach	Evidence requested	Common findings
Policy content	Examine the PT policy against the required topics: purpose, scope, roles, responsibilities, management commitment, coordination and compliance	Current PT policy with version history and approval record	Policy exists but omits scope or does not name the roles responsible for PII processing
Procedures	Examine whether procedures show how the policy is carried out for PII processing and transparency activities	Written procedures tied to named processes, such as privacy notice review or authority determination	Procedures are generic or describe a process no team actually runs
Dissemination	Confirm the policy and procedures reached the defined roles and are available to them	Distribution list, acknowledgement records or publication location with access history	Documents sit in a folder that the responsible staff cannot reach or have never opened
Designated official	Confirm a named official manages the policy and procedures	Appointment record or role description naming the official and their authority	Ownership is assigned to a team or mailbox rather than a person
Review and update cycle	Compare the defined review frequency and triggering events with the review history	Dated review records, change logs and records of updates after triggering events	Review dates are missed, or the defined events such as a new processing activity are not reflected
Privacy program plan	Examine whether the privacy program plan reflects the PT policy and its roles	Privacy program plan and cross-references to PT-1 content	Plan and policy describe different roles or different scopes
Personnel interviews	Interview staff with PT responsibilities to confirm they know their duties and the procedures in use	Interview notes and any training or briefing records the staff can point to	Staff describe practices that differ from the written procedures

Sequence for writing and operating a PT-1 policy

This sequence takes an organization from an undefined PII processing policy to an approved, published and reviewed PT-1 policy with implementing procedures that assessors can examine. Each step closes with a record that shows the control is operating, not just documented.

Confirm the policy level and scope
Decide whether the PT-1 policy applies at the organization, mission or business process, or system level, and list the systems and processing activities it covers. Your privacy office and system owners should confirm which PII processing activities exist before drafting starts, because an inventory gap here carries into every later step. The output is a short scope statement that names the level, the systems in scope and the business owners who depend on the policy. The step is done when the privacy and security leads both sign off on that scope statement.
Name the designated official
Assign one official to manage the PT policy and procedures, and record that appointment in writing. The official owns the review schedule, approves changes and answers assessor questions about the control. Confirm the appointment with the organization's governance process, since the designation is what SP 800-53A assessors look for when they interview personnel with PII processing responsibilities. The output is a signed appointment or role description that names the official and the backup for absences.
Draft the policy content
Write the policy so it addresses purpose, scope, roles, responsibilities, management commitment, coordination among entities, and compliance. Use your own organization's terms and map each section to the processing activities confirmed in step one. Where PT-2 through PT-8 apply to your systems, cross-reference the policies that govern them rather than restating them. The output is a draft policy with a version number and a list of the owners named for each section, ready for legal and privacy review.
Write the implementing procedures
Write the procedures that carry out the policy, such as how new PII processing is recorded, how privacy staff review changes, and how exceptions are requested and approved. Each procedure should name the role that performs each step and the record it creates. Confirm the procedures against the systems people actually use, because assessors test whether procedures are implemented, not only whether they exist. The output is a procedure set with an index that links each procedure to the policy section it supports.
Define dissemination and review triggers
Specify which defined roles receive the policy and procedures, the channel used to distribute them, and the review frequency and events that trigger an update. Triggers commonly include changes in law, new processing activities, system changes and incidents, but the organization must define its own list and frequency. Confirm the frequency with the designated official, since the control requires the organization to set it. The output is a dissemination plan that names recipients, channels and the triggers that force a review.
Approve and publish the policy
Obtain approval from the management level that the policy names, record the approval date and version, and publish the policy and procedures in the document system your staff use. Keep superseded versions available for comparison. Confirm that the approving authority matches the management commitment described in the policy. The output is an approved, signed policy and procedure set, plus a distribution record showing who received it and when.
Set the review log and maintain evidence
Open a review log that records each scheduled review, each event-driven review, the reviewer, the changes made and the approval for those changes. Keep the distribution record current as roles change. This log is the evidence assessors usually examine first, so make sure every entry links to the version it reviewed. The output is a maintained review record that shows the policy has been reviewed at the defined frequency and after defined events, which keeps PT-1 operating between assessments.

How the PT-1 policy connects to the privacy program plan and the CSF

The PT-1 policy is the anchor for the rest of the PII processing and transparency family. The authority rules in PT-2, the purpose limits in PT-3, consent in PT-4, privacy notices in PT-5, system of records notices in PT-6, specific PII categories in PT-7 and computer matching in PT-8 all need a documented rule to point to, and the PT-1 policy is where that rule lives. Assessors usually read it first and then check each later control against it. Before you scope PT-2 through PT-8, confirm that the policy names the owner of each processing decision and states the review triggers that apply to them. Also confirm that the procedures are written at the level of detail a privacy analyst could follow without asking the author.

Assessors also read the PT-1 policy alongside the privacy program plan, which is the document the SP 800-53A procedure lists as an object to examine. The policy sets the rules and the program plan shows how the organization carries them out across systems, so the two should use the same role names, the same review cycle and the same description of management commitment. A mismatch between them is a common finding. Ask the policy owner to confirm which document governs when they conflict, and check that the program plan references the current policy version rather than an earlier one.

NIST's OLIR catalog lists PT-1 as an informative reference for eight CSF 2.0 subcategories: GV.OC-03, GV.OV-01, GV.PO-01, GV.PO-02, GV.SC-03, ID.IM-01, ID.IM-02 and ID.IM-03. Treat this as a way to reuse evidence. A PT-1 policy and its review records can support those CSF subcategories in a CSF profile, but the mapping does not certify equivalence, and NIST marks the crosswalk as not comprehensive, so some CSF outcomes will need their own evidence. The NIST OLIR informative reference is the natural next read for checking which CSF subcategories your organization wants to cover.

Evidence that passes a PT-1 review

An assessor testing PT-1 looks for a policy and procedures set that is approved, distributed, owned and kept current, and each card below is one artifact that proves a piece of that. The artifacts only count if they are maintained between assessments, so each card also explains how to keep it current.

Signed PT policy with approval record

The PII processing and transparency policy itself, with a version number, an effective date and the approval of the official who owns it. Assessors check that the policy addresses purpose, scope, roles, responsibilities, management commitment, coordination and compliance. Confirm that the approval record names the approver and the date, and that the text in the approved version matches what staff can currently read. Keep the signed copy in the controlled repository so the approved version cannot be silently edited.

Implementing procedures

The procedures show how the policy is carried out in practice, such as who reviews a new processing activity and how a purpose change is recorded. Each procedure should name the role that performs each step and the record it produces. Assessors compare procedures with the systems in scope, so a procedure that describes a process no team follows is a finding. Tie each procedure to the policy section it implements.

Distribution and acknowledgment records

PT-1 requires the policy and procedures to be disseminated to defined roles, so keep proof of who received them and when. Acknowledgment records, such as signed attestations or training completion logs, show that personnel with PII responsibilities actually read the current version. When the policy changes, confirm that the acknowledgment cycle restarts for the affected roles. Ask the organization to confirm which roles it has defined as recipients.

Designated official appointment

PT-1 requires the policy to be managed by a designated official, so the appointment must be written down. The appointment letter or role description should state the official's authority, the scope of the policy they manage, and their reporting line to the privacy program. Assessors ask the official to explain what they do each review cycle, so confirm the person can answer those questions. Update the appointment record whenever the role changes hands.

Review and update log with triggers

A review log records each scheduled review and each event-driven review, along with the outcome and any changes made. The organization sets its own review frequency and triggering events, and the log must show it followed them. Gaps between the defined schedule and the recorded reviews are the most common finding. Record the trigger for each out-of-cycle review, such as a new processing activity or a legal change, so the reason for the update is traceable.

Link to the privacy program plan

PT-1 assessment expects the policy and procedures to be consistent with the privacy program plan, which is one of the examine objects listed for this control. Keep a cross-reference table that maps each policy section to the matching program plan section, and update it whenever either document changes. Assessors often compare the two side by side, so contradictory purpose statements or role names are easy to spot. Confirm the plan version cited in the policy is the current one.

What meeting PT-1 costs in money and effort

This table breaks the PT-1 effort into cost components, showing who is paid for each, whether it is one-time or recurring, what drives it up and how to keep it down. NIST does not estimate compliance costs and no figures are supplied here, so use the rows to structure a written quote and compare bids on the same scope.

Cost component	One-time or recurring	What drives it	How to keep it down
Internal drafting of the PT policy and procedures	One-time, then recurring at each review	Number of systems and business processes that set the policy level, and how many PII processing activities must be described	Start from one agreed template covering purpose, scope, roles, management commitment, coordination and compliance, then tailor it per system only where needed
Legal and privacy review	Recurring at each review cycle and after triggering events	Jurisdictions, sector rules and changes in processing that require counsel or the privacy office to sign off	Scope legal review to the policy and procedures themselves, and reuse prior approvals when the text changes only in minor ways
Designation and management sign-off	Recurring	Need for a designated official and documented management commitment at each update	Record the designation and sign-off in the same document control workflow used for other policies
Dissemination and role-based training	Recurring, usually tied to onboarding and policy changes	Number of defined roles that receive the policy and procedures and the frequency of acknowledgments	Publish one authoritative copy with read-and-acknowledge tracking rather than separate distribution per team
Document control tooling	Recurring license or hosting cost for commercial tools, or one-time setup and hosting for self-hosted tools	Number of users, need for version history, approval workflows and role-based access, and whether the tool sits inside the organization	Self-hosted open-source wikis such as XWiki (LGPL-2.1-or-later) or BookStack (MIT) can keep version history and per-page permissions without per-seat license spend, though hosting and administration remain internal or contracted costs
Review and update cycles	Recurring at the defined frequency and after defined events	How often the organization sets its review interval, how many events trigger updates, and how many policies must be checked together	Align the PT-1 review date with other privacy and security policy reviews and record the trigger events in advance
Evidence collection for assessors	Recurring at each assessment	Number of documents an assessor examines and whether version history, approvals and dissemination records are easy to retrieve	Keep the version history, approval records and acknowledgments in one place so the assessor can examine them without manual reconstruction
Assessor time and implementation partner support	Recurring at each assessment, plus one-time readiness work if needed	Assessment scope, number of interviews with personnel holding PT responsibilities, and how well-prepared the evidence is	Request a fixed-scope quote that names the documents, interviews and deliverables, and confirm whether the assessor or the partner prepares the evidence

Self-hosted tools that keep PT-1 documents under control

XWiki is an open-source wiki under the LGPL-2.1-or-later license. For PT-1, its main value is revision history. The PII processing and transparency policy and its procedures are the documents an assessor will ask to examine, and the assessor will also ask how the organization knows which version was in force on a given date. XWiki keeps every change to a page under version control, so the page history is the record of what changed, when and by whom.

Change history: Each saved edit is kept as a numbered version showing the author and time, so you can show when a review update to the PT policy was made.
Version comparison: Assessors can compare any two versions side by side, which helps when checking that a revised policy kept required sections such as roles and review cycles.
Rollback: If an unapproved edit is saved, an earlier approved version can be restored. The rollback itself is recorded, so the restore is visible in the history.
Review trail: Pair the wiki history with the approval record kept outside the tool, such as a sign-off in a ticket, so each version links to a named approver.
Export for assessors: Confirm with your platform team how history is preserved in backups and exports, since the assessor may need copies taken at specific points.

XWiki shows what changed and who changed it, but it does not decide what the PT policy must say or who owns it. Confirm with your assessor and your own audit requirements that the wiki history meets their evidence expectations.

Where PT-1 programs usually fall short

PT-1 is less a single document than a chain: a policy is written, disseminated, owned, reviewed and then followed in practice. Most weak PT-1 programs break at one link in that chain, and assessors test each link separately.

Policy written but not disseminated

The PII processing and transparency policy exists as a document, but the roles that handle personal data never receive it or acknowledge it. PT-1 requires dissemination to defined roles, so an assessor will ask who received the policy, when, and how. Check distribution lists, acknowledgment records and whether engineers, support staff and data owners can find the current version. A policy stored only in a privacy team folder does not meet this requirement.

No designated official

PT-1 expects the policy and procedures to be managed by a designated official. In many organizations the policy is shared between legal, the privacy office and IT, and nobody owns the update cycle. Confirm that a named role, with a deputy, is recorded in the policy itself and in the privacy program plan. An ownerless policy tends to go stale, and assessors treat an unnamed owner as a gap in the control, not a detail.

Review frequency defined but not followed

Many policies state an annual review and a list of events that trigger an update, then show a revision date that is years old. PT-1 requires review and update at the frequency the organization defines and after the defined events. Check the revision history against the stated interval, and confirm that events such as new processing activities, system changes or legal changes actually produced updates. Version control in a wiki or document system helps prove the review trail.

Procedures that describe unused processes

Procedures often describe an ideal workflow for handling PII, such as purpose review or authority checks, that staff do not perform. The procedures must match the process people run, because assessors interview the personnel who carry them out. Walk through one real processing change with the team, compare what they do against the written steps, and record the gaps. Then either change the procedure to match reality or change the practice, and document which you chose.

Policy out of step with PII flows

The policy names categories of personal data, systems and purposes that were accurate when it was drafted, but new applications, analytics pipelines and third-party integrations have since changed where PII moves. A policy that does not reflect actual flows cannot support the authority and purpose controls it governs. Build or refresh a data inventory first, then check the policy scope, roles and procedures against it. Mismatches between the policy and the inventory are the most common finding.

PT-1 questions buyers ask before bringing in help

How much effort does a first PT-1 policy take?

The effort depends on how many systems process PII, how many privacy and business processes already have written rules, and how much of the privacy program plan exists. No duration figure is supplied for this work, so treat any number a vendor gives as a claim to test. A first PT-1 policy usually needs a drafting pass that covers purpose, scope, roles, responsibilities, management commitment, coordination and compliance, followed by procedures that show staff how to apply it. The drivers are the number of PII processing activities that need to be described, the level of agreement needed from legal, privacy and system owners, and whether the policy sits at organization, mission or system level. Ask any partner for a written scope that lists the policy documents, the procedure documents and the review rounds included.

Can our team write a PT-1 policy without a partner?

Yes, an internal privacy or compliance team can write PT-1 documents without outside help, and many organizations do. The control is a governance document, so the main risk is not the writing but the adoption: the policy must be disseminated to defined roles, managed by a designated official and reviewed on a schedule the organization sets. Teams without prior NIST SP 800-53 experience often benefit from reading the control in the NIST CPRT and the SP 800-53A assessment procedure before drafting, so that each determination statement has a matching section or record. An implementation partner can help with the systems that hold the documents, such as version control and access permissions, but it does not write the organization's policy as an authority on its behalf.

What does PT-1 need from privacy and system owners?

PT-1 needs privacy leads and system owners to supply accurate facts about how PII is processed, not just approval of a draft. The privacy office typically owns the policy text, the designated official and the review cycle. System owners supply the processing activities, data flows and roles that the procedures must describe. Assessors interview personnel with PII processing and transparency responsibilities, so those people need to know the policy and the procedures well enough to explain them. Ask internally who signs off on the policy, who receives updates and who records review dates before any drafting starts, because unclear ownership is the most common reason the control fails an assessment.

How long does PT-1 take to complete?

No duration figure is supplied for PT-1, so this page does not give one. The timeline should come from your organization's own plan, which sets the target dates for drafting, legal review, approval, dissemination and the first scheduled review. Those dates depend on your approval chain, the number of systems in scope and any dependency on the privacy program plan or system security and privacy plans. Ask any implementation partner to show the milestones and the client reviews in the written scope, and confirm whether assessment support is part of the same engagement or a separate one.

Does PT-1 apply to low or moderate impact systems?

No. SP 800-53B does not allocate PII Processing and Transparency controls to the low, moderate or high security control baselines. PT-1 sits in the privacy control baseline, which applies to systems regardless of impact level. A system categorized as low, moderate or high for security may still need PT-1 if it processes PII and the privacy baseline is selected for it. Confirm your selected baseline with your authorizing official or privacy office, and check the current SP 800-53B profiles in OSCAL before you assume a system is out of scope.

Can an implementation partner issue a PT-1 assessment?

No. An implementation partner can prepare the policy, procedures, records and system configuration that support PT-1, but it cannot issue an assessment, attestation or authorization. Only the organization's independent assessor, or the body that authorizes the system under the organization's own program, can assess the control and report on it. DeployOpen prepares systems, controls and evidence for compliance assessments, and the assessor then tests them. The organization remains responsible for its controls, so ask any partner to state in writing which evidence it prepares and which parts remain the assessor's work.

How does PT-1 relate to the privacy program plan?

PT-1 requires a policy and procedures that govern PII processing and transparency, while the privacy program plan describes the organization-wide privacy program that the policy operates within. The assessment procedure for PT-1 lists the privacy program plan as a potential assessment object to examine alongside the policy and procedures, so the two must agree on purpose, roles and review responsibilities. The related controls in the catalog are PM-18, PM-20, PM-27 and SI-2, so check how those program and system controls reference the PT policy. Keep one version of each document in a controlled repository so that an assessor can compare them without reconciling conflicting copies.

How DeployOpen prepares PT-1 policy and evidence

DeployOpen works on PT-1 as a documentation and system-preparation task inside your own environment. We help you define what the PII processing and transparency policy and procedures must cover, prepare the systems that hold them, and organize the evidence an assessor will examine. Your organization owns the policy and its approval, and an independent assessor reaches its own conclusions.

How we scope

Confirm which systems and business processes process PII and fall under the privacy baseline for PT-1.
Agree in writing which policy levels (organization, mission, business process or system) the written scope covers.
Identify the designated official, the defined roles and the review frequency your organization has set or must set.

How we build

Draft a PT-1 policy outline covering purpose, scope, roles, responsibilities, management commitment, coordination and compliance, for your review.
Set up a self-hosted document system with version history so each policy and procedure change is recorded.
Configure role-based permissions so only designated owners can approve, edit or publish PT policy and procedure documents.

How we hand over

Deliver a document register mapping each PT-1 determination statement to the policy or procedure that addresses it.
Provide a dissemination record template showing which defined roles received each approved version and when.
Document the review and update history, including the events that trigger an out-of-cycle review of PT-1 documents.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and documentation maintenance are available as a retainer after handover.
Confirm with your assessor which PT-1 evidence they will request, since assessment objects can vary by organization and system.