Privacy-Compliant Communications for Regulated Industries

Regulated industries — finance, legal, healthcare-adjacent services, public sector — operate under data-minimization duties that treat metadata as personal data. GDPR Article 5(1)(c) requires collecting the minimum data necessary; Article 25 demands privacy by design and by default; the ePrivacy Directive protects the confidentiality of communications themselves, including traffic data. Yet most messaging infrastructure retains a complete communication graph: who contacted whom, when, and how often. That graph is personal data, and holding it creates a compliance surface that no encryption layer removes.

The problem: messaging metadata is personal data

Data-protection regulators have consistently held that traffic data — source, destination, timestamp, frequency — is personal data within the meaning of GDPR Art. 4(1). The European Court of Justice (La Quadrature du Net, 2020) reinforced that metadata retention engages fundamental rights. CCPA's broad definition of "personal information" likewise captures inferences derivable from communication patterns.

For enterprise architects this means: a "secure" messaging rollout that logs routing metadata is still processing personal data at scale, requiring a lawful basis, retention limits, impact assessments (DPIAs), and breach-notification exposure. The cleanest compliance posture is not to hold the data at all.

How Tessera helps

Tessera's architecture is structurally data-minimizing. Relays route messages to buckets, not to identified recipients; the recipient pulls from their bucket. A relay operator cannot reconstruct the sender↔recipient graph because it never exists in a single place. Three properties matter for compliance:

• No central authority. Enrolment is pairwise and local; there is no directory service holding the full user graph.
• Metadata privacy by construction. Blinded pseudonyms and bucketed broadcast mean relays process messages without learning which user is which.
• Quantifiable privacy. (ε,δ)-DP cover traffic gives a formal, tunable privacy guarantee that a DPIA can cite directly.

Deployment: self-hosted relays

For regulated workloads the recommended deployment isself-hosted: the organization operates its own relay nodes (or a federation thereof) inside its trust boundary. Because relays are metadata-blind by design, even a fully self-hosted relay learns less about its users than a conventional messaging server would. No third-party processor processes identifiable metadata, narrowing the Art. 28 processor-contract surface.

# run a compliant relay node inside your VPC
uv run python -m tessera.network.ws_server --port 8100 \
    --storage sqlite:///var/lib/tessera/relay.db \
    --cover-traffic-epsilon 0.1 --cover-traffic-delta 1e-6

# cluster of relays (mesh or ring) for resilience
uv run python -m tessera.deploy.cluster --nodes 5 --topology mesh

Compliance mapping

The following table maps specific obligations to the Tessera mechanism that satisfies them. This is architectural guidance, not legal advice; a DPIA should confirm applicability to your jurisdiction and processing.

Why this is stronger than policy alone

A data-retention policy says "we will delete metadata after 30 days." Tessera says "the relay cannot reconstruct the metadata at all." The difference matters in breach scenarios: a breached conventional server exposes the full graph; a breached Tessera relay exposes only bucket-addressed ciphertext and cover traffic, with the real traffic indistinguishable under (ε,δ)-DP. Privacy-by-design under Art. 25 favors technical guarantees over policy promises, and the DP budget is auditable.

Frequently asked questions