PT-8: Computer Matching Requirements

PT-8 requires you to identify when your system participates in a “matching program” and, if it does, implement the specific legal and procedural safeguards that govern computer matching (such as formal agreements, notice, and accountability). To operationalize it quickly, decide whether any data sharing or analytics qualifies as matching, assign an owner, document the procedure, and retain repeatable evidence. ¹

Key takeaways:

• PT-8 only triggers if you conduct a “matching program”; your first job is classification and scoping. ¹
• Treat PT-8 as a documented workflow: approval gates, required terms, notice/consent checks, and logging of matching runs. ²
• Audits fail most often on missing evidence: no mapping to an owner, no procedure, and no proof the process runs consistently. ¹

PT-8: computer matching requirements requirement is easy to mis-handle because many teams do “matching-like” work (eligibility checks, identity resolution, fraud screening, benefit coordination) without calling it a matching program. PT-8 is the control that forces you to answer a binary question: are you processing information for the purpose of conducting a matching program? If yes, you must implement the matching-program safeguards as a defined, repeatable operational process with auditable outputs. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to (1) scope whether any system use case qualifies as matching, (2) bind that decision to governance artifacts (owner, procedure, approval requirements), and (3) produce durable evidence that the process is followed for each matching activity. PT-8 sits in the NIST Privacy (PT) control family and will show up in federal system assessments and in contractor environments handling federal data where privacy engineering and documentation discipline are expected. ²

This page gives you a requirement-level playbook you can implement without waiting on a long policy rewrite.

Requirement: PT-8 computer matching requirements

Plain-English interpretation: If your system or organization processes information to run a matching program, you must follow the required computer matching safeguards, and you must be able to prove you followed them. Your “proof” needs to be more than a policy statement; it needs to be a workflow with named owners, approvals, and retained artifacts tied to each matching program. ¹

Why this exists (operator context)

Computer matching introduces predictable privacy failure modes: using data for a purpose the data subjects did not expect, linking datasets in ways that increase identifiability, and making determinations (eligibility, adverse actions, access decisions) based on merged records. PT-8 is the control that forces you to treat matching as a governed program, not an ad hoc analytics job. ²

Regulatory text

Provided excerpt: “When a system or organization processes information for the purpose of conducting a matching program:” ¹

What the operator must do with this excerpt

1. Detect the trigger condition: Determine whether any processing you perform is “for the purpose of conducting a matching program.” Treat this as a scoping decision that must be recorded and reviewable. ¹
2. If triggered, implement matching-program requirements as controlled work: Document who approves matching, what prerequisites must be met, and what artifacts must be produced and retained per matching activity. ²
3. Make it assessable: Map PT-8 to an owner, an implementation procedure, and recurring evidence artifacts so an assessor can test both design and operation. ¹

Who it applies to

Entity scope

• Federal information systems assessed against NIST SP 800-53. ²
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down contractually or required by an authorization program. ²

Operational scope (where PT-8 tends to trigger)

You should perform PT-8 scoping when a system performs any of the following, especially across organizational boundaries or datasets with different original purposes:

• Matching records across two datasets to confirm identity, eligibility, or entitlement.
• Cross-checking lists (e.g., sanctions-like checks, duplicate detection, death master checks, benefits coordination).
• Automated joins across systems where the output drives a decision about a person.

PT-8 is not automatically triggered by every ETL job. It triggers when the purpose is a matching program. Your job is to document the purpose and the governance applied. ¹

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

Step 1: Define “matching program” in your control procedure

Create a short internal definition that your engineers, product owners, and privacy counsel can use consistently. Include:

• The types of inputs (datasets, sources, third parties)
• The matching logic (exact match, probabilistic match, identity resolution)
• The intended outputs (eligibility determination, fraud flag, denial, adverse action)
• Whether the matching is one-time or recurring

Keep it operational. Avoid legal essays. Your goal is consistent triage. ²

Step 2: Build a PT-8 intake and decision workflow (the “trigger check”)

Create a lightweight intake form or ticket template that is required before any new matching use case goes live. Minimum fields:

• Business purpose and decision impact
• Data sources and data elements
• Whether any source is external (another agency, another business unit, a third party)
• Whether individuals are notified/consented (or basis for not doing so)
• Retention period for match outputs
• Security controls and access model for match outputs

Then require a recorded decision: PT-8 applies / does not apply, with approver and rationale. ¹

Step 3: Assign a single accountable owner (and two required reviewers)

Operationalize PT-8 like a change-control gate:

• Control owner: privacy lead or GRC lead who ensures artifacts exist and reviews evidence.
• Required reviewers: legal/privacy counsel (matching compliance) and security (data protection and logging).
• Optional reviewers: data governance, records management, and the system owner.

This directly supports the recommended control mapping expectation: owner, procedure, recurring evidence. ¹

Step 4: Create a “Computer Matching Program Packet” template

This is the artifact bundle you will retain for each matching program. Keep it consistent so audits are fast. Include:

• Approved intake form and applicability decision
• Data inventory excerpt for the inputs and outputs (what data, from where, for what purpose)
• Matching logic description at a level suitable for governance review
• Required approvals and sign-offs
• Notice/consent or authority rationale (documented position)
• Risk assessment notes and mitigations (access controls, minimization, retention, QA)
• Operational plan (how runs are initiated, monitored, and logged)

Store packets in a controlled repository with versioning. ²

Step 5: Implement run-level controls (so you can prove operation, not just design)

For each matching run or scheduled recurring match:

• Log who initiated the run, when, and under what approved matching packet ID.
• Log the input dataset versions (or pointers) and output destination.
• Restrict access to match outputs to approved roles.
• Retain a reconciliation/QA record when matching affects determinations about people (e.g., false positive review steps, exception handling).

Auditors commonly ask for “show me the last run” evidence. Build this into the job orchestration or ticketing workflow. ²

Step 6: Establish recurring review and re-approval triggers

Define what changes force re-approval:

• Adding a new data source
• Expanding the purpose or decision impact
• Material changes to matching logic
• New third party involvement
• Retention or access model changes

Track these as change events tied to the matching packet. ²

Step 7: Map PT-8 in your control library and assessment narrative

In your SSP or control repository, document:

• Control statement for PT-8
• Owner
• Procedure link
• Evidence list and collection frequency
• Systems in scope (where matching applies) and systems out of scope (with rationale)

Daydream is useful here as the system of record to map PT-8 to the control owner, the procedure, and recurring evidence artifacts so you can answer assessor requests quickly without rebuilding context each cycle. ¹

Required evidence and artifacts to retain (audit-ready)

Use this checklist as your evidence register for the pt-8: computer matching requirements requirement:

Evidence artifact	What it proves	Where it usually lives
PT-8 applicability decisions 1	You detected when PT-8 triggers	GRC tool or ticketing
Computer Matching Program Packet 1	Governance, approvals, purpose limitation	GRC repository / DMS
Data inventory entries for inputs/outputs	You know what data is matched and produced	Data governance catalog
Run logs tied to packet ID	Control is operating	SIEM / job scheduler logs
Access reviews for output datasets	Output is protected	IAM tool evidence
Change records for logic/source changes	Re-approval gates work	Change management tickets

Tie each artifact to a matching program identifier so sampling is straightforward. ²

Common exam/audit questions and hangups

Expect these questions in assessments aligned to NIST SP 800-53: ²

• “Which systems conduct matching programs? Show your scoping rationale.”
• “Show the documented procedure for initiating and approving a match.”
• “Who approves matching programs? How do you enforce that approval?”
• “Provide evidence for the most recent matching run: inputs, outputs, approver, logs.”
• “How do you control downstream use of match outputs?”
• “What triggers re-approval when data sources or logic change?”

Hangups that slow audits:

• No single place where matching programs are listed.
• Logs exist but cannot be tied to an approved program.
• Teams treat matching as “analytics” and skip governance.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating PT-8 as a policy-only control.
   Fix: require a packet per matching program plus run-level evidence. ²

2. Mistake: scoping only at the system boundary.
   Matching often happens in pipelines, notebooks, or third-party platforms. Scope by use case and data flow, not by application name. ²

3. Mistake: no re-approval triggers.
   Teams add a data source later and never revisit the decision. Add change triggers to your intake template and change-management process. ²

4. Mistake: evidence exists but is not retrievable.
   Fix: create an evidence register and store artifacts with consistent naming and version control. Daydream can keep the mapping between PT-8, owners, and evidence locations so you can answer assessor requests fast. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat PT-8 primarily as an assessment and authorization risk: failure typically shows up as audit findings, authorization delays, corrective action plans, and contractual noncompliance for contractor systems handling federal data. ²

Practically, the risk is concentrated in two areas:

• Uncontrolled secondary use of matched data and match outputs.
• Unprovable governance (you may be doing the right things informally, but cannot demonstrate them).

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

First 30 days (foundation)

• Assign PT-8 control owner and reviewers; document roles and RACI.
• Create the PT-8 intake template and applicability decision record.
• Inventory known matching-like use cases across systems and teams; record initial applicability decisions.

By 60 days (operationalize)

• Publish the Computer Matching Program Packet template.
• Require packet completion and approval for all in-scope matching programs.
• Implement run-level logging requirements and link logs to packet IDs.

By 90 days (assess and harden)

• Run an internal mini-audit: sample recent matching runs and verify artifacts end-to-end.
• Add re-approval triggers to change management and data governance workflows.
• Centralize evidence mapping in a GRC system (Daydream or equivalent) so PT-8 evidence is consistent across teams and assessment cycles. ¹

Frequently Asked Questions

How do I know if an activity is a “matching program” for PT-8 purposes?

Treat it as matching when the purpose is to compare or link records about individuals across datasets to produce an output that drives a decision or determination. Document the purpose and decision impact, then record an applicability decision. ¹

Does PT-8 apply to internal matching between two business units?

It can. PT-8 triggers based on the purpose (conducting a matching program), not strictly on whether data crosses an external boundary. Your intake should capture internal cross-dataset matching and route it through the same approval gate. ²

What evidence do auditors usually want first?

They typically ask for your list of matching programs, the documented procedure, and a recent example showing approvals plus run-level logs. If you cannot tie a matching run to an approved packet, expect a finding. ²

We outsource matching to a third party. Are we still on the hook?

Yes for governance and evidence. Treat the third party as part of the matching program, require the same packet artifacts, and ensure contracts/SOWs support your logging, access control, and retention expectations for match outputs. ²

Can we mark PT-8 “not applicable”?

Yes if you do not process information for the purpose of conducting a matching program. Record the rationale, the systems reviewed, and who approved the determination so it stands up during assessment. ¹

How should we manage PT-8 across multiple systems?

Use one standard intake and packet template, then map each in-scope system/use case to the same PT-8 procedure and evidence register. A GRC system like Daydream helps keep owner/procedure/evidence mappings consistent and assessable. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5