Death data and compliance: permissible use, GLBA and vendor review

Start with purpose, not with product

The first question is not which provider to use. It is what you are going to do with the answer, because the use determines which rules apply.

Using a deceased signal to prevent fraud at origination, to validate a claim, to stop a payment or to suppress outreach is a straightforward operational use. Using it as a factor in a decision about a living consumer's eligibility, terms or employment is a different thing entirely and may bring consumer reporting obligations into scope.

Write the intended use down, in plain language, before procurement starts. Most of the compliance friction later in these projects comes from a use case that was never defined precisely enough for legal to give a clean answer.

The Safeguards Rule obligations you keep

Financial institutions in scope of the FTC Safeguards Rule at 16 CFR Part 314 carry a set of obligations that do not transfer to a vendor. Bringing in a deceased data provider adds a service provider to your program, it does not reduce your program.

In practice, adding this vendor should touch several parts of your existing information security program. Your risk assessment should reflect the new data flow. Your service provider oversight should cover the new provider, with written security obligations and a reassessment cadence. Your access controls should cover who inside your organization can see match results, because a deceased match is sensitive information about a real household.

None of this is unusual, and a provider that has done it before will hand you the mapping rather than making you build it.

• Update the written risk assessment to cover the new data flow
• Record the provider in your service provider inventory with written security obligations
• Define who internally can view and export match results
• Confirm retention and deletion for both the records you send and the results you receive
• Include the provider in your incident response contact chain

When a deceased match becomes a consumer report

This is the area teams most often get wrong, and it is worth a short conversation with counsel rather than a long one after the fact.

A deceased person is not a consumer for most purposes, so a confirmed match on someone who has genuinely died sits outside a lot of consumer protection machinery. The risk is not there. The risk is in the false positive, because a false positive is a statement about a living person.

If a match, or a near match, contributes to a decision about a living individual's credit, insurance, employment or eligibility, you need to be confident about which framework applies and what rights that individual has. This is another argument for the two state model described in our suppression guide: suppressing an outbound call is not an eligibility decision, whereas declining an application is.

Reviewing the vendor properly

Standard security questionnaires cover encryption, access control and incident response well. They cover data provenance badly, and provenance is where the risk in this category actually lives.

Ask where the data comes from, under what license or certification, and what happens to that access if the underlying agreement lapses. Ask what the provider does with the records you submit, because sending your customer file to a vendor who enriches their own product with it is a materially different arrangement to one who deletes it after delivery.

Then ask for the evidence rather than the assertion.

• Named source channels and the license or certification governing access
• Written confirmation that your submitted records are not resold, relicensed or used to enrich other products
• Documented retention and deletion schedule for inputs and outputs, with earlier deletion available on request
• Encryption in transit and at rest, with key management described
• Subprocessor list with locations, and notification of changes
• Incident response commitments including notification timing
• Current attestation status stated honestly, including anything still in progress
• Control mapping to the framework your examiners use

Documenting it so it survives an examination

The artefacts that make this easy later are boring and quick to produce at the time. A one page description of the data flow. The permissible purpose statement. The vendor assessment and its date. The retention schedule. The threshold and escalation rules for acting on a match. The log design that evidences the control operating.

Assemble those during implementation and the annual review becomes a half day exercise. Assemble them afterwards and it becomes a project.

Common questions