PT-5(2): Privacy Act Statements
To meet the pt-5(2): privacy act statements requirement, you must present a Privacy Act Statement whenever a form collects information that will be stored in a Privacy Act System of Records, either directly on the form or as a separate statement the individual can keep 1. Operationalize it by inventorying covered forms, standardizing statement content, implementing release controls, and retaining evidence that statements were provided at collection.
Key takeaways:
- Identify which data collections feed a Privacy Act System of Records and treat those forms as in-scope.
- Put the Privacy Act Statement on the form or provide a detachable/retainable statement at the point of collection.
- Keep durable evidence: form versions, screenshots, approval records, and sample completed packets showing the statement was provided.
PT-5(2) is a “front door” privacy control. If your organization collects personal data through forms and then maintains that data in a Privacy Act system of records, PT-5(2) requires you to give the individual a Privacy Act Statement at the moment you collect the information 1. This is operationally simple but easy to miss because forms proliferate: web intake pages, PDF packets, call-center scripts, HR onboarding tools, event registration, identity proofing flows, and third-party hosted collection pages.
For a CCO or GRC lead, the fastest path is to treat PT-5(2) as a controlled publishing problem: (1) decide which forms are in scope, (2) standardize statement language and ownership, (3) make sure the statement is presented in every channel where collection happens, and (4) retain evidence that the statement was present for each released version. Assessors usually fail teams on PT-5(2) for one of two reasons: the statement is missing on “one last” form, or the team cannot prove what was displayed at the time of collection.
Regulatory text
Requirement (excerpt): “Include Privacy Act statements on forms that collect information that will be maintained in a Privacy Act system of records, or provide Privacy Act statements on separate forms that can be retained by individuals.” 1
What the operator must do:
- Determine whether a given form collects information that will be maintained in a Privacy Act system of records.
- If yes, ensure the individual receives a Privacy Act Statement on the form (embedded in the UI/PDF) or via a separate statement that the individual can keep (for example, a printable page, detachable sheet, or downloadable notice) 1.
- Ensure this is true across all collection channels, including third-party hosted forms where you control the content.
Plain-English interpretation
If you collect personal information and your organization keeps it in a Privacy Act System of Records, you must tell the person what’s happening in a Privacy Act Statement at collection time. You can embed the statement in the form or provide it as a separate page the person can retain 1.
This control is about notice at collection plus proof you gave it. It is not satisfied by a general website privacy policy alone, because PT-5(2) is tied to specific forms and systems of records.
Who it applies to (entity and operational context)
PT-5(2) commonly applies in these contexts:
- Federal information systems that collect information from individuals and maintain it in a Privacy Act system of records.
- Contractor systems handling federal data where the contractor collects information on behalf of a federal agency and the information is maintained in a Privacy Act system of records 1.
Operationally, it applies to:
- Public-facing web forms (intake, registration, eligibility, service requests)
- Internal forms used for benefits, onboarding, or investigations if they feed a Privacy Act system of records
- Paper/PDF forms, including scanned submissions
- Call-center scripts where agents collect data verbally and enter it into a covered system
- Third-party form tools and SaaS workflows where your organization designs the questions and stores the responses
What you actually need to do (step-by-step)
1) Define “in-scope” with a tight decision rule
Create a short decision rule your teams can follow:
A form is in-scope for PT-5(2) if:
- It collects information about an individual; and
- The collected information will be maintained in a Privacy Act system of records 1.
Execution tip: Don’t debate edge cases in meetings. Put the rule in writing, then require the product/process owner to attest whether the destination system is a Privacy Act system of records.
2) Build an inventory of collection points (forms) and data destinations
Create a register with:
- Form name and channel (web/PDF/phone/in-person)
- Business owner
- System(s) where submissions are stored
- Whether the destination is a Privacy Act system of records
- Current presence of Privacy Act Statement (yes/no, where shown)
- Link or repository location to the source (CMS page, PDF, script doc)
This inventory becomes your audit backbone. It also prevents “one-off” forms from escaping governance.
3) Standardize the Privacy Act Statement package (content + formatting)
PT-5(2) does not prescribe the exact wording in the excerpt you have; it requires that the Privacy Act statement be included or provided in a retainable way 1. Operationally, standardize:
- A baseline statement template approved by privacy counsel/Privacy Office
- A short form-specific addendum field for the system/program name and any unique uses
- Display rules by channel:
- Web: above submit button, printable/downloadable
- PDF: on first page or signature page; include as detachable page if needed
- Phone/in-person: scripted read-out plus offer to provide written statement (email/mail/handout) the individual can keep
Practical control: Treat the statement text as controlled content (like a legal disclaimer). Changes require review and versioning.
4) Implement presentation controls per channel
Use a channel checklist:
Web forms
- Statement visible without requiring navigation away from the form (or provide a direct link to a printable statement the user can save).
- Capture a screenshot for evidence (see Evidence section).
PDF/paper
- Statement printed on the form or attached as a separate page.
- Ensure the “separate form that can be retained” is actually delivered with the packet 1.
Call-center
- Update the script and QA scorecards: agents must read a short notice and offer the retainable statement.
- Provide a standard mechanism to send the statement (email template, SMS link, or mailed insert).
Third-party forms
- Contractually require the third party to display the statement exactly as provided.
- Validate after deployment with screenshots from the live environment.
5) Put PT-5(2) into your release and change-management gates
Most PT-5(2) failures happen after redesigns. Add two gating questions to your change ticket:
- “Does this form collect information that is maintained in a Privacy Act system of records?”
- “If yes, where is the Privacy Act Statement shown or provided as retainable?” 1
If you use Daydream to manage control ownership and evidence expectations, map PT-5(2) to a named owner, a written procedure, and recurring evidence artifacts so teams stop reinventing the control each audit cycle 1.
Required evidence and artifacts to retain
Assessors generally want to see both design evidence (what you intended) and operational evidence (what was actually in production). Maintain:
- Form inventory (in-scope determination, owners, destinations)
- Approved Privacy Act Statement templates (version-controlled)
- Form artifacts by channel
- Web: dated screenshots of the statement on the page; archived release notes
- PDF: the exact PDF version distributed; packet assembly instructions
- Phone: script version, training record, QA checklist item
- Change-management records
- Tickets showing statement review/approval for new or changed forms
- Spot-check results
- Periodic sampling that confirms the statement is present post-release
Evidence quality rule: keep artifacts that show what an individual saw at collection time.
Common exam/audit questions and hangups
Expect these questions:
- “Show me all forms that feed a Privacy Act system of records and where the statement is displayed.” 1
- “How do you ensure new forms include the statement before production release?”
- “If the statement is separate, prove the individual can retain it.” 1
- “Who owns the statement language and who approves changes?”
- “What about third-party hosted collection pages?”
Hangups that trigger findings:
- Teams can show a template but cannot show the live UI/PDF used in practice.
- The statement exists, but it’s behind a link that isn’t retained or is not reliably presented at the time of submission.
- One neglected intake path (legacy PDF, conference signup, “temporary” spreadsheet form) is missing the statement.
Frequent implementation mistakes and how to avoid them
-
Mistake: Treating a website privacy policy as coverage for all forms.
Avoidance: PT-5(2) is form- and collection-specific. Tie each statement instance to a form and destination system 1. -
Mistake: No proof of what was displayed.
Avoidance: Archive screenshots/PDFs per release, not “current state only.” -
Mistake: Separate statement that people cannot retain in practice.
Avoidance: Make it downloadable/printable, or deliver a physical insert. Test the user path 1. -
Mistake: Third-party form tools drift from approved language.
Avoidance: Treat statement text as controlled content; verify after every vendor-side update.
Enforcement context and risk implications
No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement actions.
Risk-wise, PT-5(2) is a notice-at-collection control. Gaps create predictable issues: individuals claim they were not informed at collection, internal teams cannot show consistent notice across channels, and assessors see weak privacy governance over intake. The operational impact is usually audit findings, remediation work, and delayed authorizations rather than a single standalone penalty callout based on the data provided.
A practical 30/60/90-day execution plan
First 30 days (stabilize and scope)
- Assign a control owner for PT-5(2) and document the decision rule for in-scope forms 1.
- Build the initial inventory of forms and data destinations; flag anything feeding a Privacy Act system of records.
- Collect current-state evidence (screenshots/PDFs/scripts) before changes start.
By 60 days (standardize and remediate)
- Publish an approved Privacy Act Statement template and channel-specific implementation standards.
- Remediate high-traffic and high-risk forms first (public web intake, core program forms, call-center scripts).
- Add PT-5(2) checks to change-management and SDLC/intake workflows.
By 90 days (operationalize and make it auditable)
- Complete remediation across remaining forms, including “edge” channels (events, offline packets, third-party tools).
- Implement a recurring spot-check and evidence capture routine.
- In Daydream (or your GRC system), map PT-5(2) to the owner, procedure, and recurring evidence artifacts so audits become a pull, not a scramble 1.
Frequently Asked Questions
Does PT-5(2) require the Privacy Act Statement to be on the same page as the form?
No. The requirement allows the statement to be included on the form or provided on a separate form that the individual can retain 1. The operational test is whether the statement is actually provided at collection.
We collect data in a SaaS form tool. Are we still responsible?
Yes, if your process collects information that will be maintained in a Privacy Act system of records, you must ensure the statement is presented in that tool 1. Treat it as controlled content and verify it in production.
What’s the minimum evidence an assessor will accept?
Keep the released form versions (web screenshots or PDF copies) showing the statement and the approval/change records that tie those versions to a release. Add a small sampling log that proves ongoing operation.
What if the form collects data, but we don’t store it in a Privacy Act system of records?
PT-5(2) is triggered when the information “will be maintained in a Privacy Act system of records” 1. If it is out of scope, document the destination system and your rationale so you can defend the scoping decision.
Can the statement be a link?
The excerpt allows a separate statement that individuals can retain 1. If you use a link, make it reliably accessible at collection time and allow the individual to save/print it; keep evidence of the live experience.
Who should own PT-5(2): privacy or security?
Assign ownership to the team that governs privacy notices and form language, usually the Privacy Office with GRC support. Security and engineering should own the release gates that prevent forms from shipping without the statement.
Footnotes
Frequently Asked Questions
Does PT-5(2) require the Privacy Act Statement to be on the same page as the form?
No. The requirement allows the statement to be included on the form or provided on a separate form that the individual can retain (Source: NIST SP 800-53 Rev. 5 OSCAL JSON). The operational test is whether the statement is actually provided at collection.
We collect data in a SaaS form tool. Are we still responsible?
Yes, if your process collects information that will be maintained in a Privacy Act system of records, you must ensure the statement is presented in that tool (Source: NIST SP 800-53 Rev. 5 OSCAL JSON). Treat it as controlled content and verify it in production.
What’s the minimum evidence an assessor will accept?
Keep the released form versions (web screenshots or PDF copies) showing the statement and the approval/change records that tie those versions to a release. Add a small sampling log that proves ongoing operation.
What if the form collects data, but we don’t store it in a Privacy Act system of records?
PT-5(2) is triggered when the information “will be maintained in a Privacy Act system of records” (Source: NIST SP 800-53 Rev. 5 OSCAL JSON). If it is out of scope, document the destination system and your rationale so you can defend the scoping decision.
Can the statement be a link?
The excerpt allows a separate statement that individuals can retain (Source: NIST SP 800-53 Rev. 5 OSCAL JSON). If you use a link, make it reliably accessible at collection time and allow the individual to save/print it; keep evidence of the live experience.
Who should own PT-5(2): privacy or security?
Assign ownership to the team that governs privacy notices and form language, usually the Privacy Office with GRC support. Security and engineering should own the release gates that prevent forms from shipping without the statement.
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream