PT-7: Specific Categories of Personally Identifiable Information

PT-7 requires you to apply an organization-defined privacy process to specific categories of personally identifiable information (PII), rather than treating all PII the same. Operationalize it by defining “special handling” PII categories, mapping where they exist in systems and third parties, and enforcing category-specific rules (collection, access, sharing, retention, and monitoring) with auditable evidence. ¹

Key takeaways:

• Define your “specific categories” of PII and the exact handling rules for each category.
• Tie categories to real systems, data flows, and third parties, then enforce controls where the data is created, stored, processed, or shared.
• Keep assessor-ready evidence: category inventory, data maps, procedures, and proof the rules run in production.

The pt-7: specific categories of personally identifiable information requirement is about precision. You can’t manage privacy risk effectively if your program treats every piece of PII as equal. PT-7 pushes you to identify categories of PII that warrant special handling and then apply your organization-defined privacy process to those categories consistently across the lifecycle.

Practically, this becomes a classification-and-controls exercise: define the categories, find them in your environment, decide what “different” means (stricter access, narrower sharing, shorter retention, stronger monitoring, additional approvals), and prove those rules operate across systems and third parties. Most programs fail PT-7 in one of two ways: (1) the categories exist only in a policy and never make it into technical or operational workflows, or (2) teams “over-classify” without defining concrete handling differences, which makes the program unenforceable.

PT-7 is assessed like other NIST SP 800-53 controls: assessors look for a defined approach, clear ownership, repeatable procedures, and evidence of operation. ²

Regulatory text

Control text (excerpt): “Apply {{ insert: param, pt-07_odp }} for specific categories of personally identifiable information.” ¹

What this means operationally: PT-7 expects you to:

1. define the organization’s approach (the “organization-defined process” referenced in the control), and
2. apply it to specific categories of PII you designate as needing distinct treatment.

Because the excerpt references an organization-defined parameter, your implementation must be explicit: write down the categories, the criteria for putting data in a category, and the required handling controls for each category. Assessors will not infer your intent.

Plain-English interpretation

PT-7 requires category-based PII handling. You must decide which PII categories need extra protections or different rules, then make those rules real in operations.

Examples of “specific categories” (your list will vary by mission, law, and contracts):

• Government identifiers (e.g., SSN-equivalents, passport numbers)
• Financial account data
• Biometric identifiers
• Health-related information
• Children’s data
• Credentials or authentication-related PII (if stored)
• Precise geolocation

PT-7 does not require a universal category list. It requires that your organization defines categories and consistently applies a documented process to them. ¹

Who it applies to

Entity scope

• Federal information systems
• Contractor systems handling federal data ¹

Operational scope Apply PT-7 anywhere you create, collect, store, process, transmit, or share PII, including:

• Business applications (case management, HR, benefits, identity)
• Data platforms (data lakes, analytics workspaces)
• Logging/monitoring pipelines that may capture PII
• Third parties that process PII (cloud providers, SaaS, support, call centers)
• Integration points (APIs, ETL jobs, managed file transfers)

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

1) Assign an owner and define the PT-7 procedure

Deliverable: a short PT-7 operating procedure that states:

• control owner (often Privacy Officer + Security/GRC co-owner)
• approval authority for category definitions and exceptions
• how categories are maintained and reviewed
• how category rules are implemented in systems and third-party engagements

This step aligns to the practical expectation to map PT-7 to an owner, procedure, and recurring evidence. ¹

2) Define your “specific categories of PII” and the criteria

Deliverable: a PII Category Standard (table format works best) with:

• Category name
• Data elements included/excluded (examples)
• Business rationale for special handling
• Systems/contexts where it appears (initially “TBD,” then filled in after discovery)
• Required handling rules (see step 4)

Operator tip: avoid category sprawl. If you can’t describe a different handling rule, it is not a meaningful “specific category” for PT-7.

3) Inventory where those categories exist (systems + third parties)

Deliverables:

• A PII category inventory mapped to:
  • Applications and databases
  • Data stores (object storage, file shares)
  • Data flows (ingress/egress, integrations)
  • Third parties and subprocessors

How to execute fast:

• Start with your highest-volume PII systems (identity, HR, benefits, CRM/case tools).
• Pull data dictionaries, schema exports, and key form fields.
• Review API specs and integration tickets for PII fields.
• Confirm third-party processing via contracts/SOWs and security questionnaires.

4) Set category-specific handling requirements (make “different” explicit)

Deliverable: a handling matrix that turns PT-7 into enforceable rules.

Use a table like this:

Category	Collection limits	Access controls	Sharing/transfer	Retention	Monitoring
Gov ID	Collect only if required by program	Role-based access + approvals	Encrypt in transit; restrict to named recipients	Shorter retention or legal schedule only	Alerts on bulk export
Biometrics	Explicit authorization basis	Strong MFA; least privilege	No onward sharing without privacy approval	Minimal retention	High-sensitivity DLP rules

Keep the controls consistent with your broader NIST SP 800-53 program so implementation is assessable and testable. ²

5) Implement the rules in operational workflows

This is where PT-7 passes or fails. Wire category requirements into daily processes:

SDLC / change management

• Add a required field: “PII category present?” in intake and design reviews.
• Require privacy review for new systems handling PT-7 categories.
• Gate production release on: updated data map + implemented controls.

Access management

• Map categories to access tiers.
• Require documented approvals for access to special categories.
• Review access on a schedule driven by your risk posture (document your chosen cadence in the procedure).

Data protection tooling

• DLP patterns for the defined categories (where technically feasible).
• Encryption requirements aligned to your system baselines.
• Tokenization/redaction for non-production environments.

Third-party due diligence

• Contract clauses: permitted purposes, onward sharing restrictions, breach notification, deletion/return, audit rights as applicable.
• Verify processor controls: access controls, encryption, and segregation.
• Track which third parties process which categories, not just “PII yes/no.”

Daydream fit (earned, not forced): Teams often track PT-7 artifacts across spreadsheets, ticketing, and contract folders. Daydream can centralize the control owner, the PT-7 procedure, and recurring evidence artifacts so you can answer assessor questions without rebuilding the story each audit cycle.

6) Test and keep evidence current

Control testing approach

• Pick representative systems for each category.
• Validate: category identification exists, controls are configured, and operations follow the procedure.
• Record exceptions with compensating controls and an expiration date.

Required evidence and artifacts to retain

Maintain an assessor-ready package that proves design and operation:

1. PT-7 operating procedure (owner, scope, review cadence, exception process)
2. PII Category Standard (definitions, criteria, examples)
3. System/data map showing where each category resides and flows
4. Handling matrix mapping categories to enforceable requirements
5. Implementation evidence, such as:
   • screenshots/export of DLP rules for a category
   • access control configurations (roles/groups) and approval records
   • change tickets showing privacy review for category-bearing systems
   • vendor/third-party register entries showing category processing
6. Testing evidence (test plan, sampling, results, remediation tickets)

Common exam/audit questions and hangups

Assessors and auditors commonly ask:

• “What are your specific PII categories, and who approved them?”
• “Show me where Category X exists in your environment.”
• “How do category rules show up in access requests and approvals?”
• “How do you control sharing with third parties by category?”
• “How do you know teams follow the process for new projects?”

Common hangup: “We have a privacy policy.” PT-7 expects category-specific operational proof, not just policy language. ¹

Frequent implementation mistakes and how to avoid them

1. Category list with no handling differences
   Fix: require each category to have at least one stricter rule (access, sharing, retention, monitoring) documented in the handling matrix.

2. No system-level mapping
   Fix: tie categories to an application inventory and data flows. If you can’t point to where the data is, you can’t prove the control operates.

3. Ignoring third parties
   Fix: add a “PII categories processed” field to your third-party register and contract intake checklist.

4. Uncontrolled exceptions
   Fix: require documented approval, compensating controls, and an expiration date; review exceptions during control testing.

Risk implications (why operators care)

Category-based handling reduces the chance that highly sensitive PII is broadly accessible, over-retained, or shared beyond intended purposes. PT-7 also supports faster incident response because you can quickly identify whether an event involves a special category with higher reporting, reputational, or contractual impact. ²

Practical execution plan (30/60/90-day)

Use phases rather than fixed calendar promises; adjust to your system count and staffing.

First 30 days (Immediate)

• Name PT-7 control owner(s) and approve the PT-7 operating procedure. ¹
• Draft the initial PII Category Standard (start with a small, high-risk set).
• Select pilot systems where those categories are most likely present.
• Add “PII category present” to project intake and change tickets.

Next 60 days (Near-term)

• Complete category mapping for pilot systems and top third parties.
• Publish the handling matrix and implement access + sharing rules for pilot systems.
• Implement at least one technical enforcement mechanism per category where feasible (DLP rule, encryption requirement, tokenization/redaction practice).
• Train engineering, procurement, and system owners on the procedure.

Next 90 days (Operationalize and prove)

• Expand inventory coverage to remaining in-scope systems and third parties.
• Run a PT-7 control test with sampling and retain evidence.
• Formalize exception tracking and remediation workflow.
• Prepare an assessor packet that links categories → systems → controls → evidence.

Frequently Asked Questions

How do we choose “specific categories” of PII for PT-7?

Start with categories that would drive stricter handling in your environment (access limits, restricted sharing, shorter retention, stronger monitoring). Document the criteria and get formal approval so the categories are defensible in assessment. ¹

Do we need a separate policy for each category?

No. A single PT-7 procedure plus a category standard and handling matrix is usually cleaner. What matters is that category differences are explicit and implemented in workflows and systems. ²

How do we prove PT-7 is operating, not just documented?

Keep evidence that category rules are enforced: access approvals, role mappings, DLP configurations, change tickets showing privacy review, and third-party contracts/register entries tied to categories. Pair that with a periodic control test and remediation records. ²

What if a SaaS third party won’t tell us exactly where data is stored?

Record the categories processed, the purposes, and the control commitments in the contract and due diligence package. If data residency or subprocessing details are required for your risk posture, treat refusal as an exception that needs documented acceptance and compensating controls.

Does PT-7 require data discovery tooling?

PT-7 doesn’t mandate a tool. Use whatever produces reliable category mapping and evidence. Many teams combine schema reviews, form inventories, and targeted discovery scans for high-risk repositories. ²

How should Daydream show up in an audit for PT-7?

Use Daydream as the system of record for PT-7 ownership, the approved procedure, and recurring evidence artifacts, then link out to technical proofs (tickets, screenshots, exports). Auditors care that the trail is complete and repeatable, not where the files live.

Footnotes

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

2. NIST SP 800-53 Rev. 5