PT-2: Authority to Process Personally Identifiable Information

To meet the pt-2: authority to process personally identifiable information requirement, you must identify the specific legal or policy authority that allows your organization (and each covered system/workflow) to process PII, then document it in a way auditors can trace from each PII use back to that authority. This becomes the “permission slip” for PII processing across your environment.

Key takeaways:

• PT-2 is a documentation-and-traceability control: every PII processing purpose needs a clear stated authority and a record that links to it.
• Operationalize PT-2 by building a PII processing inventory mapped to authorities, owners, systems, third parties, and retention/disclosure rules.
• Evidence matters: assessors usually fail teams on PT-2 due to missing artifacts, unclear authority statements, or mappings that don’t cover real data flows.

PT-2 sits in NIST SP 800-53’s Privacy (PT) family and forces a basic discipline: you do not process personally identifiable information unless you can point to the authority that permits it, and you can prove you did that determination and documentation. In federal environments and contractor systems handling federal data, this usually means you must tie each PII processing activity to a defined authority (law, regulation, executive directive, contract, program mandate, or other formally established authorization).

For a Compliance Officer, CCO, or GRC lead, PT-2 becomes actionable when you translate it into three artifacts you can defend: (1) a written statement of the authority(ies) you rely on, (2) a mapping from each PII processing activity (collection, use, sharing, storage, disposal) to those authorities, and (3) governance that keeps the mapping current as systems and third parties change.

If you already run a privacy program, PT-2 often exposes gaps in operational traceability: teams “know” why PII is processed but cannot produce a clean, assessor-ready record that covers every system, every third party, and every purpose.

Regulatory text

NIST SP 800-53 PT-2 requires you to: “Determine and document the {{ insert: param, pt-02_odp.01 }} that permits the {{ insert: param, pt-02_odp.02 }} of personally identifiable information; and” ¹

Operator interpretation (what you must do):

• Determine the authority (the formal permission basis) that allows the processing of PII in your environment. This is a decision you can explain and defend.
• Document that authority so it is durable, reviewable, and traceable to actual systems and workflows that handle PII.
• Treat “authority” as something stronger than “business need.” Auditors expect a formal basis that can be cited and tied to governance decisions ².

Plain-English interpretation of PT-2

PT-2 means: for every meaningful way you process PII, you should be able to answer, in writing, “What authorizes us to do this?” Then you must show that this answer is not isolated in a policy binder, but connected to real operations: applications, logs, forms, APIs, data pipelines, case management, HR processes, and third-party services.

PT-2 is often tested as a readiness proxy. If you cannot state and map authority, your notice, consent, sharing, retention, and minimization controls tend to be inconsistent.

Who it applies to (entity and operational context)

PT-2 commonly applies in:

• Federal information systems and programs that process PII ².
• Contractor systems handling federal data, including SaaS and managed services where the contractor processes PII on behalf of an agency or under a federal contract ².

Operationally, PT-2 touches:

• System owners for any application with user, employee, customer, citizen, patient, or student identifiers.
• Privacy and legal for defining valid authorities and approving exceptions.
• Procurement / third-party risk when PII is processed by third parties (cloud, payroll, analytics, call centers).
• Security/GRC for evidence, control mapping, and assessment response.

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

Step 1: Name the control owner and decision authority

Assign:

• PT-2 control owner (usually Privacy or GRC).
• Authority approver (often Legal/Privacy counsel or a delegated official).
• System/process attestors (system owners who confirm their PII processing aligns to documented authority).

Practical tip: publish this in your control matrix so assessors see accountability immediately ².

Step 2: Define what counts as “PII” for your program

Write a short internal definition aligned to your environment and scope it to:

• Direct identifiers (name, SSN, employee ID).
• Indirect identifiers that can reasonably identify a person when combined.

Do not over-theorize. The output you need is a consistent scoping rule that lets teams classify datasets and pipelines as in-scope.

Step 3: Build a PII processing inventory (system + workflow level)

Create (or extend) an inventory that lists, at minimum:

• System/application name and owner
• PII categories processed
• Processing purposes (why)
• Data subjects (employees, customers, citizens, etc.)
• Data sources and collection points (forms, APIs, imports)
• Disclosures/sharing (internal and third parties)
• Storage locations and environments
• Retention and disposal triggers

If you already maintain a data map, adapt it so it can support an “authority mapping” column.

Step 4: Determine the authority for each processing purpose

For each inventory line item, document:

• Authority type (for example: statute/regulation, agency directive, contract requirement, formal program authorization)
• Authority reference (title, section identifier, contract clause reference, or internal directive identifier)
• Authority owner (who can interpret or update it)
• Constraints implied by the authority (limits on use, sharing, retention, notice)

PT-2 does not require you to publish a legal memo in every system record. It does require enough specificity that an auditor can follow the thread from “we process PII in System X for Purpose Y” to “this authority permits that processing” ¹.

Step 5: Document the result in assessor-friendly artifacts

Minimum set most teams need:

• A PT-2 procedure: how authorities are determined, approved, recorded, and reviewed.
• A PII authority register: a table of authorities and where they apply.
• A system/workflow mapping: inventory entries mapped to authority IDs.

A tight table usually beats long prose. Example fields:

System/Process	PII Categories	Purpose	Authority ID	Authority Reference	Third Parties	Notes/Constraints

Step 6: Operationalize change control (so PT-2 stays true)

PT-2 breaks when the business changes faster than documentation. Add PT-2 checks to:

• SDLC / intake: new feature that collects PII cannot go live without an authority mapping entry.
• Procurement: third-party onboarding requires identifying the authority for the PII disclosure to that third party.
• Data governance: new dataset in the lake/warehouse requires a declared purpose and authority.
• Privacy review triggers: changes to use, sharing, retention, or new data subject groups.

Step 7: Test it the way an auditor will

Pick a sample of high-risk workflows (HR, identity, access logs, customer support recordings, analytics). For each:

• Show the data flow.
• Show the processing purpose.
• Produce the authority mapping.
• Show that third-party sharing (if any) is captured and tied to the same authority or an explicit approved authority for disclosure.

If any workflow lacks a clear authority trail, treat it as a control failure and fix the mapping and governance.

Required evidence and artifacts to retain

Retain evidence that proves both “determine” and “document” happened, and that it stays current:

• PT-2 policy/procedure document with owner, scope, and review cadence ².
• PII processing inventory with authority mapping fields populated.
• Authority register (list of authorities relied upon).
• Approval records (tickets, sign-offs, meeting minutes) for new authorities or new uses of PII.
• Change management evidence showing PT-2 checks in SDLC/procurement intake.
• Assessment-ready exports (screenshots or reports) showing mappings for sampled systems.

Daydream note (earned mention): teams commonly store PT-2 evidence across GRC, intake tools, and spreadsheets. Daydream can act as the system of record for control ownership, procedures, and recurring evidence artifacts so PT-2 does not become a quarterly scavenger hunt ².

Common exam/audit questions and hangups

Assessors tend to ask:

• “Show me the documented authority for processing PII in System A.”
• “How do you know every PII-processing system has an authority mapped?”
• “What triggers an update when a system starts using PII for a new purpose?”
• “How do you control disclosures to third parties and prove the authority covers that disclosure?”

Common hangups:

• Authority is documented only at an enterprise level, with no traceability to systems.
• Inventory exists, but “purpose” is vague (“operations”) so authority cannot be evaluated.
• Third-party sharing is missing from the mapping, especially for SaaS sub-processors and analytics.

Frequent implementation mistakes and how to avoid them

1. Mistake: treating “legitimate business need” as authority.
   Fix: define acceptable authority types for your organization and require a reference ID in the inventory.

2. Mistake: one authority statement for the whole enterprise.
   Fix: keep an enterprise authority register, but also map authority to each system/workflow and purpose.

3. Mistake: the inventory is owned by one team and never updated.
   Fix: push updates into intake workflows where engineering, product, HR, and procurement already operate.

4. Mistake: ignoring third parties.
   Fix: require a “third party processing/disclosure” field, and block contracting/onboarding until it’s completed.

5. Mistake: building artifacts that cannot be sampled.
   Fix: ensure you can export a clean report showing system → PII → purpose → authority → approver.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for PT-2, so this page does not cite specific actions.

Risk-wise, PT-2 gaps usually surface as:

• Unapproved PII use cases that expand quietly over time.
• Inconsistent disclosures to third parties because nobody can point to the permitting authority.
• Assessment failures due to missing documentation even when the organization believes it has a valid basis ².

Practical 30/60/90-day execution plan

First 30 days (stabilize and get to “auditable minimum”)

• Assign PT-2 control owner and approver; publish RACI in your control matrix.
• Draft the PT-2 procedure and define acceptable authority types and the minimum documentation fields.
• Inventory the highest-impact systems that process PII and populate an initial authority mapping.
• Run a mini-audit on a small sample to confirm you can produce evidence on demand.

By 60 days (expand coverage and embed into workflows)

• Expand the PII processing inventory to cover the full in-scope environment.
• Build an authority register and normalize authority IDs so mapping is consistent.
• Add PT-2 checkpoints to procurement and SDLC intake (tickets/forms with required fields).
• Train system owners on how to update authority mappings when purpose changes.

By 90 days (operate the control and prove it)

• Run an internal assessment: sample systems, validate mappings, and record remediation.
• Establish a recurring review cycle tied to change management and third-party onboarding.
• Centralize evidence collection (for example, in Daydream) so PT-2 artifacts, owners, and attestations are current and exportable for audits.

Frequently Asked Questions

What counts as an “authority” under PT-2?

PT-2 expects a formal basis that permits PII processing, such as a law, regulation, directive, contract requirement, or other documented authorization your organization recognizes ². Document the reference and scope so it can be evaluated against actual processing.

Do I need a separate authority for each system?

You can reuse the same authority across multiple systems, but you must still map each system’s PII processing purposes back to that authority. Auditors typically test traceability at the system/workflow level, not only enterprise policy level.

How should we handle third parties that process PII on our behalf?

Treat third-party processing and disclosures as part of the same authority mapping exercise: identify the authority that permits the disclosure/processing and document which third parties are involved. Make this a procurement onboarding requirement so it stays current.

We have a data inventory but it doesn’t include “purpose.” Is that a PT-2 issue?

Yes, because PT-2 hinges on “authority that permits processing,” and authority is evaluated against a defined purpose. Add a purpose field and require it to be specific enough to review and approve.

What evidence is most likely to be requested in an assessment?

Expect requests for your PT-2 procedure, your PII processing inventory with authority mappings, and samples that show traceability for specific systems and workflows ¹. Keep approval records for new or changed processing purposes.

Can Daydream replace our spreadsheet-based PT-2 tracking?

Yes, if you configure it as the system of record for control ownership, implementation procedures, and recurring evidence artifacts so mappings and approvals are trackable over time. The key is consistent fields and exportable reports for assessors.

Footnotes

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

2. NIST SP 800-53 Rev. 5