PT-6: System of Records Notice

PT-6: System of Records Notice requirement means: if your system processes information that will be maintained in a Privacy Act “system of records,” you must ensure the required System of Records Notice (SORN) exists and that users/individuals receive appropriate notice tied to that system and data use. Operationalize it by identifying SORN-scoped data flows, mapping them to an active SORN, and maintaining evidence that notice is provided and kept current.

Key takeaways:

• PT-6 triggers only when your system processes data that will be maintained in a Privacy Act system of records ¹.
• Your fastest path is a tight mapping: system → SORN → user-facing notice points → recurring review evidence.
• Auditors will focus on traceability and currency: can you prove the SORN exists, applies, and is reflected in operational notices?

CCOs and GRC leads usually run into PT-6 late, after an Authority to Operate (ATO) package is already in motion or after a program office says, “This is a Privacy Act system of records.” PT-6 is narrower than general privacy notice expectations: it is about systems that handle information that will be maintained in a Privacy Act system of records, and it drives a specific operational outcome, notice that is anchored to an official System of Records Notice (SORN) ¹.

The practical work is less about drafting new privacy language and more about governance and traceability. You need a reliable decision on whether the system is in scope, a mapping to the correct SORN (or a documented gap/plan if a SORN is pending), and proof that your system’s collection points and user experiences match what the SORN says. Teams fail PT-6 most often because ownership is unclear (privacy vs. system owner vs. legal), or because they cannot produce artifacts that connect “this data field” to “this SORN” to “this notice shown to the individual.”

This page gives requirement-level steps you can execute quickly and defend in an assessment against NIST SP 800-53 expectations ².

Requirement overview (PT-6)

What PT-6 is asking for: For systems that process information that will be maintained in a Privacy Act system of records, the organization provides an appropriate system of records notice ¹.

Plain-English interpretation

• If the system collects, uses, or otherwise processes personal information that ends up in a Privacy Act “system of records,” you need to ensure the associated SORN exists and the system’s operational notices align to it.
• “Notice” is not a one-time PDF in a compliance folder. Examiners typically expect to see where notice is presented in the user journey (collection forms, portals, call scripts, intake workflows) and how it is kept current when the SORN or data practices change.

Regulatory text

Provided excerpt: “For systems that process information that will be maintained in a Privacy Act system of records:” ¹

What the operator must do with this excerpt

1. Make a scope determination: Decide whether the system processes information that will be maintained in a Privacy Act system of records. Document the decision and who approved it.
2. If in scope, tie the system to a SORN: Identify the specific SORN(s) that cover the system’s records and uses.
3. Implement notice in operations: Ensure individuals receive notice consistent with the SORN at or before collection and in any other required interaction points (for example, online account creation, application intake, helpdesk collection, API-based collection where a UI notice may not exist).
4. Prove it: Keep evidence that notice exists, is accurate, and is reviewed when the system changes.

(Note: PT-6 is a NIST SP 800-53 control. NIST provides control expectations; your agency/customer privacy office and program counsel typically define the SORN-specific content and publication workflow.) ²

Who it applies to

Entity scope

• Federal information systems where personal information is processed and maintained in a Privacy Act system of records ¹.
• Contractor systems handling federal data when the system processes information that will be maintained in a Privacy Act system of records ¹.

Operational contexts that commonly trigger PT-6

• Systems that support benefits, eligibility, enforcement, case management, HR, credentialing, or identity proofing where records are retrieved by personal identifier.
• Shared service platforms where the system is one component in a broader program system of records (you may still need system-specific notices, or a mapping that shows how the platform aligns to the program SORN).

Out-of-scope (common misreads)

• Systems that handle personal information but are not part of a Privacy Act system of records (you still have privacy obligations, but PT-6 specifically targets systems tied to a Privacy Act system of records) ¹.

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

Step 1: Assign ownership and decision rights

Create a simple RACI:

• Control owner: Privacy Officer / Privacy Program Manager
• System owner: Product/system owner accountable for implementation in the system
• Approvers: Agency privacy office (or contracting officer/program office for contractors), legal counsel as required
• Implementers: UX/content, engineering, service desk, forms team

Deliverable: PT-6 control record that names owners, review cadence, and evidence artifacts ¹.

Step 2: Determine whether the system is SORN-scoped

Run a short intake with three outputs:

• Data inventory extract: What personal data elements are processed.
• Recordkeeping destination: Where the “official record” is stored/maintained.
• Retrieval basis: Whether records are retrieved by personal identifier in a way consistent with a system of records.

Deliverable: “PT-6 Applicability Memo” stored with the SSP/privacy package.

Step 3: Map system data flows to SORN(s)

Build a mapping table that an auditor can read in minutes:

System function	Data elements	Where stored/maintained	Covered SORN name/ID	Notice point
Online intake	Name, SSN, address	Case system	[SORN reference]	Web form footer + just-in-time notice

Deliverable: SORN-to-system mapping matrix with version/date and owner sign-off.

Step 4: Implement notice at each collection channel

Cover every channel where data enters:

• Web/UI: Privacy notice link plus just-in-time notice at sensitive fields if applicable.
• Call center: Script language and a job aid for agents; confirm how script updates are controlled.
• Paper/PDF forms: Form-level notice text and version control.
• APIs/batch intake: Contractual or developer documentation notice; ensure the upstream collector provides notice consistent with the SORN.

Deliverable: “Notice implementation pack” (screenshots, scripts, form templates, developer docs excerpts).

Step 5: Align change management to notice and SORN currency

Tie PT-6 to your SDLC and change control:

• Add a privacy impact checkpoint for changes to data elements, purposes, disclosures, retention, or sharing.
• Require privacy review before release when changes touch SORN-scoped data.
• Track SORN updates and force a corresponding update to system notices.

Deliverable: Change ticket template fields (e.g., “SORN impact: Y/N; SORN ID; privacy approval”).

Step 6: Operationalize recurring evidence

Make PT-6 “audit-ready by default”:

• On a schedule, revalidate the mapping (system → SORN → notice points).
• Store dated evidence snapshots so you can prove what users saw at a point in time.

Daydream fit (earned mention): many teams implement PT-6 once, then fail it later because evidence is scattered across UX tools, ticketing, and SharePoint. Daydream can centralize the control owner, procedure, and recurring evidence artifacts so you can show assessors a single trace from requirement to implementation to proof ¹.

Required evidence and artifacts to retain

Keep artifacts that show scope, mapping, implementation, and upkeep:

• PT-6 applicability decision record (signed/approved).
• SORN reference(s) and internal mapping matrix that shows why they apply.
• Screenshots of notice in production (dated), plus URLs or app routes.
• Call scripts and training/job aids (dated versions).
• Form templates/PDFs with notice language (dated versions).
• SDLC/change tickets showing privacy review for SORN-impacting changes.
• Annual/periodic review record: who reviewed, what changed, what stayed the same.

Common exam/audit questions and hangups

Expect questions like:

• “Show me the SORN that covers this system and where the notice appears in the user workflow.”
• “Which data fields in the database are within the system of records, and how do you know?”
• “What happens when you add a new use case or integrate a new third party processor?”
• “Prove the notice was present in production before the feature launched.” Hangup: teams show a generic privacy policy, but cannot tie it to the SORN scope or to the actual collection experience.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating PT-6 as a one-time publication task.
   Fix: bind PT-6 to change control and keep dated evidence snapshots.

2. Mistake: No authoritative SORN mapping.
   Fix: require privacy office sign-off on the mapping matrix; store it with the SSP.

3. Mistake: Missing non-UI channels (call centers, batch files, APIs).
   Fix: inventory collection channels; assign a notice owner per channel.

4. Mistake: Contractor assumes agency handles everything.
   Fix: document shared responsibility. Even if the agency publishes the SORN, you still need system-level implementation evidence and operational notices where you collect data ¹.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied sources. Practically, PT-6 gaps show up as assessment findings, ATO delays, or contract noncompliance risk when your system is part of a federal program subject to Privacy Act obligations ².

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Name the PT-6 control owner and system owner; document RACI.
• Complete the PT-6 applicability memo.
• Inventory collection channels and data entry points.
• Draft the system-to-SORN mapping matrix (even if the SORN reference is pending; document the dependency).

By 60 days (implement and document)

• Implement or update notice at each collection channel.
• Add privacy/SORN impact fields to change tickets and release gates.
• Capture dated evidence: screenshots, scripts, forms, developer docs.
• Run a tabletop review with privacy + system owner: pick two workflows and trace data to SORN to notice.

By 90 days (operate and prove)

• Perform the first formal review cycle of the mapping matrix and notice pack.
• Test change management: introduce a controlled “data element change” in a ticket and validate approvals and evidence.
• Package artifacts for auditors: one folder or GRC record with scope decision, mapping, implementation proof, and review log.

Frequently Asked Questions

How do I know if my system is “maintained in a Privacy Act system of records”?

Treat it as a scope decision: identify where the official record is maintained and whether records are retrieved by personal identifier consistent with a system of records. Document the decision and get privacy office confirmation ¹.

If the agency publishes the SORN, what do I (as a contractor) still need to do?

You still need system-level implementation: map your system functions and data elements to the SORN, implement notice in your collection channels, and retain evidence for assessments ¹.

Is a generic privacy policy page enough to meet PT-6?

Usually no for audit purposes. Assessors expect traceability from the applicable SORN to the specific points where individuals provide data and see notice, with dated evidence that it’s in production.

What evidence is most persuasive in an assessment?

A signed applicability memo, a current system-to-SORN mapping matrix, and dated production screenshots (or captured UI flows) showing notice at collection points, plus change tickets showing privacy review.

We collect data via API with no end-user UI. How do we provide notice?

Put notice requirements into the upstream integration contract and developer documentation, and confirm the upstream collector provides notice consistent with the SORN. Retain the contract clause and the published documentation excerpt as evidence.

How should we handle product changes that add new data fields?

Add a required “SORN impact” check in your change workflow and block release until privacy reviews the change and confirms the notice/mapping updates are complete.

Footnotes

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

2. NIST SP 800-53 Rev. 5