Trackr.Live The landing site for Trackr Services
§ Trackr.Live

PT — PII Processing and Transparency

PT is the family that did not exist before Rev 5, and its arrival is the clearest signal of what changed when NIST renamed the catalog. The Rev 4 document was Security Controls. Rev 5 is Security and Privacy Controls for Information Systems and Organizations. Privacy stopped being an appendix and became a co-equal discipline inside the same catalog, and PT is where most of that move landed. If you are an ISSO who has spent your career in AC, AU, SC, and IA, PT is the family where you hand off to someone else: the privacy office, the Senior Agency Official for Privacy, the lawyers who own the SORN. Pretending otherwise, or burying PII handling inside an AC narrative because that is the muscle memory from Rev 4, is exactly the mental model that needs retiring.

A privacy notice rendered as a layered document, a flow of personal data fields passing a gate marked with a legal authority seal before entering a records system, a separate channel showing an individual being given a notice card.

PT is a control-catalog family from SP 800-53, not a step of the RMF. The RMF is still the SP 800-37 Rev 2 process: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. What changed in Rev 2 of 800-37 is that privacy got woven through every step and the SAOP got a defined role across them. PT controls enter at Select, get implemented and documented at Implement, and get graded at Assess, with privacy-program assessors often doing the grading rather than the security control assessor, and the results still landing in the SAR and POA&M like everything else.

Where PT came from

In Rev 4, the privacy controls lived in Appendix J, organized into their own families: Authority and Purpose (AP), Transparency (TR), Individual Participation (IP), Data Quality and Integrity (DI), Data Minimization and Retention (DM), Use Limitation (UL), Security (SE), and Accountability, Audit, and Risk Management (AR). Appendix J was withdrawn in Rev 5. Its content was folded into the main catalog so that privacy and security controls sit side by side instead of in separate books. Most of the transparency and processing-authority material consolidated into PT; the rest scattered into PM, SI, and the program-management space.

So the genealogy is worth tracing if you ever inherit an old SSP. Authority and Purpose became PT-2 and PT-3. Transparency became PT-5 and PT-6. Individual Participation, the right to consent, became PT-4. Use Limitation, the idea that you bind processing to a stated purpose, folded back into PT-2 and PT-3. If a system security plan or a control citation still references AP-1 or TR-2 or UL by number, that is a Rev 4 artifact nobody retired, and a standalone “Transparency family” page anywhere is now a legacy document. The families don’t exist anymore. The obligations do.

Ownership is the other thing that makes PT different from every family around it. The SAOP and the privacy program own these controls, not the ISSO. The artifacts PT demands come from privacy and legal: the privacy notice, the Privacy Act statement, the System of Records Notice published in the Federal Register, the Privacy Impact Assessment that decides which PT controls even apply. A system engineer does not write a SORN. Knowing where that line sits saves wasted effort during Implement, because the narrative for half of PT is authored by people who have never opened your SSP.

What’s in the family

PT spans PT-1 through PT-8, and unlike AC, the whole range is live in Rev 5. There are no withdrawn PT controls to trip over, because the family is brand new.

  • PT-1, Policy and Procedures. The family -1. Org-level privacy policy and the procedures under it, owned at the privacy-program level. Same shape as every other -1, different office signing it.
  • PT-2, Authority to Process PII. You need legal authority to process personally identifiable information, and it has to trace to a statute, regulation, or executive mandate. No authority, no processing. This is the Privacy Act’s fingerprint on the catalog.
  • PT-3, PII Processing Purposes. Specify the purposes for which you process PII and bind the actual processing to those documented purposes. PT-2 says you may; PT-3 says only for what you wrote down.
  • PT-4, Consent. Mechanisms for individuals to consent to processing where consent is the basis, including tailored and just-in-time consent enhancements rather than one blanket checkbox at signup.
  • PT-5, Privacy Notice. The notice you give individuals about how their PII is handled. Its named enhancement, PT-5(2) Privacy Act Statements, is the 5 U.S.C. 552a(e)(3) statement that has to appear at the actual point of collection, on the form or web page where you ask for the data.
  • PT-6, System of Records Notice (SORN). When you maintain a system of records under the Privacy Act, you publish a SORN. PT-6(1) covers routine uses; PT-6(2) covers exemption rules.
  • PT-7, Specific Categories of PII. Heightened handling for sensitive categories, with PT-7(1) Social Security Numbers (collect and use fewer of them) and PT-7(2) information about how individuals exercise First Amendment rights.
  • PT-8, Computer Matching Requirements. If you run a computer matching program against another agency’s records, the Computer Matching and Privacy Protection Act requires a matching agreement and a Data Integrity Board. Narrow, but when it applies it is hard law.

Baselines, or rather, why PT doesn’t have them the way AC does

Here is the single most important way PT diverges from a security family, and the place where copying the AC page blindly would produce a wrong answer. PT controls are not allocated to the Low, Moderate, and High security baselines in SP 800-53B the way AC, AU, and SC are. FIPS 199 impact level does not pull PT into your control set.

What pulls PT in is whether the system creates, collects, uses, processes, stores, maintains, disseminates, discloses, or disposes of PII. That determination comes from the privacy program and, concretely, from a Privacy Impact Assessment. A Low-impact system that holds a roster of names and SSNs carries more PT obligation than a High-impact system that processes no PII at all. 800-53B does carry a privacy control baseline and marks privacy-related controls, but the trigger is “this system processes PII,” not “this system is High.” So the table below uses an “applies when” column instead of a “first live at Low/Moderate/High” column, because for PT the honest answer to “when does this control switch on” is a question about data, not impact.

Deeper: the PIA is the privacy analog to FIPS 199 categorization.
On the security side, you categorize with FIPS 199, the impact level drives a 800-53B baseline, and that baseline hands you a starting control set. PT selection works on a parallel track that runs on different fuel. The Privacy Impact Assessment, required by Section 208 of the E-Government Act of 2002 and operationalized by OMB Circular A-130, is the artifact that decides whether and which PT controls apply. The PIA asks what PII the system touches, under what authority, for what purpose, and what risks that creates for individuals. Its answers select the PT controls and shape their implementation the way an impact level selects AC enhancements. Which is why a stale PIA is so corrosive: when the PIA that drove control selection is three years old and the system has added a new data field since, the control set itself is now wrong, not just the documentation. The PIA is not paperwork that happens after selection. For privacy, it is selection.

Control Applies when What an assessor actually checks
PT-2 Any system processing PII Point to the documented legal authority, confirm it maps to the PII actually processed. New field, no new authority, finding.
PT-3 Any system processing PII Purpose specification exists; observed processing matches it, not some broader internal reuse nobody wrote down.
PT-4 Where consent is the processing basis A real consent mechanism exists, and it maps to an actual processing limitation rather than a checkbox that changes nothing.
PT-5 Any system collecting PII from individuals Privacy notice is published and reachable by the individuals it concerns.
PT-5(2) Federal collection under the Privacy Act The 552a(e)(3) statement is present at the real collection point, sampled against the actual forms, not assumed.
PT-6 Federal system of records A current SORN covers the records as operated; check Federal Register publication and the routine uses.
PT-7(1) System uses SSNs SSN collection and use is justified and minimized, with a reduction rationale.
PT-8 Computer matching occurs Matching agreement and Data Integrity Board review are in place.

The legal spine under all of this is older than the catalog. The Privacy Act of 1974 (5 U.S.C. 552a) drives PT-2 authority, the PT-5(2) statement, the PT-6 SORN, and PT-8 matching. OMB Circular A-130, Managing Information as a Strategic Resource, stands up the privacy program, mandates the PIA, and defines the SAOP role. The E-Government Act Section 208 is where the PIA requirement originates. PT is NIST translating decades of privacy statute into control language the RMF can assess.

Where it goes brittle

The SORN is the artifact most likely to be out of date on any given system, and PT-6 is where that shows. A system of records drifts: a new data element gets added, a new routine use starts (some downstream agency now gets a feed), the legal basis shifts. The published SORN in the Federal Register describes the system as it was at publication, which might be 2016. An assessor pulls the current SORN and reads it against the records as operated, and the gap is right there. Amending a SORN is slow and involves Federal Register publication, so the incentive to quietly skip it is real, and that is exactly why it gets checked.

Authority drift is the PT-2/PT-3 version of the same disease. The system starts collecting one more field for one more purpose. Nobody re-runs the authority question. Nobody updates the purpose specification. The PIA and the SORN still describe the old, narrower scope. By the time an assessor maps the database schema against the documented purpose, the system is processing data it never established authority to process, which is not a documentation problem. It is a legal one.

The Privacy Act statement under PT-5(2) fails in a dull, physical way: it is missing from the form. The web page that collects the PII has no 552a(e)(3) statement on it, or it carries boilerplate copied from a different system that names the wrong authority and the wrong routine uses. Assessors sample the actual collection points. A privacy notice posted somewhere on the site does not satisfy PT-5(2) if the statement is not at the point of collection.

SSN over-collection under PT-7(1) has a policy tailwind behind it. OMB has pushed agencies to reduce and eliminate unnecessary SSN use for years, so an assessor looking at a system that uses the SSN as a primary key or collects it “just in case” will ask for the minimization justification, and “we always have” is not one.

And consent theater under PT-4: a checkbox that gates nothing. The user clicks “I agree,” the processing is identical to what would happen if they hadn’t, and no limitation is wired to the consent state. A narrative describing a mechanism that constrains nothing.

How PT connects to the rest of the catalog

PT specifies whether and why you may process PII and what individuals are told. It does not, by itself, protect the data, and an assessment that treats PT as self-contained misses half the picture. The PII inventory lives in PM, specifically PM-5(1). Data minimization, de-identification, and disposal moved into SI-12 enhancements. Role-based privacy training is AT-3. Confidentiality at the boundary leans on AC-21 information sharing and AC-22 publicly accessible content, plus SC and MP for protection in transit and at rest. Breach handling rides IR; logging of PII access rides AU. PT is the policy and transparency layer; the enforcement is spread across other families.

I’ll plant a flag here, and this is the one I’ll defend: on most federal systems the PT narratives are the thinnest in the SSP, and folding Appendix J into the main catalog is part of why. The Appendix J separation made privacy a bolt-on, which was bad. But the cure traded one problem for another. Privacy controls now compete for attention inside an assessment whose center of gravity is security, run on a calendar set by security, often staffed by a privacy office a fraction of the size of the security shop. The result is predictable: PT controls get the least-specific narratives, the SORN is the document most likely to be stale, and the PIA most likely to have outlived the system it describes. Co-equal in the catalog title does not mean co-equal in practice, and the org chart usually tells you which one wins when time runs short.

If your PT narratives read like the Privacy Act paraphrased back at the assessor, they will come back Other Than Satisfied for the same reason a generic AC narrative does. The assessor has read 552a. What they want to know is what this system collects, under what authority, told to whom, and whether the SORN on file actually covers it.

Sources

Adjacent material on this site