Privacy used to be an appendix in NIST SP 800-53. In Rev. 4, privacy controls sat in a separate catalog at the back, with their own family identifiers, and security teams could read the whole publication without meeting them. Rev. 5 ended that. Privacy controls now live in the main catalog, and many controls are written to serve security and privacy at once.
For anyone implementing 800-53, that changes ownership as much as content. A control such as AU-3 now has a privacy enhancement, so your logging engineers are doing privacy work whether they know it or not. This article covers what Rev. 5 changed, the PII Processing and Transparency family, the privacy controls in other families, and how to divide the work between security and privacy owners.
What Rev. 5 changed for privacy
Three changes matter.
Integration. Privacy controls are part of the single catalog. A control may serve security, privacy, or both, and many familiar security controls now carry privacy enhancements.
A dedicated family. PII Processing and Transparency (PT) collects the controls about the lawful and transparent handling of personally identifiable information.
A privacy baseline. NIST SP 800-53B defines a privacy baseline for systems that process PII. It applies whatever the security impact level, and it is selected alongside the Low, Moderate, or High security baseline.
Rev. 5 also says plainly that security and privacy programs are separate disciplines that must collaborate. In federal agencies, privacy responsibilities sit with the senior agency official for privacy. In a company, the equivalent is whoever owns your privacy program, and that person should own these controls, not inherit them by accident from the security team.
The PT family, control by control
The PT family is short. Each control answers one question about a system's handling of PII.
PT-1, Policy and Procedures. The documented policy for PII processing and transparency, like the first control in every family.
PT-2, Authority to Process PII. Identify the legal authority that permits the processing, and restrict processing to what that authority allows.
PT-3, PII Processing Purposes. Identify and document the purposes for processing, describe them in notices, and restrict processing to compatible purposes. Changes in purpose need review.
PT-4, Consent. Provide means for individuals to consent to processing, where consent is the mechanism, before the processing happens.
PT-5, Privacy Notice. Give individuals a notice that is available when they first interact with the system, plain in language, and specific about what is processed and why.
PT-6, System of Records Notice. Publish system of records notices as the Privacy Act of 1974 requires. This is a federal agency obligation.
PT-7, Specific Categories of PII. Apply additional conditions to sensitive categories, with enhancements covering Social Security numbers and information about how individuals exercise First Amendment rights.
PT-8, Computer Matching Requirements. Meet the federal requirements for computer matching programs, another agency obligation.
Read that list and the structure is clear. PT-2 and PT-3 are about whether the processing should happen at all. PT-4 and PT-5 are about whether individuals know and agree. PT-6 to PT-8 are largely federal statutory duties that a contractor supports rather than owns.
Privacy controls outside the PT family
The PT family is the smaller part of the story. Rev. 5 places privacy requirements throughout the catalog, often as enhancements to familiar security controls. Some that teams most often miss:
| Control | What it asks for |
|---|---|
| PM-5(1) | An inventory of PII: where it is, in which systems, and what it is |
| PM-18 | A privacy program plan, the privacy equivalent of the security program plan |
| RA-8 | Privacy impact assessments, before developing or procuring systems that process PII and before new collections |
| AU-3(3) | Limiting the PII elements recorded in audit records to what is needed |
| IR-8(1) | Breach handling as part of the incident response plan, including notification decisions |
| SI-12(1) | Limiting the PII elements processed to what the purpose requires |
| SI-19 | De-identification of data sets, with methods and validation |
This is not an exhaustive list. The privacy baseline in 800-53B draws on controls from many families, and the exact selection should be read from the publication itself rather than from a summary.
The audit record enhancement deserves particular attention. Logging pipelines collect whatever applications emit, and applications emit names, email addresses, and sometimes far worse. A security team optimizing for investigation will log everything. AU-3(3) asks someone to decide what PII the logs genuinely need, and to stop collecting the rest.
Who owns what
Joint controls fail when each side assumes the other has them. A workable split looks like this:
Privacy owns the decisions. Authority to process, purposes, notices, consent, the PII inventory, and privacy impact assessments.
Security and engineering own the mechanisms. Access to PII, encryption, log minimization, de-identification tooling, and the technical side of breach detection.
Both own incident response. Security detects and contains. Privacy decides whether an incident is a breach involving PII and what notifications follow.
Write the split into your implementation statements. "Shared" is not an owner. For each privacy-relevant control, name the role responsible for the decision and the role responsible for the mechanism.
Applying the privacy controls outside government
Many organizations meet the privacy controls without being federal agencies. Contractors operating systems for agencies inherit them through their contracts. Commercial organizations adopt 800-53 as a reference catalog.
If you also work under GDPR, the concepts will look familiar. PT-3's purpose restriction echoes purpose limitation. PM-5(1)'s inventory resembles a record of processing activities. RA-8's privacy impact assessment resembles a data protection impact assessment, though the triggers differ, as our article on when a DPIA is required explains.
Resemblance is not equivalence. PT-2 asks for legal authority to process, which for a federal agency means a statute or regulation. GDPR asks for a lawful basis from a defined list. Consent under PT-4 and consent under GDPR carry different conditions. Reuse your artifacts where they fit, then check each against the specific text it is meant to satisfy. Where the question is what a law requires of you, confirm with counsel.
Common gaps in privacy control implementation
No PII inventory. Without PM-5(1), every other privacy control is guesswork, because nobody can say which systems are in scope.
Production PII in test environments. Copying production data into development or test is common and rarely justified. The catalog addresses minimization of PII used in testing, training, and research.
Notices that describe last year's system. PT-5 notices drift from reality as features ship. Tie notice review to change management.
Breach handling bolted onto incident response. If your incident plan has no step where someone decides whether PII was involved, IR-8(1) is not met.
Security owning privacy by default. If the person accountable for privacy decisions is a security engineer because nobody else was assigned, fix the assignment before the assessment.
Our NIST 800-53 framework page covers how the privacy baseline fits with the rest of the catalog.
How TrustLynce helps
TrustLynce runs record of processing, privacy impact assessment, and data subject request workflows alongside your 800-53 controls, so privacy evidence sits next to the controls it supports. See data privacy.