Deep DiveEU

EU ePrivacy Directive Confidentiality of Communications

How to treat communications content, traffic data, and location data as privacy-critical product surfaces.

Focus: Articles 5, 6, and 9, retention and access controls, GDPR interplay, and the current OTT coverage gap.

Author
Sorena AI
Published
Feb 21, 2026
Updated
Feb 21, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published Feb 21, 2026
Updated Feb 21, 2026
Overview

For communications products, confidentiality is a product-architecture constraint, not a checkbox. Under the current directive, the baseline rules sit in Article 5 for confidentiality, Article 6 for traffic data, and Article 9 for location data other than traffic data, all as implemented in national law. The safest operational approach is a strict use-case register: what you do with content, traffic data, or location data, why, who can access it, for how long, and how users are informed.

Section 1

Start with the current directive baseline, content, traffic data, and location data

The current legal baseline is still Directive 2002/58/EC, not the proposed regulation. That means you should classify your communications data against the current directive text and national implementation first.

The most useful split in practice is content, traffic data, and location data other than traffic data, because the directive treats them differently.

  • Content, message bodies, call content, attachments, and payloads. Treat this as the most sensitive layer.
  • Traffic data, routing, time, duration, recipients, network identifiers, and related service-delivery metadata.
  • Location data other than traffic data, process only where national law and the directive conditions permit, and keep anonymization or consent logic explicit.
Section 2

Build a communications use-case register around Articles 5, 6, and 9

A use-case register is your core control. It prevents scope creep and forces teams to justify why communications data is being used at all.

Make it audit-ready with owners, approval dates, retention windows, and testable access controls.

  • For each use case, data type, purpose, necessity, alternatives considered, national-law constraint, and legal-review outcome.
  • Controls, access roles, logging, retention window, deletion trigger, and user-transparency reference.
  • Review triggers, new feature, new analytics purpose, new vendor, or longer retention period requires fresh review.
Section 3

Common product patterns that need tight controls

Most communications products hit the same pressure points. Treat these as risk hotspots and keep the controls product-specific.

The operational question is not only whether a use case is useful. It is whether the use case is permitted, necessary, minimized, and explainable.

  • Service delivery and billing, keep traffic-data use limited to what is needed for transmission, billing, interconnection, fraud handling, and closely related operational needs allowed by law.
  • Spam, security, and abuse prevention, define the signal set narrowly, retain only what is needed, and keep access controls strict.
  • Product analytics or personalization, treat any reuse of communications-related data as a specific use case that needs documented legal review and minimization.
Section 4

The GDPR layer and the remaining OTT gap

The GDPR still matters because many communications datasets include personal data and because the ePrivacy Directive is implemented alongside GDPR-era consent and transparency standards.

The proposed regulation is still useful as reform context, especially because it was designed to address the uneven treatment of OTT services, but you should not present it as current law.

  • Document the split clearly, ePrivacy or national telecom-privacy rules for communications secrecy and sector-specific limits, GDPR for broader personal-data processing obligations.
  • If your service is an OTT or adjacent service, record the specific national-law position rather than assuming the proposal text already applies.
  • Keep proposal-only concepts in a watchlist, not in your current-state control matrix.
Section 5

Evidence pack for confidentiality reviews

Your evidence should answer what data you use, for what purpose, under which controls, and how you prevent repurposing or excessive retention.

Make the pack exportable for internal audits, regulator questions, and product reviews.

  • Use-case register, approvals, and change history.
  • Retention schedule per data type and deletion-verification evidence.
  • Access controls, access logs, and periodic-access-review records.
  • Transparency mapping showing where each use case is communicated to users and where the GDPR layer is documented.
Recommended next step

Use EU ePrivacy Directive Confidentiality of Communications as a cited research workflow

Research Copilot can take EU ePrivacy Directive Confidentiality of Communications from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Primary sources

References and citations

Related guides

Explore more topics

Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation
An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage.
Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists
A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control.
Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists
A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed.
ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata
A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting.
ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence
An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions).
ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)
A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design.
ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits
A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment.
ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence
An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX.
ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls
Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC).
ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map
A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)).
ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?
A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality.
ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement
High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194).
ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence
A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing.
EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases
A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes.