How should privacy-preserving exposure notification systems limit what data is collected and stored?

They should minimize collection by using rotating, short-lived identifiers instead of location history or persistent personal profiles. A workable design keeps matching data on devices where possible, limits any central storage to narrowly scoped keys, and purges records quickly. That reduces the burden on health authorities and lowers the chance that a large trove of sensitive movement data can be misused.

How to Minimize Data Collection Without Breaking Exposure Notification

Privacy-preserving exposure notification works when the system is designed to answer one narrow question: whether a device was near another device that later reported an infection, without building a broader surveillance record. That means the architecture should treat location, social graph data, and durable identity as out of scope, unless a specific public-health design requires them for a very limited purpose.

The collection boundary should be set at the protocol level, not left to policy statements alone. If a design can function with ephemeral, rotating proximity identifiers and on-device matching, then that is the right baseline because it avoids creating a central dataset that is more sensitive than the notification function requires.

What Data Should Never Become Part of the Core Design

The strongest privacy posture is to avoid collecting data that turns a proximity alert into a movement history. Persistent personal profiles, raw location trails, contact graphs, and long-lived identifiers create a dataset that is materially more valuable than the exposure notification use case needs. Once such data exists, its risk profile changes because it can be repurposed for enforcement, profiling, or unrelated analytics.

A good rule is to ask whether each field is necessary to compute exposure, verify a report, or prevent abuse. If it only improves convenience, analytics, or future product flexibility, it should usually stay out of the system. When a central component is unavoidable, it should hold only the narrowest keys or certificates needed for the trust function, not a broad record of who met whom.

Retention, Matching, and Deletion Should Be Built for Short Lifecycles

Retention should be measured in days, not months, and only as long as the public-health workflow genuinely needs it. On-device matching reduces the amount of sensitive data that ever leaves the phone, while fast purging limits the value of any records that must be retained for validation, abuse prevention, or operational troubleshooting.

That short lifecycle matters because exposure notification systems can accumulate risk over time even if any single data element seems harmless. The longer identifiers, report keys, or diagnostic tokens remain available, the easier it becomes to correlate events, infer proximity patterns, or recover historical movement from secondary logs.

Risk and Threat Considerations

These systems are most exposed when data minimization is treated as an implementation detail instead of a hard design constraint. Even a well-intentioned public-health platform can become a high-value target if it stores long-lived identifiers, centralizes matching data, or keeps detailed logs that let an outsider reconstruct who was near whom.

Failure mechanism: The design drifts from temporary proximity processing into persistent identity and location correlation, often through analytics, debugging, or backend retention that outlives the original notification purpose.

Impact: Sensitive movement data can be misused for profiling, coercion, or unauthorized secondary uses, and a compromise of the stored data can reveal far more than a single exposure event.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.

Framework	Control / Reference	Relevance
GDPR	Art. 5 — Principles relating to processing of personal data	Requires data minimisation and storage limitation for exposure-notification data.
	Art. 25 — Data protection by design and by default	Directly supports building privacy-minimizing exposure notification into the architecture.
	Art. 32 — Security of processing	Applies to protecting stored keys and short-lived records from misuse or compromise.
Recommendation — Limit collection to what is necessary and purge records once the notification purpose is complete. Build rotating identifiers and on-device matching into the default system design. Protect any retained matching material with strong access control and rapid deletion.
NIST CSF 2.0	PR.DS-01 — Data-at-rest is protected	Relevant to limiting and protecting any central exposure-notification storage.
	PR.DS-10 — Data-in-transit is protected	Supports secure exchange of diagnosis keys and notification data between devices and services.
	PR.AA-05 — Physical and logical access to assets is limited to authorized users, processes, and devices	Supports narrowing access to the small set of central keys or operational records.
Recommendation — Encrypt and tightly restrict any retained exposure-notification data. Protect proximity-report exchanges in transit with authenticated, encrypted channels. Restrict access to retained records and trust keys to the minimum necessary processes.
ISO/IEC 27001:2022	A.5.15 — Access control	Applies where central services must limit who can access notification-related data.
	A.8.12 — Data leakage prevention	Supports preventing unintended disclosure of movement or proximity data.
Recommendation — Define and enforce least-privilege access to any retained exposure-notification records. Apply controls that prevent exposure-notification data from being copied or exported unnecessarily.

Practitioner Guidance

What to verify: Confirm that the system can still function if all nonessential fields are removed, and insist on a data inventory that distinguishes exposure matching inputs from operational telemetry. If a field is not needed for matching, report validation, or narrowly scoped abuse prevention, treat it as optional until proven otherwise.

What good looks like: Matching happens on device where possible, centrally stored material is short-lived and purpose-limited, and deletion is automatic rather than dependent on manual cleanup. The safest sign is that the system can answer exposure questions without retaining a reusable history of people, places, or relationships.

Practitioner takeaway: Privacy-preserving exposure notification succeeds when minimization is engineered into the protocol and retention model, not added after the fact as a policy promise.