PT-5: Privacy Notice

PT-5: Privacy Notice requires you to give individuals clear, accessible notice about how you process their personally identifiable information (PII), then prove the notice is accurate, current, and delivered at the right time and place in the user journey. Operationalize it by inventorying PII processing, drafting a system-specific notice, publishing it where collection occurs, and retaining evidence of versioning, approvals, and posting. ¹

Key takeaways:

• PT-5 is a control you operationalize at the “point of collection” and across material changes, not a one-time website posting. ¹
• Your fastest path to audit readiness is mapping PT-5 to an owner, a repeatable procedure, and recurring evidence artifacts. ¹
• Misalignment between actual data flows and what the notice says is the most common failure mode; fix the inventory first.

The pt-5: privacy notice requirement is straightforward in concept and easy to fail in practice: you must notify individuals about your PII processing in a way that matches reality and shows up where people actually provide their data. For federal information systems and contractor systems handling federal data, PT-5 sits at the intersection of privacy engineering, product delivery, and governance. ¹

CCOs and GRC leads often inherit privacy notices as “legal-owned website text.” PT-5 forces a tighter operational posture: the notice needs a control owner, an implementation procedure, and evidence that you maintain it as systems, forms, APIs, and third parties change. If your environment has multiple collection points (web forms, call centers, mobile apps, integrations), one generic notice is rarely enough for assessment purposes.

This page gives requirement-level implementation guidance you can execute quickly: applicability, a step-by-step build, evidence to retain, common audit traps, and an execution plan that gets you to defensible operation without inventing process overhead.

Regulatory text

Excerpt (control requirement): “Provide notice to individuals about the processing of personally identifiable information that:” ¹

Operator interpretation: PT-5 requires a privacy notice program that (a) communicates PII processing to individuals and (b) is implemented where PII is collected or otherwise processed in a way that affects individuals. The excerpt in your source is truncated, so treat PT-5 as a requirement to provide meaningful notice about processing, and design your implementation so an assessor can trace: data flow → notice content → delivery mechanism → approvals/versioning → ongoing updates. ¹

What an assessor will look for: a published notice, evidence it’s presented in the right channels, and proof the notice aligns to actual PII handling in the system boundary. ²

Plain-English requirement (what PT-5 really demands)

You need a reliable way to tell individuals:

• What PII you process (categories of data)
• Why you process it (purposes tied to services/operations)
• How it’s processed and shared (including key third parties where relevant)
• How long you keep it (at least retention logic, even if expressed at a high level)
• What choices or rights exist (where your program supports them)
• How to contact you (privacy inbox or process)

Then you must keep the notice current as processing changes. If your notice says you don’t share PII, but your integrations send identifiers to an analytics provider, PT-5 fails operationally even if the notice exists.

Who it applies to

Entity types in scope:

• Federal information systems
• Contractor systems handling federal data ¹

Operational contexts where PT-5 becomes “real work”:

• Public-facing web properties collecting PII (forms, registrations, support tickets)
• Authenticated applications (portals, SaaS, mobile apps) that profile users or store identity attributes
• HR, benefits, and applicant tracking processes (employee/applicant PII)
• Call center scripts and CRM intake
• API-based collection where your customer collects data and transmits it to you
• Third-party enabled processing (payment processors, identity providers, analytics, support tooling)

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

Step 1: Assign ownership and define the control procedure

1. Name a control owner (often Privacy Officer, CISO/GRC, or Legal with operational delegation).
2. Write a one-page PT-5 operating procedure that states:
   • where notices must appear,
   • who approves changes,
   • what triggers an update,
   • how often you review for accuracy,
   • what evidence you retain.

This mapping of PT-5 to owner, procedure, and recurring evidence is explicitly recommended as a practical control approach. ¹

Step 2: Build (or refresh) a PII processing inventory tied to the system boundary

Your notice cannot be accurate if you can’t describe processing.

1. List PII elements processed (direct identifiers, contact info, government IDs if applicable, device IDs, etc.).
2. Document processing purposes per system feature/process.
3. Document data sources (provided by individual, generated by system, received from third party).
4. Document disclosures/recipients (internal teams, third parties, inter-agency transfers if applicable).
5. Document retention drivers (record schedules, contract requirements, operational needs).

Keep this inventory scoped to the assessed system boundary so PT-5 is testable.

Step 3: Draft system-specific privacy notice content

Create a notice that mirrors the inventory. Practical drafting rules that reduce audit friction:

• Use plain language and short sections.
• Use tables for “data category → purpose → sharing.”
• Avoid absolute statements (“we never share”) unless the inventory proves it.
• Add a “Last updated” field and a version identifier for evidence.

If you have multiple products or collection contexts, maintain a “base notice” plus context-specific addenda (for example: recruiting notice, customer app notice).

Step 4: Implement notice delivery at the right collection points

Map each PII collection channel to a delivery method:

Collection point	Minimum PT-5 delivery expectation	Evidence to retain
Web form	Link to notice next to submit, or inline summary with link	Screenshot, HTML snippet, release ticket
Mobile app	In-app settings + link at signup or first collection	Screen captures, build notes
Call center	Script reference + follow-up link	Script version, training record
API intake	Developer docs + contractual notice obligations	API docs version, contract clause

The goal is traceability: “individual gives PII here” → “they can access notice here.”

Step 5: Add change triggers and review cadence to your SDLC and third-party processes

PT-5 breaks when systems change. Add explicit triggers:

• New PII field added to a form or profile
• New use case/purpose (for example, fraud monitoring, analytics expansion)
• New third party receiving PII
• Retention policy change
• Material UI change that relocates collection or notices

Implement the trigger as:

• a privacy checkpoint in product intake,
• a required question in change requests,
• a procurement intake step for third parties that process PII.

Step 6: Establish versioning, approvals, and publication controls

Minimum governance that holds up in an assessment:

• Approval workflow (Privacy + Legal + Product owner as applicable)
• Version control (repo, GRC tool, or controlled document store)
• Publication control (who can post changes; how you roll back)
• Archive older versions with effective dates

Step 7: Monitor for drift (your notice vs reality)

Run periodic checks:

• Compare PII inventory to production fields and event tracking specs.
• Sample third-party integrations for actual transmitted fields.
• Confirm links are live, readable, and accessible.

This is where teams usually find “silent expansions” in analytics, support tooling, or logs.

Required evidence and artifacts to retain

Retain artifacts that prove both design and operating effectiveness:

Core artifacts

• PT-5 control statement mapped to an owner and procedure ¹
• System-specific privacy notice (current) and prior versions with effective dates
• Approval records (tickets, sign-offs, document history)
• PII processing inventory aligned to the system boundary
• Publication evidence: screenshots, URLs, app store build notes, release artifacts
• Change trigger evidence: completed privacy review checklists for relevant releases
• Training/script evidence for non-digital channels (call center, in-person intake)

Nice-to-have artifacts (reduce back-and-forth)

• Crosswalk: inventory rows mapped to notice sections
• Evidence that third-party sharing statements match contracts and configurations

Common exam/audit questions and hangups

Expect these lines of inquiry:

• “Show me where an individual sees the notice at the time they provide PII.”
• “How do you know the notice matches what the system actually collects and shares?”
• “What triggers an update to the notice?”
• “Who approves changes, and where is version history?”
• “Does your notice cover third-party processing that is in scope for this system?”

Typical hangup: the notice exists, but you cannot prove it was presented at collection points beyond a footer link, or you can’t tie it to an up-to-date inventory.

Frequent implementation mistakes (and how to avoid them)

1. Copying a generic corporate privacy policy into a system assessment package.
   Fix: create a system addendum keyed to the assessed system boundary and data flows.

2. Writing absolute sharing statements that engineering can’t sustain.
   Fix: use qualified language that mirrors your integration reality and update triggers.

3. No evidence trail.
   Fix: keep screenshots, approvals, and version history as routine artifacts, not scramble work.

4. Not covering non-web collection.
   Fix: add call scripts, PDFs, kiosks, and API docs into your “notice delivery map.”

5. Third-party drift.
   Fix: link procurement intake to PT-5 so new processors trigger notice review.

Enforcement context and risk implications

Your provided source catalog includes no public enforcement cases for PT-5, so focus on assessment and operational risk: inaccurate or missing notices create avoidable findings, force rapid rework during authorization or customer audits, and increase the chance that privacy promises conflict with actual processing. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Assign PT-5 owner and publish the PT-5 operating procedure. ¹
• Identify all PII collection points for the in-scope system(s).
• Build the first-pass PII inventory and list third parties receiving PII.
• Decide the notice structure (base notice + addenda vs system-specific notice).

By 60 days (publish and instrument)

• Draft and approve the notice text from the inventory.
• Implement delivery at each collection point (web, app, call, API docs).
• Add change triggers to your SDLC (intake questions, release checklist).
• Set up versioning and an evidence folder structure (or a GRC workflow).

By 90 days (operate and prove)

• Run a drift check: compare inventory vs actual fields/events and third-party transmissions.
• Close gaps: update notice, fix placements, correct sharing language.
• Package evidence for assessment: current notice, prior versions, approvals, screenshots, trigger records.
• If you manage many systems, standardize templates and track PT-5 status centrally in Daydream so owners can attach recurring evidence artifacts to each system’s PT-5 record. ¹

Frequently Asked Questions

Do I need a separate privacy notice for every system?

PT-5 expects notice that matches the actual PII processing in scope. If one enterprise notice accurately covers the system and is presented at the collection points, you can use it, but most teams end up needing system addenda for accuracy and audit traceability. ¹

Where exactly should the notice appear on a web form?

Place it where the individual submits PII, not only in a global footer. A short statement plus a direct link near the submit action is easiest to defend because it ties notice delivery to collection.

What counts as evidence that the notice was provided?

Keep screenshots (or screen recordings) showing placement at collection points, plus the approved notice version and publication record (ticket or release note). Pair this with the PII inventory used to draft the notice.

How do we handle third parties in the notice?

Your notice should reflect that you share PII with third parties for defined purposes when that is true for the system. The operational control is to trigger notice review when procurement adds a new PII-processing third party.

What triggers a required notice update?

Treat any material change in PII categories, processing purposes, sharing recipients, or retention approach as a trigger. Add those triggers to change management so updates happen before the change goes live.

How does Daydream help with PT-5 execution?

Daydream is most useful as the system of record for control ownership, the PT-5 procedure, and recurring evidence artifacts (approved notice versions, screenshots, and review tickets) so you can show consistent operation across multiple systems. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5