EU ePrivacy Directive Confidentiality of Communications
Use Article 5 as a confidentiality control: protect communications and related against listening, tapping, storage, interception, or surveillance unless users consent or a lawful authorization applies.
Built for product, legal, privacy, telecom, security, analytics, and vendor teams that need evidence for message handling, metadata processing, device access, recording, and GDPR handoffs.
Article 5 requires Member States to protect the confidentiality of communications and related carried through public communications networks and publicly available electronic communications services. It does not give providers a general analytics, security, or product-improvement permission. First identify the communication, the users concerned, and each act of listening, tapping, storage, interception, surveillance, or recording. Then document user consent, storage necessary for conveyance, legally authorized business recording, or the specific national legislative measure relied on.
1
Section 1
What Article 5 Protects
The core rule is confidentiality of communications and related . The Directive defines a communication as information exchanged or conveyed between a finite number of parties through a publicly available electronic communications service, while traffic data is data processed for conveyance or billing.
For a product review, separate message content from and . Content can reveal the substance of an email, call, chat, or message. Traffic data and location data can reveal who communicated, when, through which route, on what device, and sometimes from where.
Article 5 is framed as a duty on Member States to secure confidentiality through national legislation. A provider therefore needs the applicable national implementation for case-specific questions such as recording notice, interception authority, remedies, and enforcement. The Directive supplies the EU baseline but does not itself settle every operational permission.
Inventory content, message attachments, call audio, chat text, and signaling information separately from analytics events.
Label used for transmission, routing, session management, billing, fraud detection, customer support, marketing of electronic communications services, or value-added services.
Treat other than as its own control set: anonymize it or collect consent for the value-added service, and document withdrawal and temporary refusal paths.
Do not collapse communications confidentiality into a GDPR-only lawful-basis check; ePrivacy may set the more specific rule for the communications step.
Explains why communications content and metadata require distinct protection and why the Commission viewed ePrivacy as complementary to GDPR.
metadata derived from electronic communications
2
Section 2
Permitted Processing Is Narrow
Article 5 prohibits listening, tapping, storage, and other interception or surveillance by anyone other than users unless the users concerned consent or the activity is legally authorized under the Article 15 framework. It also preserves technical storage that is necessary to convey a communication, but that carve-out does not turn into permission for product analytics, profiling, or secondary metadata reuse.
The Directive separately preserves legally authorized recordings made in lawful business practice to provide evidence of a commercial transaction or another business communication. The recording must fit that evidence purpose and the applicable national authorization; Article 5(2) is not a general call-recording permission. Document this route separately from user consent and technical transmission storage.
Approve conveyance storage only for the technical step needed to transmit, route, deliver, buffer, or retry the communication.
For recording, retain the transaction or business-communication evidence purpose, the national rule authorizing the recording, the recording trigger, any required notice or consent flow, the retention rule, access controls, and deletion path.
For , erase or anonymize when no longer needed for transmission unless a specific billing, interconnection, consent-based marketing, value-added service, dispute, or legal authorization path applies.
Restrict traffic-data access to personnel acting under provider authority and only where necessary for the permitted purpose.
Supports the rule against interception or surveillance, the technical conveyance storage and business-recording caveats, and the erasure, anonymisation, purpose, and personnel limits for traffic data.
listening, tapping, storage or other kinds
3
Section 3
Terminal Equipment Access Is Adjacent But Separate
Confidentiality reviews often find a second ePrivacy issue: software that stores information on, or gains access to information already stored in, a user device. After the 2009 amendment, Article 5(3) generally requires consent after clear and comprehensive information, except for technical storage or access solely to transmit a communication or what is strictly necessary to provide a service explicitly requested by the user.
The EDPB treats Article 5(3) as broader than cookies. The technical review should cover pixels, tracked URLs, identifiers, local storage, browser or app APIs, IoT reporting, and unique identifiers where code instructs the terminal equipment to send back stored or generated information.
Keep a separate evidence line for each cookie, SDK, pixel, tracking URL, local-storage item, app permission, IoT telemetry path, and identifier collection.
Record whether the item stores information, gains access to stored information, or does both; the operations do not need to be performed by the same entity.
Assess the two exceptions separately: storage or access solely for transmitting a communication, and storage or access strictly necessary for an information society service explicitly requested by the user.
Where device access produces personal data, document the Article 5(3) ePrivacy step and the GDPR basis for later analysis, enrichment, sharing, or retention.
Supports the broader technical scope covering information, terminal equipment, access, storage, pixels, local processing, IoT, and identifiers.
does not exclusively apply to cookies
4
Section 4
Consent and Legal Authorization Caveats
When consent is the control, it must match the ePrivacy operation being approved. Consent to a privacy policy, terms of service, or unrelated analytics category should not be used as evidence that users consented to interception, surveillance, traffic-data marketing, location-data value-added services, or terminal-equipment access.
When legal authorization is invoked, identify the national legislative measure. Article 15 permits restrictions of specified ePrivacy rights and obligations only where they are necessary, appropriate, and proportionate for its listed public-interest purposes. Record the authorizing law, permitted operation, data, duration, safeguards, and review route before relying on it.
For consent: retain the exact user-facing text, purpose, data categories, affected service, timestamp, withdrawal path, and proof that withdrawal is honored.
For traffic-data marketing or value-added services: document necessity, duration, user notice, consent, and withdrawal.
For location-data value-added services: document anonymization or consent, purpose, duration, third-party transfer notice, withdrawal, and temporary refusal controls.
For legal authorization: cite the specific legislative measure and keep it separate from product consent, business-recording, and technical-transmission rationales.
Provides GDPR consent-quality guidance used when ePrivacy relies on the GDPR-standard consent concept.
freely given, specific, informed and unambiguous
5
Section 5
Provider and Product Evidence
The evidence package should show how the service prevents unauthorized access to communications content and related . A policy statement alone does not show that the controls work. Engineering, security, privacy, support, vendor-management, and audit reviewers should be able to use the evidence.
For suppliers and embedded services, the key question is whether they can listen to, store, record, inspect, enrich, or receive communications data or terminal-equipment information. If they can, record the ePrivacy basis, contractual controls, technical controls, access logs, retention, and deletion evidence.
Can a provider reuse for product analytics under a GDPR legitimate-interest basis?
Not for the ePrivacy-governed traffic-data step if Article 6 of the ePrivacy Directive sets a narrower condition. The provider should first identify whether transmission, billing, interconnection, consent-based marketing of electronic communications services, a value-added service, dispute handling, or a legal authorization applies, then assess any later personal-data processing under GDPR.
Does Article 5 protect metadata as well as communication content?
Article 5 expressly covers communications and related . Commission ePrivacy materials also emphasize that metadata derived from electronic communications may reveal sensitive and personal information, so product evidence should cover both content access and metadata handling.
Configuration evidence for recording features, message inspection, logging, telemetry, diagnostics, spam or abuse detection, and customer-support access.
Provider controls for access authorization, role restrictions, encryption, key access, logging, incident handling, retention, anonymization, and deletion.
Vendor evidence showing whether processors, subprocessors, SDKs, communications APIs, analytics tools, or support platforms can access communications or related metadata.
Change triggers for new messaging features, call recording, AI summarization, endpoint telemetry, tracking pixels, app permissions, location features, or supplier changes.
Historical Commission explanatory material about the then-proposed ePrivacy Regulation and its intended distinction from GDPR personal-data protection for communications confidentiality and devices.
protects the confidentiality of electronic communications
6
Section 6
GDPR Interplay
The ePrivacy Directive particularises and complements GDPR in the electronic communications sector. Where ePrivacy contains a special rule for a specific operation, such as traffic-data processing or terminal-equipment access, the product cannot bypass that rule by selecting a broader GDPR lawful basis.
GDPR still matters. Personal-data processing that is not specifically governed by an ePrivacy special rule remains subject to GDPR obligations, including transparency, data-subject rights, processor controls, security, retention, and international-transfer analysis. The practical split is operation by operation: ePrivacy for the communications or device-access step, GDPR for personal-data processing that follows unless ePrivacy also specifically regulates it.
Identify the precise operation: conveyance, interception, recording, traffic-data use, location-data use, terminal-equipment storage or access, or later analysis.
Apply the ePrivacy special rule first where it governs that operation.
Apply GDPR to personal-data processing outside the ePrivacy special rule, including downstream profiling, analytics, storage, sharing, and rights handling.
Keep the enforcement-owner analysis country-specific only when supported by the applicable national implementing law.
States that the proposed ePrivacy Regulation was designed as lex specialis to GDPR for electronic communications data that qualify as personal data.
lex specialis to the GDPR
Recommended next step
Map Article 5 controls before launch or supplier approval
Sorena can help turn communications flows, metadata use, device access, recording features, and GDPR handoffs into cited evidence requests and implementation checks.
Supports the rule against interception or surveillance, the technical conveyance storage and business-recording caveats, and the erasure, anonymisation, purpose, and personnel limits for traffic data.
Supports evidence for communications confidentiality, traffic-data purpose limits, personnel restrictions, erasure, anonymization, and consent.
Historical Commission explanatory material about the then-proposed ePrivacy Regulation and its intended distinction from GDPR personal-data protection for communications confidentiality and device integrity.
Historical Commission explanatory material about the then-proposed ePrivacy Regulation and its intended distinction from GDPR personal-data protection for communications confidentiality and devices.
"protects the confidentiality of electronic communications"