PT-5 Privacy notice

PT-5 asks an organization to give individuals a clear privacy notice when they first interact with it and at a defined frequency afterward. This page covers what assessors test, the evidence that passes and what the work costs.

On this page

What the PT-5 privacy notice requirement asks for

PT-5 requires the organization to give individuals a privacy notice about how their personally identifiable information is processed, and to make that notice available when they first interact with the organization and at a defined frequency afterward. The notice must be clear and written in plain language, and it must state the authority for the processing and the purposes it serves, along with other information the control defines. In an audit or contract scope, the assessor will check two things first: whether the notice exists and reaches people at the right moments, and whether its content matches what the system actually does with PII. PT-5 sits in the privacy control baseline, which applies to a system regardless of its security impact level. A low-impact system that holds personal data is therefore in scope for this control even though the moderate and high baselines do not add it.

The risk behind PT-5 is opaque processing: individuals cannot exercise choices or challenge uses of their data if they do not know what happens to it. The control is hard to keep current because notices are written once and then drift. A new analytics tool, a new data field, a new sharing partner or a retention change can alter processing while the notice still describes the old design. Assessors commonly test this gap by comparing the notice with system documentation, data flow records and interviews with the staff who own the user interface and user experience. Before an assessment, the organization should confirm who owns each notice, which system changes trigger a review, and how the notice version in production is tied to the processing purposes recorded under PT-3 and the authority recorded under PT-2.

PT-5 has one enhancement in the SP 800-53 Release 5.2.0 catalog, PT-5(2), which the privacy baseline adds. It concerns Privacy Act statements, which are notices given where individuals supply information that will be stored in a system of records. Organizations outside US federal agencies should treat that enhancement as applicable only where a comparable statutory notice duty applies to them. PT-5 is also linked to nine related controls in the catalog: PM-20, PM-22, PT-2, PT-3, PT-4, PT-7, RA-3, SC-42 and SI-18. Those links are the practical starting point for an assessor's questions, so confirm the notice evidence with the owners of the authority, purpose, consent and risk assessment records before the assessment window opens.

Which systems, data and teams does PT-5 reach

PT-5 applies wherever the organization processes PII, so scope starts from data flows rather than from security categorization. The cards below cover the collection points, processors and owners that determine which notices must exist and who has to keep them accurate.

Direct collection through web and apps

Every public website, customer portal, mobile app and embedded form that asks individuals for PII is a notice surface. Inventory each page and screen where data is entered, including account sign-up, support forms and cookie or tracking banners, and confirm that the notice is reachable at the first point of interaction. Check that single-page apps and login-gated flows do not skip the notice for new users.

Paper, call-center and in-person intake

Notices are often missing from channels outside the digital estate. Forms printed for benefits, applications taken at branches, and scripts used by call-center agents collect PII and need a notice that the individual can actually receive. Confirm that paper forms carry the notice text, that agents have a current script, and that recorded calls are covered by the same notice content.

Third-party processors and embedded services

When a vendor, analytics provider, payment processor or hosted form collects PII on the organization's behalf, the notice must still describe that processing. Map each external service to the data it receives and the purpose it serves, then compare that list against what the notice says. Gaps often appear in tag managers, chat widgets and survey tools that were added after the notice was written.

Internal systems that gather PII from staff

Employee onboarding portals, HR systems and internal case tools also process PII and fall within PT-5 when the processing is not otherwise covered. Decide with privacy counsel which internal collections need a notice, and record that decision in the PII inventory so assessors can see why some systems were excluded.

UX, product and content owners

The people who write, place and change notice text are usually in product, user experience or content teams, not in security. Assign named owners for each notice surface, give them the notice text and change process, and include them in interviews, since the assessment procedure for PT-5 includes interviewing personnel with user interface or user experience responsibilities.

Release changes that alter processing

A new feature, data field or vendor can change what a notice must say without anyone touching the notice. Tie notice review to the change process so that a release adding a data collection point triggers a check of the affected notice. Ask engineering leads how they identify new PII fields, because undocumented changes are the usual cause of stale notices.

How an assessor tests PT-5

This table maps the three assessment methods that SP 800-53A Rev. 5 uses for PT-5 to the evidence an assessor requests and the findings they commonly raise. Read each row as one line of the assessment, and use the evidence column to prepare the files before the assessor asks for them.

Assessment methodEvidence requestedCommon findings
Examine privacy notices and Privacy Act statementsCurrent privacy notices, version history with dates, Privacy Act statements where applicable, and the screens or forms that present themNotice text does not name the processing authority or purposes; notice wording no longer matches what the system actually collects
Interview personnel with user interface or user experience responsibilitiesNamed owners for each notice touchpoint, design or content review records, and staff explanations of when and how users see the noticeProduct or design teams are unaware of a notice requirement; new user flows were released without privacy review
Test processes and mechanisms that deliver noticeEvidence that the notice appears at first interaction, the defined review frequency, and logs or screenshots from test runs showing delivery to usersNotice is not shown at first interaction, such as after data is already collected; notices lag behind changes in processing; the review cycle is defined but not performed
Test notice availability across channelsTest scripts or walkthroughs covering web, mobile, API and paper or call-center channels, with resultsNotice is present on the main website but missing from mobile apps, partner portals or support workflows
Verify plain language and completenessReadability review records, the list of other information the control requires, and sign-off by privacy staffNotices use dense legal wording without a summary; required elements are scattered or absent
Confirm the notice reflects current processingMapping between notice content, the PT-2 authority records and the PT-3 purpose records, and change tickets linking processing changes to notice updatesNotice lists purposes that no longer exist or omits newly added processing; authority cited in the notice differs from the records

How to build a PT-5 notice program step by step

This sequence takes a privacy notice from an unknown set of collection points to a tested, maintained set of notices that tell individuals who is processing their PII, why, and under what authority. Each step produces a artifact an assessor can examine.

  1. Inventory every PII collection point

    Start by listing each place the system or organization collects PII from individuals: web forms, mobile screens, call scripts, paper intake, API endpoints, and data received from third parties that is later shown to the individual. The privacy or product owner leads this, with input from engineering and operations, because collection points are often created by teams that do not think of them as privacy events. The output is a collection-point inventory that names the channel, the data elements, the system of record, and the owner of each point. The step is done when a sample walkthrough of each channel finds no PII collection missing from the list.

  2. Document authority and purposes from PT-2 and PT-3

    Take each collection point and attach the authority and purposes already documented under PT-2 and PT-3. PT-5 does not create these determinations; it requires the notice to state them accurately, so a gap here means the notice cannot be written correctly. Privacy counsel or the privacy office confirms the legal or other authority for each processing activity, and the business owner confirms the purposes match actual use. The output is a mapping table from each collection point to its authority, purposes and any compatible secondary uses. The step is done when every row has a named approver and no purpose appears in the notice that is absent from the PT-3 record.

  3. Draft plain-language notice text

    Write the notice for each collection point in plain language that an individual can read without specialist knowledge. The text should identify the authority, the purposes, the categories of PII processed, and the other information the organization has defined for the notice, in the order a reader would expect. Store drafts in a versioned wiki or document system so each change, author and approval is recorded. The output is a set of approved draft notices, one per collection point or per shared template, with a reading-level and content check recorded. The step is done when a reviewer outside the project team can explain back the purpose and authority from the text alone.

  4. Define the presentation point and review frequency

    Decide where and when each notice is shown. PT-5 expects availability when the individual first interacts with the organization, and a defined frequency after that, so the design must specify the first-interaction point for each channel, any repeat presentation, and how a person can return to the notice later. User experience and product owners set the placement, and the privacy office sets the review interval, which the organization must define and document. The output is a presentation specification per channel showing the trigger, placement, format and review interval. The step is done when each channel has a specification that names both the first-interaction point and the review cadence.

  5. Build and test notices on each channel

    Implement the notice in each channel as specified and test it as an individual would encounter it. Testing should cover desktop and mobile web, applications, paper or call scripts, and any API or partner channel where notice is delivered by another party. Capture dated screenshots or transcripts of the notice at the presentation point, and confirm that the text matches the approved version. Interviews with the user interface or user experience staff responsible for the channel help show who owns the placement. The output is a tested notice screenshot set and a test record showing the result for each channel. The step is done when every channel shows the approved text at the defined trigger, with any defect logged and retested.

  6. Set notice owners and version control

    Assign an owner for each notice and record how it is updated. Use an access model that lets the privacy office approve changes while product teams propose them, and keep the approved history so an assessor can see which version was live on which channel at a given time. Permission settings in the document system should reflect these roles. The output is a notice register listing each notice, its owner, its current version, its channels and its last review date. The step is done when the register is complete and the permissions match the approval roles described in the policy.

  7. Set change triggers for updating notices

    Define the events that require a notice to be reviewed and revised before the scheduled review date. Typical triggers include a new collection point, a new purpose, a change in authority, a new data category, a new third-party recipient, and a change to the presentation point. Tie these triggers to the change management process so that engineering and product releases cannot ship new PII collection without a notice review. The output is a written trigger list linked to the change process and a sample record showing a trigger firing and the resulting notice update. The step is done when a test change to a collection point produces a documented review.

  8. Run the review cycle and keep evidence current

    On the defined review frequency, and whenever a trigger fires, re-run the inventory check, confirm the authority and purposes still apply, retest the presentation on each channel, and record the outcome. Ask the organization to confirm the review interval in its own policy, since the appropriate interval depends on its processing and regulatory context. The output is a dated review log per notice with the test evidence attached. The step is done when the latest review is complete for every notice and the evidence set is ready for an assessor who examines the notices and interviews the staff responsible for them.

How notice delivery works across channels

The core point is that one privacy notice has to be delivered the same way wherever the individual meets the system, and that the notice must agree with the authority, purpose and consent records behind it. PT-5 asks that the notice be available when an individual first interacts with the organization and again at a defined frequency afterward. A web form, a mobile screen, a paper intake form, a phone script and a third-party embed each need a version of that notice that carries the same authority, purposes and rights information. The practical decision is which channel carries the full text, which carries a short notice with a link to the full text, and who approves each variant. The UX and product owners named in the assessment objectives for PT-5 are the people to involve, because truncated text on a small mobile screen or a paraphrased phone script is where notices most often drift from the approved wording.

Each channel should be mapped to the records it draws on. The authority recorded under PT-2, the purposes described under PT-3 and the consent mechanism documented under PT-4 must produce the same statements in every channel. For example, an illustrative intake system might show the purpose list in a web form, read a shorter version on a phone line and print the full notice on paper. If PT-3 adds a purpose, the notice text, the consent prompt and the call script all need to change together, and the version history should show when each channel was updated. Because third-party embeds sit outside the organization's own pages, confirm in the contract and in the test results who controls the notice text inside the embed and how changes reach it.

For an assessment, collect one notice per channel, the change record that links each version to its PT-2, PT-3 and PT-4 source, and test results showing that the notice appeared at first interaction on each channel. Ask your implementation partner and your assessor to walk through the same person's path across channels. Confirm with your privacy office whether PT-5(2), which is part of the privacy baseline, applies to your Privacy Act statements and how those statements are presented on each channel.

Which evidence passes a PT-5 review

A PT-5 assessor examines the notice itself, sees where it appears to individuals, and tests whether the organization keeps it accurate over time. The cards below cover the artifacts that answer those three questions and the routines that keep them current between assessments.

Versioned notice texts with approval records

Keep every published version of each privacy notice, with its effective date, the processing it describes and the named approver who signed off. An assessor examining the notice will ask which text was live on a given date, so the version history must answer that without reconstruction. Check that each approval names the privacy function and that the approved text matches what users actually saw. Store versions in a controlled repository where edits leave a trail.

Screenshots and recordings of first-interaction presentation

PT-5 expects notice to be available when individuals first interact with the organization. Capture dated screenshots or short screen recordings of each channel where that first interaction happens, including web forms, mobile sign-up, call scripts and paper intake. Record the path a user takes to reach the notice and note any consent prompt shown alongside it. Refresh captures after each interface change, because stale screens are a common finding.

Defined review frequency and review records

Document how often each privacy notice is reviewed and who performs the review, then keep the completed review records. The assessor will compare the scheduled frequency against the dated review entries and look for gaps. Each record should state whether the notice was confirmed unchanged or revised, and reference any processing change that triggered an out-of-cycle review. A defined cycle with missing entries is weaker evidence than a shorter cycle that is consistently performed.

Privacy Act statements where applicable

Where the organization operates a Privacy Act system of records, collect the Privacy Act statements used on forms and collection points, and map each to the system it supports. Confirm each statement names the authority for collection and the purposes, and that it appears at the point where the individual supplies information. This enhancement sits in the privacy baseline, so confirm with counsel whether your environment triggers it before assembling the set.

Change logs linking notices to processing changes

Maintain a change log that ties each notice revision to the processing change that required it, such as a new data source, purpose or recipient. Include the request, the date the change went live, the notice version it prompted and the approver. An assessor testing whether notices stay accurate will pick a recent system change and trace it forward to the notice. Gaps in this trail usually mean the notice is out of date.

Keeping evidence current between audits

Assign an owner for each artifact and attach evidence collection to existing events, such as release sign-off and the scheduled notice review. Capture screenshots at each release rather than once a year, and archive superseded versions instead of overwriting them. Run a quarterly check that every live notice matches its approved version and that the change log has no open items. Keep the storage self-hosted within your own infrastructure so the record stays under your control.

What meeting PT-5 costs in money and effort

This table breaks down the main cost components of meeting PT-5 Privacy notice, who is paid for each one, whether it is one-time or recurring, and what pushes it up or down. No price figures are published for PT-5 because NIST does not estimate compliance costs, so use the table to scope a quote and ask the right questions. The main takeaway is that notice cost grows with the number of collection points and processing purposes, and that the notice text itself is mostly internal legal and privacy time.

Cost componentWho is paid or who does the workOne-time or recurringWhat drives it
Internal legal and privacy reviewOrganization's privacy office and counsel, who confirm the authority and purposes stated in the noticeOne-time for the first notice, then recurring at each reviewNumber of processing purposes and how often they change
UX and content designOrganization's UX staff or an implementation partner who drafts plain-language text and layoutOne-time for the notice design, recurring for each revisionNumber of languages, audiences and presentation points
Engineering to build presentation pointsOrganization's engineers or an implementation partner who add notice displays at first interaction and at the defined frequencyOne-time build, with recurring maintenance as systems changeNumber of collection channels such as web forms, apps, APIs and call scripts
Evidence upkeepCompliance or privacy staff who keep notice versions, dates and screenshots available for assessorsRecurringNumber of notice versions and how long prior versions must be retrievable
External legal reviewOutside privacy counsel, paid by the hour or under a fixed-scope agreementUsually one-time for new notices, occasional for material changesJurisdictions covered and novelty of the processing
Assessor samplingIndependent assessor or auditor, paid under their own engagement, who samples notices and channelsRecurring with each assessment cycleNumber of channels sampled and quality of the evidence provided
Documentation toolingSelf-hosted wiki or documentation platform, such as XWiki or BookStack, whose licenses are open sourceSetup one-time, hosting and upkeep recurringHosting effort and staff time to administer versioned notice pages; no license fee for the open-source tools
Notice version historyPrivacy office, using page version control and role-based permissions to publish approved text onlyRecurringNumber of approvers and whether edits must be traceable to a named person

Which self-hosted open-source tools support PT-5 evidence

XWiki is an open-source wiki licensed under LGPL-2.1-or-later that can host each privacy notice as a page. Its main value for PT-5 evidence is version control. Every change to a notice page is kept, so an assessor who asks what the notice said at a given date can be shown the stored version rather than a reconstruction from memory. The same history supports the question of when a wording change was made and who made it, which helps show that the notice was kept current as processing changed.

  • Change history: Each saved edit is recorded with what changed, when it changed and the user who made the change.
  • Version comparison: Reviewers can compare any two versions of a notice to see exactly which purposes, authority statements or contact details were altered.
  • Rollback: A prior approved version can be restored if a later edit is found to be inaccurate.
  • Export for assessors: Page history and exported versions can be provided to an assessor as dated documentary evidence, subject to your own retention rules.
  • Licensing: LGPL-2.1-or-later permits use, but confirm with your legal team how the license terms apply to any modifications or extensions you build.

Before relying on XWiki, confirm the specific version history retention settings and export options in the release you deploy, and check how your backup routine preserves page history.

Where PT-5 programs usually fall short

PT-5 is easy to write once and hard to keep true. The gaps below appear when a privacy notice is treated as a document rather than a control that must match live processing. Each card names a check an assessor is likely to run and the action that closes it.

Notices shown after collection

A notice that appears after the first data capture, or only in a footer link, does not meet the requirement that individuals receive notice available when they first interact with the organization. Walk the first-use path of every system that collects PII, including sign-up forms, API onboarding, call scripts and paper intake, and record where the notice appears relative to the first field that collects data. Close it by moving the notice to the first interaction point and capturing a dated screenshot or form export as evidence.

Notice text that does not match processing

The most common finding is a notice that describes purposes and data categories the system no longer uses, or omits processing added by an integration, analytics tool or vendor. Compare the notice line by line against the data inventory, the authority recorded under PT-2 and the purposes recorded under PT-3. Close it by reconciling the notice with the inventory and assigning one owner to sign off each change.

No defined review frequency

PT-5 expects notices to be available at a defined frequency after first interaction, and an organization that has not set that frequency cannot show it is met. Many programs review notices only when someone remembers, so the notice drifts while the systems underneath it change. Ask who owns the notice, what cycle they committed to in policy and whether the last review date is recorded anywhere an assessor can see. Close it by writing the review frequency into the PT policy and logging each review.

Missing Privacy Act statements

In the privacy baseline, the PT-5(2) enhancement adds Privacy Act statements to the notice requirement. Programs that collect personal information through forms, web applications or paper often publish a general privacy policy but never create the statement at the point of collection. Inventory every collection instrument that stores data in a system of records, then check whether each one shows the statement the Privacy Act requires. Close it by attaching a statement to each collection instrument and confirming the wording with privacy counsel.

No change trigger for new processing

A notice stays accurate only if adding a new processing activity forces a notice update before the activity goes live. Without a trigger, new analytics tools, data sharing with a new processor or a changed retention rule can start while the public notice still describes the old design. Check whether change requests, procurement reviews and architecture approvals ask whether PII processing is changing. Close it by adding a privacy notice check to the change process so no new processing starts until the notice is updated.

PT-5 privacy notice questions buyers ask

What drives the effort of a PT-5 privacy notice program?

The effort is driven mainly by how many processing activities the notice must cover and how many places individuals first interact with the organization. PT-5 expects notice to be available at first interaction and again at a defined frequency, so each channel that collects PII (web forms, apps, call scripts, paper intake) adds work. The notice must also state the authority for processing and the purposes, which means the organization first needs an accurate inventory and a documented basis for each activity. Where PT-2 and PT-3 are already mature, the notice is largely a translation exercise. Where they are not, the notice work expands into discovery. Ask any provider to scope the channels and processing activities in writing before quoting.

Can our team write and maintain a PT-5 notice in-house?

Often yes, provided the team has access to the people who know the processing. The organization owns the notice, its accuracy and its approval, and no outside party can make those decisions for it. Writing the text is usually the smaller task. The harder parts are confirming the legal authority, keeping purposes consistent with what systems actually do, and updating the notice when products change. A reasonable test is whether one named owner can trace every statement in the notice to a documented processing activity and a system that performs it. If that traceability does not exist, an implementation partner can help build it, while the organization keeps approval. DeployOpen can prepare documentation and evidence for an assessment, but it does not write legal positions on the organization's behalf or certify the result.

What does a PT-5 notice need from legal and product teams?

Legal staff confirm the authority and the wording of the processing basis, check that the notice is accurate against applicable law, and approve changes. Product and user experience teams decide where and when the notice appears, how it reads on each screen and whether it is in plain language for the intended audience. SP 800-53A assesses PT-5 partly by interviewing personnel with user interface or user experience responsibilities, so product owners should be able to explain how notice is delivered. Engineering contributes by making notice placement, versioning and re-presentation testable. A short written RACI that names these roles, with a change process for new features, usually prevents the most common failure, where a product change alters processing and the notice is not updated.

How long does it take to put a PT-5 notice program in place?

The duration depends on the number of processing activities, the number of user-facing channels and how much of the PT-2 and PT-3 groundwork already exists. No researched timeline applies to PT-5 in general, so treat any single number from a vendor as an estimate that needs a scope behind it. Ask for the phases in writing: channel inventory, notice drafting and legal review, technical placement and testing, evidence collection and a review cycle. Also confirm which approvals sit on the critical path, since legal sign-off is frequently the longest step. For a fixed-scope engagement, DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the timeline should come from that document.

Does NIST set the cost or timeline for PT-5 compliance?

No. NIST publishes the control, its baseline placement and assessment procedures, but it does not estimate compliance or certification costs and does not set implementation timelines. For federal systems, timelines are left to OMB Circular A-130, and under FISMA, Inspectors General independently assess agency system security. PT-5 is in the privacy baseline, which applies regardless of impact level, so the requirement itself does not vary by system category. Cost and duration therefore depend on your processing footprint, your existing privacy program and the assessment regime that applies to you. Ask your regulator, contract or assessor which evidence they expect, then price the work against that list.

What does DeployOpen do for PT-5 and what does the auditor do?

DeployOpen prepares systems, documentation and evidence that support a PT-5 assessment, such as channel configuration, notice versioning and records of where notice is shown. The organization keeps ownership of its controls, its legal position and its notice text. An independent assessor or auditor examines the evidence, tests the controls and issues any report or conclusion. DeployOpen does not issue audit reports, attestations or certifications. Before engaging anyone, confirm in writing which deliverables are preparation work and which outputs, if any, come from an independent party.

Which open-source tools can keep PT-5 notice evidence current?

Two categories help. A wiki with version control records each change to the notice, who made it and when, and lets reviewers compare versions and roll back, which supports the evidence an assessor will examine. XWiki, which is licensed under LGPL-2.1-or-later, provides this per-page history. A documentation platform with role-based permissions lets the legal owner approve and product owners edit without giving everyone publish rights. BookStack, licensed under MIT, assigns abilities through roles and allows permissions to be overridden at shelf, book, chapter or page level. Confirm with each vendor that the features you need exist in the version you deploy, and keep approval records outside the tool if your assessor requires them.

How DeployOpen prepares PT-5 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so privacy notice content, its delivery points and its evidence trail are set up where the client controls them. The organization owns its privacy notices and its PT-5 determination, and only an independent assessor can issue an assessment result.

How we scope

  • The written scope lists which systems process PII and which notice touchpoints must be covered for PT-5.
  • We agree in writing which notice content is in scope, including the processing authority and purposes named in the notice.
  • Engagements are fixed-scope, and ongoing support for notice review is available as a retainer.

How we build

  • We configure the self-hosted platforms so privacy notices appear at the first point of interaction with individuals.
  • We set up a versioned repository for notice text, so each revision records what changed, when and by whom.
  • We configure role-based permissions so only designated owners can edit or publish privacy notice content.

How we test

  • We walk through the notice delivery paths with the client to confirm availability at first interaction and at the defined frequency.
  • We check that notice wording maps to the authority and purposes recorded under PT-2 and PT-3.
  • We document test results so assessors can examine the notice, its delivery mechanism and the process behind it.

How we hand over

  • We deliver the notice inventory, delivery configuration notes, version history and test records as client-owned documents.
  • We provide a PT-5 evidence index that maps each assessment object to the artifact that shows it.
  • We confirm with the client which items the independent assessor will need, and the assessor decides what is sufficient.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.