NIST SP 800-53 PT PII Processing and Transparency: Key Controls, Enhancements and How to Evidence Them

Privacy control findings rarely come from a missing notice; they come from systems that process personal data for purposes nobody wrote down, under an authority nobody checked, through pipelines nobody watches for change. This guide works through the PII Processing and Transparency (PT) family of NIST SP 800-53 Rev. 5 control by control: what each control and enhancement requires, which sit in the privacy baseline, which organisation-defined parameters you must set, and what evidence an assessor will ask for. It is written for privacy officers, system owners, security plan authors and assessors. For where PT sits in system categorisation, see the NIST SP 800-53 Privacy Controls and FIPS 199/200 Categorisation Guide; for a programme-level view, see the NIST Privacy Framework 1.1 Guide. This page goes deeper into the PT controls and their evidence.

Key takeaways

• PT is a privacy baseline family. All eight base controls are allocated to the SP 800-53B privacy baseline and to none of the Low, Moderate or High security baselines. The privacy baseline applies to systems irrespective of impact level, so it is triggered by PII processing, not by the security category.
• PT-2 and PT-3 are the foundation. Document the authority that permits each processing activity and the purpose of each, restrict processing to what is authorised and compatible, and monitor changes. Every other PT control depends on these two records.
• PT-3d is the control most often missed. It requires mechanisms to make sure changes in PII processing follow your requirements. New analytics, logging and AI features change processing without anyone filing a privacy review.
• Several controls are US federal specific. PT-5(2) Privacy Act statements, PT-6 system of records notices and PT-8 computer matching implement US law. Other organisations usually tailor them out and document why.
• Machine processing counts. Service accounts, ETL jobs, AI agents and third-party API integrations process PII too. Their access and purpose belong in the PT-2 and PT-3 records.

The PT family at a glance

The table lists the PT base controls with their baseline allocation and the enhancements selected in the privacy baseline, taken from NIST's OSCAL Release 5.2.0 catalogue and baseline profiles (P = Privacy baseline). No PT control appears in the Low, Moderate or High security baselines.

PT works with controls in other families that the privacy baseline also selects, notably RA-8 Privacy Impact Assessments, IR-8(1) Breaches and IR-2(3) Breach training. SP 800-171 Rev. 3 has no PT family, so contractors handling CUI meet PT obligations only where a contract or law brings them in. For tailoring method, see the NIST SP 800-53B Control Baselines and Tailoring Guide.

PT-1 and PT-2: policy and authority to process

• PT-1 Policy and Procedures: a PII processing and transparency policy at the level you select, procedures to implement it, a designated official, and review at a frequency and after events you define. Name the events: a new law or regulator guidance, a new category of PII, a significant incident.
• PT-2 Authority to Process: (a) determine and document the authority that permits the processing of PII, with both the authority and the processing as parameters you define; (b) restrict processing to only what is authorised. For federal agencies the authority is a statute, executive order or regulation. For other organisations the nearest equivalent is the legal basis under the privacy law that applies, such as a lawful basis under UK GDPR or EU GDPR.
• PT-2(1) Data Tagging and PT-2(2) Automation: tailoring candidates that attach authorised processing to the data itself and use automated mechanisms to manage enforcement. Classification labels, attribute-based access control and policy engines that evaluate a processing tag at query time are the usual routes.

The PT-2 record must cover every processing activity, including those carried out by machines. A service account with read access to a customer table is a processing activity. List it, tie it to an authority and a purpose, and restrict its access to what that purpose needs. See the Data flow mapping for security and privacy.

PT-3: purposes and change control

PT-3 has four parts: (a) identify and document the purposes for processing PII; (b) describe them in public privacy notices and policies; (c) restrict processing to what is compatible with those purposes; (d) monitor changes in processing and implement mechanisms you define so that changes follow requirements you define.

PT-3d is where modern systems slip. Log pipelines that capture request bodies, observability tools that store user identifiers, and AI features that send records to an external model all change processing. Make "does this change what PII we process or why" a mandatory field in change requests and architecture reviews, and scan data stores for PII that has appeared outside the inventory. See the AI and Privacy Guide.

PT-4 and PT-5: consent and notice

• PT-4 Consent: implement tools or mechanisms for individuals to consent to processing before collection that support informed decisions. PT-4 applies where consent is the basis for processing; where another authority applies, record that and why consent is not used. PT-4(1) tailors consent to specific elements or purposes, PT-4(2) asks for consent at the point of collection or use, and PT-4(3) lets individuals revoke consent.
• PT-5 Privacy Notice: notice available on first interaction and then at a frequency you define, in plain language, identifying the authority and the purposes, and including information you define. PT-5(1) Just-in-time Notice, a tailoring candidate, gives notice at the point of collection. PT-5(2), in the privacy baseline, adds Privacy Act statements on forms that collect information for a Privacy Act system of records.

Evidence for PT-4 and PT-5 is about traceability. An assessor will pick a collection point and ask for the consent or notice shown there, the version in force at the time, and the record of the individual's choice. For consent records in identity systems, see the Identity Data Privacy and Consent Guide.

PT-6, PT-7 and PT-8: Privacy Act and specific categories

• PT-6 System of Records Notice: for information maintained in a Privacy Act system of records, draft notices following OMB guidance, submit new and significantly modified notices to OMB and the appropriate congressional committees for advance review, publish them in the Federal Register and keep them accurate. PT-6(1) reviews routine uses and PT-6(2) reviews claimed exemptions, each at a frequency you define. Both are in the privacy baseline.
• PT-7 Specific Categories of PII: apply processing conditions you define for specific categories of PII. PT-7(1) for Social Security numbers requires eliminating unnecessary collection and exploring alternatives, not denying a right or benefit for refusal to disclose, and telling individuals whether disclosure is mandatory, under what authority and for what use. PT-7(2) prohibits processing information on how individuals exercise First Amendment rights unless authorised by statute or by the individual, or within the scope of authorised law enforcement activity.
• PT-8 Computer Matching Requirements: for matching programmes, obtain Data Integrity Board approval, enter a computer matching agreement, publish a matching notice in the Federal Register, independently verify information before adverse action where required, and give individuals notice and an opportunity to contest.

Outside the US federal context, PT-7's base control is still useful: set conditions for the categories your law treats as special, such as health, biometric and national identifier data, and for any category your risk assessment marks as sensitive. PT-6 and PT-8 are typically tailored out with a written rationale.

How to evidence PT controls

SP 800-53A Rev. 5 assessment procedures use examine, interview and test. The table turns them into evidence an assessor can accept in one pass.

For assessment depth, see the NIST SP 800-53A Guide.

Implementing the PT family: a phased approach

This sequence is NHI Mgmt Group's recommendation for a system that processes PII and has no structured privacy controls yet.

1. Decide applicability. Confirm with the privacy official that the system processes PII and record which PT controls apply and which are tailored out, with reasons.
2. Inventory processing. List PII elements, stores, flows and processing actors, human and machine, including third-party integrations and AI services.
3. Record authority and purpose. For each activity, write the PT-2 authority and PT-3 purpose and check compatibility of secondary uses.
4. Restrict access to purpose. Reduce human and service account access to what each purpose needs; this is where PT-2b and PT-3c become technical controls.
5. Align notices and consent. Update PT-5 notices to match the purpose record and test PT-4 consent and revocation end to end.
6. Install change triggers. Add privacy questions to change management, design review and procurement, and schedule PII discovery scans for PT-3d.
7. Review on a cycle. Re-run the inventory and record review at the PT-1 frequency and after every trigger event.

Test access reductions in a monitoring mode first: log which jobs would be denied before enforcing. Roll back by restoring the previous grant for the affected identity only, and record the exception against its purpose.

Decision guidance

• Federal versus non-federal: federal systems implement PT as written, including PT-6 and PT-8. Others keep PT-1 to PT-5 and PT-7 and translate "authority" into the legal basis under their own privacy law.
• Consent versus another basis: use PT-4 only where consent is the true basis. Asking for consent where processing would happen anyway misleads individuals and complicates revocation.
• Tagging and automation: PT-2(1), PT-2(2), PT-3(1) and PT-3(2) pay off where data sets are large and shared across many consumers. Small systems can meet the base controls with a maintained register.
• Small organisations: one record of processing with authority, purpose and access columns, linked to the notice, covers most of the base PT intent.

Detection and measurement

• Share of PII stores and processing actors in the inventory with a recorded authority and purpose.
• Share of changes affecting PII that had a privacy review before release.
• PII stores found by discovery scans that were not in the inventory, per quarter.
• Time from consent revocation to processing stopping, measured in tests.
• Days since each notice was last reviewed against the purpose record.

Framework mapping

CSF 2.0 is a cybersecurity framework and touches privacy mainly through GV.OC-03; the NIST Privacy Framework is the closer companion for PT. The ISO/IEC 27701 column names themes, not clause numbers, and is our reading. Check mappings against NIST's published informative references before using them in an audit. See the ISO/IEC 27701 Privacy Information Management Guide and the DPIA Guide: Running a Data Protection Impact Assessment.

Common failure patterns

• Notice as the whole programme: a public privacy notice exists, but no internal record ties it to actual processing.
• Machine processing invisible: service accounts and integrations read PII with no recorded purpose, so PT-2b and PT-3c cannot be shown.
• Purpose drift: data collected for one purpose is reused for analytics or model training without a compatibility decision.
• Consent not enforced: revocation updates a flag in one system while downstream copies keep processing.
• PII in logs: verbose logging captures identifiers and request bodies, creating a processing activity nobody approved.
• Federal controls copied blindly: non-federal organisations claim PT-6 and PT-8 with nothing behind them instead of tailoring them out.

Practitioner checklist

• Confirm the privacy baseline applies and record tailoring decisions for every PT control.
• Keep one record of processing with authority, purpose and processing actors, human and machine.
• Restrict service account and integration access to what each recorded purpose needs.
• Add a PII question to change management, design review and procurement for PT-3d.
• Scan data stores and log pipelines for PII outside the inventory.
• Version notices and consent text and keep records of individual choices.
• Test consent revocation end to end, including downstream copies.
• Set processing conditions for special categories and national identifiers under PT-7.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: OSCAL content, SP 800-53 Release 5.2.0 catalogue and baseline profiles
• NIST: SP 800-53B, Control Baselines for Information Systems and Organizations
• NIST: SP 800-53A Rev. 5, Assessing Security and Privacy Controls
• NIST: SP 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information
• US Department of Justice: Overview of the Privacy Act of 1974

Related NHI Mgmt Group resources: NIST SP 800-53 Guide · NIST SP 800-53 Privacy Controls and FIPS 199/200 Categorisation Guide · NIST Privacy Framework 1.1 Guide · DPIA Guide