Article 94: Repeal of Directive 95/46/EC
Article 94 requires you to treat Directive 95/46/EC (the old EU Data Protection Directive) as repealed from 25 May 2018 and to anchor your privacy program in the GDPR, not the Directive. Operationally, you must remove legacy “Directive-based” references from policies, contracts, and control mappings, and document that GDPR is your governing standard for EU personal data processing. (Regulation (EU) 2016/679, Article 94)
Key takeaways:
- Replace any “95/46/EC compliance” claims, mappings, or contract language with GDPR-based obligations and references.
- Keep a role-and-scope register that shows where GDPR applies, and who is controller vs. processor for each processing context.
- Retain an evidence packet proving you completed the repeal-impact sweep and remediated legacy references.
“Article 94: repeal of directive 95/46/ec requirement” looks simple because it is short. The operational risk is not in the repeal itself; it is in the residue it leaves behind. Many organizations still have legacy policy language, templates, and third-party contracting positions that reference the repealed Directive 95/46/EC, or that rely on assumptions and control mappings built for the Directive era.
A regulator, customer, or procurement counterparty typically won’t ask you to “prove you know the Directive is repealed.” They will ask why your privacy notice, DPA, records of processing, or internal control framework still references outdated legal authority, or why your control owners are executing a “Directive checklist” rather than GDPR controls. That mismatch creates credibility risk, slows deals, and complicates audits.
This page translates Article 94 into fast, requirement-level execution: what to change, who owns it, what evidence to retain, and how to avoid common mistakes. The goal is a clean, defensible posture: GDPR is your governing basis for EU personal data processing, and your documentation set consistently reflects that. (Regulation (EU) 2016/679, Article 94)
Regulatory text
Text (excerpt): “Directive 95/46/EC is repealed with effect from 25 May 2018.” (Regulation (EU) 2016/679, Article 94)
Operator interpretation:
This is a legal “switch-over” requirement. From the effective date, your organization should not position its EU personal data compliance program as being based on Directive 95/46/EC. Your operational obligation is to ensure your policies, procedures, templates, control mappings, and external statements reflect the GDPR as the governing framework for EU personal data processing. (Regulation (EU) 2016/679, Article 94)
Plain-English interpretation (what this means in practice)
- The Directive is no longer the governing EU-wide privacy instrument for personal data processing; GDPR is.
- If you have artifacts that still cite 95/46/EC as the primary basis (or imply that compliance with the Directive is sufficient), you should update them to GDPR terminology and obligations.
- This is a documentation and governance hygiene requirement with real downstream effects: incorrect references can create contractual ambiguity, confuse control owners, and undermine audit readiness.
Who it applies to
Entity scope:
Any organization that processes EU personal data in a context where the GDPR applies, including organizations acting as controllers or processors. The key operational driver is your processing role because the obligations you implement and the contract positions you take differ by controller vs. processor. (Regulation (EU) 2016/679)
Operational contexts where Article 94 becomes “real work”:
- Policy governance: privacy policy, internal data protection policy, retention policy, incident response playbooks referencing old law.
- Third-party risk and contracting: Data Processing Addendums (DPAs), supplier security schedules, SCC addenda, procurement templates, MSA privacy clauses.
- Compliance mapping: GRC control libraries, audit programs, DPIA templates, RoPA fields, training materials.
- External statements: website privacy notices, security/compliance one-pagers, RFP responses, trust portals.
What you actually need to do (step-by-step)
Use this as a requirement-specific operating procedure. Keep it tight, assign owners, and produce an evidence packet at the end.
Step 1: Set governance and decision ownership
- Name an accountable owner (typically Privacy Counsel, DPO, or CCO/GRC lead) for “repeal hygiene” across the documentation set.
- Define the scope of artifacts you will review: policies, standards, procedures, templates, playbooks, contracts, training, customer-facing content, and GRC mappings.
- Decide the standard language your org will use going forward (for example: “GDPR” and “Regulation (EU) 2016/679,” and avoid “Directive 95/46/EC compliant”).
Output: a short decision record that states: “For EU personal data processing, GDPR is the governing compliance framework; Directive 95/46/EC references must be removed or clearly marked as historical.” (Regulation (EU) 2016/679, Article 94)
Step 2: Build or update your GDPR role-and-scope register
Create a register that answers, per product/system/process:
- Are you acting as controller, processor, or joint controller?
- What data categories and data subjects are involved?
- Which systems process the data?
- Which third parties receive, host, or access the data?
- Which documents/templates govern that activity (DPA, notice, internal SOP)?
This register is your anchor for consistent updates across teams. It prevents the most common failure mode: policy updates that never reach contracting, engineering, or support.
Output: GDPR role-and-scope register with owners and last review date. (Regulation (EU) 2016/679)
Step 3: Run a “legacy reference sweep” across artifacts
Perform a targeted search and review for:
- “95/46/EC”, “Directive 95/46”, “Data Protection Directive”, “DPD”
- Phrases like “compliant with the EU Data Protection Directive” in marketing or RFP collateral
Prioritize documents that are reused or externally shared:
- DPA templates and standard clauses
- Privacy notice(s)
- Customer security packs and procurement responses
- Control framework mappings and audit workpapers
Output: a remediation log (artifact, location, owner, finding, severity, fix, completion). Keep before/after versions or redlines.
Step 4: Remediate with approved replacement language
Remediation is not just “search and replace.” For each artifact:
- Replace legal references to the repealed Directive with GDPR references where appropriate.
- Validate role language aligns with your actual operating model (controller vs. processor) from the role-and-scope register.
- Confirm downstream clauses still make sense (for example, DPA instructions, subprocessor terms, assistance obligations). Article 94 itself is about repeal, but your edits must not accidentally change substantive commitments.
Practical example (contracting):
- If a template says “Processor shall comply with Directive 95/46/EC,” change it to a GDPR-appropriate reference and ensure the rest of the DPA matches your processor obligations under GDPR-aligned contracting positions. (Regulation (EU) 2016/679)
Step 5: Operationalize a “no-legacy-law” gate
Add a lightweight check to prevent regression:
- Contracting gate: Legal/Privacy approves any new DPA template or privacy clause changes.
- Policy gate: GRC approves updates to privacy-related policies and ensures citations are current.
- Customer-facing gate: Trust/Marketing cannot publish privacy statements without Privacy review.
Output: documented review workflow (ticketing, approvals, and version control).
Step 6: Evidence packaging and recurring cadence
Bundle the proof you did the work:
- decision record
- role-and-scope register snapshot
- remediation log
- samples of updated artifacts
- exceptions (what you could not change and why) and remediation plan
Keep this packet current. In practice, it becomes a standard response to customer diligence questions about GDPR alignment.
Required evidence and artifacts to retain
Minimum defensible set:
- Requirement-specific SOP with named owners and triggers (new template, contract refresh, policy update, acquisition, new product).
- GDPR role-and-scope register (controller/processor role, data categories, systems, third parties).
- Legacy reference sweep results (queries used, repositories reviewed, date, reviewer).
- Remediation log with ownership and completion evidence.
- Version-controlled artifacts (redlines, approvals, final versions).
- Exception register for any legacy references that must remain temporarily (for example, a locked customer contract) with timeline and compensating controls.
Common exam/audit questions and hangups
Expect diligence reviewers to probe consistency and governance, not Article 94 semantics.
- “Show me where you document that GDPR is the governing framework for EU personal data processing.” (Regulation (EU) 2016/679, Article 94)
- “Do any customer-facing statements still claim compliance with Directive 95/46/EC?”
- “Which teams can publish templates or privacy language, and how do you prevent outdated references?”
- “How do you know whether you are controller or processor for product X, and where is that decision documented?” (Regulation (EU) 2016/679)
Hangups that stall audits:
- Multiple, conflicting templates owned by different teams.
- Privacy notices updated, while DPAs and RFP answers remain stale.
- No single system of record for role determinations.
Frequent implementation mistakes (and how to avoid them)
-
Mistake: Treating Article 94 as “no action required.”
Fix: Do the sweep anyway. Your risk is stale artifacts, not the repeal date. -
Mistake: Updating policies but not contracts and customer collateral.
Fix: Put contracting and external statements in the same remediation log, with owners outside Legal (Procurement, Sales Ops, Marketing). -
Mistake: Replacing citations without validating controller/processor posture.
Fix: Require a role check against the role-and-scope register before final approval. -
Mistake: No regression control.
Fix: Add the “no-legacy-law” gate to publishing and template updates.
Enforcement context and risk implications
No public enforcement cases were provided for this specific article in the source catalog. Treat Article 94 as a defensibility requirement: the exposure is indirect.
- Regulatory credibility risk: outdated legal references can make your program look unmanaged.
- Contract risk: incorrect references can create ambiguity during negotiations and incident response.
- Operational risk: teams may follow obsolete checklists, causing missed GDPR-required steps in adjacent areas (for example, role-specific obligations). (Regulation (EU) 2016/679)
Practical execution plan (30/60/90-day format, without assuming durations)
Use these as phases you can map to your internal planning cadence.
First phase: Immediate stabilization
- Assign owner and publish the decision record for GDPR-as-governing-standard. (Regulation (EU) 2016/679, Article 94)
- Inventory high-risk artifacts: DPA templates, privacy notice, security/compliance pack, RFP library, policy index.
- Stand up a remediation log and start tracking findings and owners.
Second phase: Near-term remediation
- Complete the legacy reference sweep across repositories (contract templates, policy platform, CMS/website copy, shared drives, GRC tool).
- Update and approve priority artifacts; capture approvals and version history.
- Create or update the GDPR role-and-scope register; align with system inventory and third-party list. (Regulation (EU) 2016/679)
Third phase: Operationalization and regression control
- Implement publishing/templating gates (Legal/Privacy/GRC approvals).
- Add a recurring review trigger (template updates, new products, new subprocessors, M&A).
- Package the evidence binder so Sales and Security can answer diligence requests quickly.
How Daydream fits (practitioner use)
Most teams fail Article 94 operationalization because the work spans multiple content surfaces: policies, contracts, GRC mappings, and customer-facing responses. Daydream is useful as the system to track requirement ownership, attach the evidence packet (decision record, sweep results, remediation log), and keep the role-and-scope register tied to systems and third parties so updates don’t drift.
Frequently Asked Questions
Does Article 94 require a specific policy or notice to be published?
Article 94 itself states the repeal of Directive 95/46/EC from 25 May 2018. (Regulation (EU) 2016/679, Article 94) The operational expectation is that your documentation set does not rely on, or present, the repealed Directive as your compliance basis.
We still see “95/46/EC” in older customer contracts. Is that automatically noncompliant?
Article 94 establishes the repeal date. (Regulation (EU) 2016/679, Article 94) For legacy contracts you cannot amend quickly, keep an exception record and ensure your current operating procedures and templates are GDPR-based.
What’s the fastest way to operationalize this requirement across third parties?
Start with your DPA template and procurement clause library, then roll changes into your third-party onboarding checklist so new agreements cannot introduce Directive references. Anchor the work in a role-and-scope register so controller/processor language stays consistent. (Regulation (EU) 2016/679)
Do we need to retrain staff on Article 94?
You generally do not need “Article 94 training” as a standalone topic. Train the teams who publish templates and customer statements to avoid legacy law references, and document the review gate so the behavior is repeatable.
How do we prove compliance in an audit without enforcement guidance?
Produce an evidence packet: decision record, artifact inventory, sweep results, remediation log, and updated documents under version control. Tie the packet to your GDPR role-and-scope register to show the change is operational, not cosmetic. (Regulation (EU) 2016/679)
If our global privacy policy references “EU Data Protection Directive,” should we remove it?
Yes, if the reference implies it is a current governing standard for EU personal data processing. Article 94 repeals Directive 95/46/EC effective 25 May 2018. (Regulation (EU) 2016/679, Article 94) Keep any historical references clearly labeled as historical, or remove them if they create ambiguity.
Frequently Asked Questions
Does Article 94 require a specific policy or notice to be published?
Article 94 itself states the repeal of Directive 95/46/EC from 25 May 2018. (Regulation (EU) 2016/679, Article 94) The operational expectation is that your documentation set does not rely on, or present, the repealed Directive as your compliance basis.
We still see “95/46/EC” in older customer contracts. Is that automatically noncompliant?
Article 94 establishes the repeal date. (Regulation (EU) 2016/679, Article 94) For legacy contracts you cannot amend quickly, keep an exception record and ensure your current operating procedures and templates are GDPR-based.
What’s the fastest way to operationalize this requirement across third parties?
Start with your DPA template and procurement clause library, then roll changes into your third-party onboarding checklist so new agreements cannot introduce Directive references. Anchor the work in a role-and-scope register so controller/processor language stays consistent. (Regulation (EU) 2016/679)
Do we need to retrain staff on Article 94?
You generally do not need “Article 94 training” as a standalone topic. Train the teams who publish templates and customer statements to avoid legacy law references, and document the review gate so the behavior is repeatable.
How do we prove compliance in an audit without enforcement guidance?
Produce an evidence packet: decision record, artifact inventory, sweep results, remediation log, and updated documents under version control. Tie the packet to your GDPR role-and-scope register to show the change is operational, not cosmetic. (Regulation (EU) 2016/679)
If our global privacy policy references “EU Data Protection Directive,” should we remove it?
Yes, if the reference implies it is a current governing standard for EU personal data processing. Article 94 repeals Directive 95/46/EC effective 25 May 2018. (Regulation (EU) 2016/679, Article 94) Keep any historical references clearly labeled as historical, or remove them if they create ambiguity.
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream