Article 95: Relationship with Directive 2002/58/EC

Article 95 requires you to prevent “double regulation” when your processing is already subject to sector-specific privacy obligations under the ePrivacy Directive (Directive 2002/58/EC). Operationally, you must identify which processing falls under electronic communications services obligations, document the overlap decision, and run a scoped control set that applies GDPR where it still governs and ePrivacy where it is the specific regime. (Regulation (EU) 2016/679, Article 95)

Key takeaways:

• Build and maintain a scope decision record for processing tied to publicly available electronic communications services.
• Map each relevant obligation to “ePrivacy-led” vs “GDPR-led” handling, then encode it into procedures and engineering requirements.
• Keep auditable evidence that you evaluated overlap and are not applying contradictory or redundant requirements.

“Article 95: relationship with directive 2002/58/ec requirement” is a coordination rule. It does not exempt you from GDPR, and it does not create new privacy duties by itself. It tells you that where an organization is already subject to specific obligations under the ePrivacy Directive for the same objective, GDPR should not impose additional obligations for those same matters in the electronic communications context. (Regulation (EU) 2016/679, Article 95)

For a Compliance Officer, CCO, or GRC lead, the practical problem is predictable: teams build cookie/telecom-style controls, then separately layer GDPR controls on top, creating conflicting notices, mismatched consent flows, duplicated logging, and unclear accountability. Article 95 is your hook to force one consistent control design and one accountable owner per requirement, with a written scope rationale.

This page focuses on rapid operationalization: scoping questions to ask, a decision matrix you can adopt immediately, the procedures and artifacts auditors will expect, and the most common failure modes (especially “we assumed ePrivacy covers everything” or “we ignored it and built two parallel programs”). Source text is limited to GDPR Article 95, so this guidance is framed as defensible implementation practice anchored to that article. (Regulation (EU) 2016/679, Article 95)

Regulatory text

GDPR Article 95 states that the GDPR “shall not impose additional obligations” on natural or legal persons for processing connected with providing publicly available electronic communications services in public communication networks in the EU, for matters where those persons are subject to specific obligations with the same objective set out in Directive 2002/58/EC. (Regulation (EU) 2016/679, Article 95)

Operator translation (what you must do):

1. Determine whether you conduct processing “in connection with” providing publicly available electronic communications services in public networks in the Union. (Regulation (EU) 2016/679, Article 95)
2. For that processing, identify whether a “matter” is already covered by specific obligations with the same objective under the ePrivacy Directive. (Regulation (EU) 2016/679, Article 95)
3. Document your decision so you can show you did not apply extra GDPR obligations where Article 95 says GDPR should not add to the sector-specific regime. (Regulation (EU) 2016/679, Article 95)

Plain-English interpretation (requirement-level)

Article 95 is a non-duplication requirement: if your organization is already regulated under ePrivacy for a particular objective in the electronic communications services context, you should not impose extra, parallel GDPR requirements for the same thing.

In practice, you operationalize this by:

• Defining scope boundaries (which services, products, and data flows are in the “electronic communications services on public networks” lane).
• Assigning the governing rule set per obligation area (ePrivacy-led where applicable; GDPR-led where ePrivacy is not the specific regime for the objective).
• Avoiding contradictory outcomes (for example, two consent prompts capturing different records for the same event, or separate retention rules for the same log).

Who it applies to (entity + operational context)

This matters most if you are any of the following:

• A provider of publicly available electronic communications services operating on public communication networks in the EU. (Regulation (EU) 2016/679, Article 95)
• A company that offers an app/service that includes communications features and partners with telecoms or network operators, where parts of processing are tightly coupled to those communications services. (Regulation (EU) 2016/679, Article 95)

It also affects you indirectly if:

• You are a third party supporting such providers (processors and sub-processors), because your customer will ask you to align your controls and contract language to their Article 95 scope decisions. (Regulation (EU) 2016/679, Article 95)

Operational context triggers (use as intake questions):

• Are we handling traffic, messaging, routing, call detail, or network-identifying data as part of delivering a publicly available communications service? (Regulation (EU) 2016/679, Article 95)
• Are we building consent/notice for communications-related tracking or access to device information that might be treated as “same objective” obligations under ePrivacy? (Regulation (EU) 2016/679, Article 95)
• Are engineering and product teams maintaining separate “GDPR privacy” and “ePrivacy/cookies/telecom privacy” workstreams without a single decision record? (Regulation (EU) 2016/679, Article 95)

What you actually need to do (step-by-step)

Step 1: Stand up a role-and-scope register for Article 95

Create a register entry specifically for Article 95 scope that includes:

• Business line/service name
• Controller/processor role per activity
• Data categories and systems in scope
• “Publicly available electronic communications services” determination
• “Public communication network” connection determination
• Decision owner and approval date
  This aligns with the practical control expectation to avoid role/scope ambiguity. (Regulation (EU) 2016/679, Article 95)

Output: “Article 95 Scope & Role Register” (versioned).

Step 2: Map processing activities to an “obligation owner” lane

Build a decision matrix per processing activity:

Processing activity	In connection with publicly available ECS on public networks?	Same objective already covered by ePrivacy obligations?	Governing lane	Required action
Activity A	Yes/No	Yes/No/Unclear	ePrivacy-led / GDPR-led / Legal review	Implement controls and evidence set

You are not trying to prove the content of ePrivacy here (that requires legal analysis). You are proving that you recognized the overlap question and routed it to the correct control owner for resolution. (Regulation (EU) 2016/679, Article 95)

Output: “Article 95 Overlap Decision Matrix” with disposition notes.

Step 3: Write a requirement-specific operating procedure (SOP)

Your SOP should be short and executable. Include:

• Trigger events: new product launch, new tracking technology, new communications feature, new third party integration, DPIA initiation, contract change request.
• RACI: legal counsel (interpretation), privacy/compliance (program owner), product (requirements), engineering (implementation), security (logging/access), procurement (third party clauses).
• Approvals: who signs off the overlap decision and any exceptions.
• Change control: how you revisit decisions after material changes.
  This converts Article 95 from policy language into repeatable execution. (Regulation (EU) 2016/679, Article 95)

Output: “Article 95 SOP: ePrivacy/GDPR Relationship Handling.”

Step 4: Embed checks into your delivery lifecycle

Operationalize via gates:

• Privacy intake form: include the Article 95 trigger questions above.
• Architecture review checklist: require an “overlap decision ID” before production release for in-scope services.
• Third party due diligence: add a question: “Does this third party process data in connection with publicly available electronic communications services on public networks, and what obligations apply?” (Regulation (EU) 2016/679, Article 95)

Output: Updated intake templates, review checklists, and third party questionnaires.

Step 5: Build and retain an auditable evidence packet

For each in-scope processing area, retain a packet that includes:

• Scope determination (what is in/out and why)
• Overlap decision matrix row(s)
• Implemented control evidence (screenshots/configs, test results, logs)
• Exceptions and remediation tickets
  This is the defensibility layer regulators and customers look for in practice. (Regulation (EU) 2016/679, Article 95)

Output: “Article 95 Evidence Packet” stored with your privacy compliance records.

Required evidence and artifacts to retain (audit-ready list)

• Article 95 Scope & Role Register (current + prior versions) (Regulation (EU) 2016/679, Article 95)
• Overlap Decision Matrix with approver identity and date (Regulation (EU) 2016/679, Article 95)
• Requirement-specific SOP + proof of adoption (training note, intranet publication record, sign-off) (Regulation (EU) 2016/679, Article 95)
• Product/privacy intake records showing Article 95 triage occurred (Regulation (EU) 2016/679, Article 95)
• Third party due diligence artifacts where relevant (questionnaires, DPAs/SCC addenda references, data flow diagrams) tied to the scope decision (Regulation (EU) 2016/679, Article 95)
• Exception register entries and corrective action tracking tied to Article 95 decisions (Regulation (EU) 2016/679, Article 95)

Common exam/audit questions and hangups

Auditors, regulators, and enterprise customers tend to ask:

• “Which services do you treat as publicly available electronic communications services on public networks?” (Regulation (EU) 2016/679, Article 95)
• “Show me where you decided ePrivacy obligations apply, and how you prevented duplicate requirements.” (Regulation (EU) 2016/679, Article 95)
• “Who approved the overlap determinations, and how do you revisit them after product changes?” (Regulation (EU) 2016/679, Article 95)
• “How do you ensure product teams don’t ship separate consent/notice experiences for the same objective?” (Regulation (EU) 2016/679, Article 95)

Hangups that slow reviews:

• Lack of a single “source of truth” decision record.
• Decisions living in email or counsel memos with no operational mapping.
• Conflicting control owners (privacy vs product vs network operations).

Frequent implementation mistakes (and how to avoid them)

1. Assuming Article 95 is an exemption from GDPR.
   Fix: Treat it as a coordination rule; keep GDPR governance in place, but document where GDPR should not add obligations for the same objective in the defined context. (Regulation (EU) 2016/679, Article 95)

2. No documented scope for “in connection with” communications services.
   Fix: Put the boundary in the scope register and link it to systems and data flows. (Regulation (EU) 2016/679, Article 95)

3. Running two parallel consent/notice implementations.
   Fix: Create one decision matrix and require an overlap decision ID in release gating. (Regulation (EU) 2016/679, Article 95)

4. Ignoring third party impact.
   Fix: Add Article 95 scoping questions to procurement intake; require third parties to disclose whether their processing supports publicly available communications services. (Regulation (EU) 2016/679, Article 95)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list case examples.

Risk still shows up in predictable ways:

• Regulatory friction: inconsistent positions across products or countries can trigger deeper supervisory scrutiny once an authority spots governance gaps around communications-related processing. (Regulation (EU) 2016/679, Article 95)
• Customer diligence failures: enterprise customers often ask how you handle overlapping privacy regimes; inability to produce a written overlap decision record looks like weak control design. (Regulation (EU) 2016/679, Article 95)
• Operational risk: duplicated requirements create conflicting engineering tickets, inconsistent records of consent/permissions, and avoidable incident complexity. (Regulation (EU) 2016/679, Article 95)

Practical execution plan (phased, no calendar-day promises)

Immediate phase: establish control ownership and scope

• Name an accountable owner for the Article 95 scope register and overlap decisions. (Regulation (EU) 2016/679, Article 95)
• Draft the scope register template and decision matrix template; start with your highest-risk communications products. (Regulation (EU) 2016/679, Article 95)
• Set a release gate: “No launch until Article 95 triage completed” for in-scope services. (Regulation (EU) 2016/679, Article 95)

Near-term phase: convert decisions into operating procedures

• Publish the Article 95 SOP with RACI, triggers, and required approvals. (Regulation (EU) 2016/679, Article 95)
• Update privacy intake, architecture review checklists, and procurement due diligence to capture Article 95 triggers. (Regulation (EU) 2016/679, Article 95)
• Build the evidence packet structure in your GRC repository so teams attach artifacts consistently. (Regulation (EU) 2016/679, Article 95)

Ongoing phase: test and sustain

• Perform periodic QA on a sample of launches and third party onboardings to confirm the overlap decision exists and matches actual implementation. (Regulation (EU) 2016/679, Article 95)
• Track exceptions and close them with remediation evidence (config changes, updated notices, corrected records). (Regulation (EU) 2016/679, Article 95)
• Keep prior versions of scope decisions to explain why your position changed after product or legal developments. (Regulation (EU) 2016/679, Article 95)

Where Daydream fits (without adding process overhead)

Daydream is useful here as a system of record for the role-and-scope register, the requirement-specific SOP, and the evidence packets tied to each overlap decision. That structure is what you need to answer diligence questions quickly and consistently without reconstructing decisions from scattered tickets and emails. (Regulation (EU) 2016/679, Article 95)

Frequently Asked Questions

Does Article 95 mean GDPR does not apply to electronic communications service providers?

No. It says GDPR should not impose additional obligations for matters where there are specific obligations with the same objective under Directive 2002/58/EC in the defined communications context. (Regulation (EU) 2016/679, Article 95)

What is the minimum artifact I need to be defensible on Article 95?

A written scope determination plus an overlap decision matrix that shows which processing is treated as ePrivacy-led vs GDPR-led, with an approver and version history. (Regulation (EU) 2016/679, Article 95)

How do I operationalize Article 95 if Legal owns ePrivacy analysis?

Put Legal as the approver for “same objective” determinations, but keep Compliance responsible for intake routing, gating releases, and evidence retention. The key is a repeatable workflow, not ad hoc emails. (Regulation (EU) 2016/679, Article 95)

We are a software provider (third party) to a telecom. Do we care about Article 95?

Yes, because your customer will ask how you scope communications-related processing and avoid duplicate or conflicting privacy obligations. Keep a mapped data flow and a documented role decision to support their program. (Regulation (EU) 2016/679, Article 95)

What does “shall not impose additional obligations” change for audits?

It changes what you must prove: not only that controls exist, but that you have a reasoned scope decision preventing redundant control stacks for the same objective in the electronic communications services context. (Regulation (EU) 2016/679, Article 95)

Can we skip documenting overlap decisions if we “don’t think ePrivacy applies”?

Don’t skip the record. Document the basis for why your processing is not “in connection with” publicly available electronic communications services on public networks, or why there is no same-objective ePrivacy obligation in play. (Regulation (EU) 2016/679, Article 95)