GDPR Article 6(1)(c): Legal Obligations as a Lawful Basis for Processing
A Scholarly Analysis for Advanced Practitioners
A practitioner-level reference deck for Data Protection Officers and Legal Counsel, examining the doctrinal foundations, operational mechanics, and enforcement landscape of Article 6(1)(c) GDPR — with pan-European (EDPB) focus and selected UK GDPR reference.
Scope of Analysis
- Doctrinal foundation and interpretive framework
- Sectoral applications across financial services, employment, healthcare, and corporate governance
- The necessity test — rigorous doctrinal analysis
- Intersection with Articles 5, 9, 13–14, 17, 21, 28, 30, 35, and 44–49
Governance, Operations & Enforcement
- 20 cross-cutting technical and organisational controls
- 10-stage process map from obligation identification to ongoing monitoring
- Key compliance artefacts and automation tools
- KPIs, industry trends (2025–2026), CJEU jurisprudence, and strategic synthesis
Doctrinal Foundation: The Text, Architecture and Interpretive Framework of Article 6(1)(c)
"Processing is lawful where it is necessary for compliance with a legal obligation to which the controller is subject." — Article 6(1)(c) GDPR
This deceptively concise formulation conceals significant interpretive complexity. The following structural analysis unpacks the key elements that advanced practitioners must master.
Structural Position & Constitutional Constraint
- Exhaustive and mutually exclusive: Article 6(1)(c) is one of six lawful bases; it is not a residual or catch-all basis — controllers must affirmatively identify the specific legal obligation before processing commences, not retrospectively
- Article 6(3) constraint: The legal obligation underpinning Article 6(1)(c) must itself be "laid down by Union law or Member State law to which the controller is subject" — a constitutional constraint requiring the enabling law to be accessible, foreseeable, and proportionate (Recital 41)
- Recital 41 elaboration: The legal obligation need not be an explicit statutory provision; clear common law obligations, regulatory instruments, codes of practice with statutory force, and court orders are capable of satisfying the requirement, provided the application of the law is foreseeable to those subject to it
Key Distinctions & Operative Constraints
- Distinction from Article 6(1)(e): Article 6(1)(c) applies to private controllers subject to legal obligations; Article 6(1)(e) applies to public authorities exercising official authority — the distinction is critical for data subject rights, particularly Article 21 (right to object), which does not apply to Article 6(1)(c) processing
- Necessity test: "Necessary" imports a proportionality analysis — processing must be the minimum required to achieve compliance; if the obligation can be satisfied without processing personal data, or with less data, Article 6(1)(c) cannot be invoked; this mirrors the CJEU's consistent interpretation across the GDPR
- No consent override: Where Article 6(1)(c) applies, the controller cannot substitute consent as the lawful basis, nor can the data subject withdraw consent to defeat the processing — a fundamental asymmetry that must be clearly communicated in privacy notices
Sectoral Examples: Where Article 6(1)(c) Operates in Practice
Article 6(1)(c) is the operative lawful basis across a broad matrix of regulated sectors. The following examples illustrate both the breadth of application and the sector-specific nuances practitioners must navigate.
Financial Services
- AML/KYC: EU Anti-Money Laundering Directives (4AMLD, 5AMLD, 6AMLD) and national transpositions (Germany's GwG, France's CMF) impose mandatory CDD, beneficial ownership verification, and transaction monitoring — all grounded in Article 6(1)(c)
- Tipping-off tension: The AML tipping-off prohibition simultaneously restricts transparency obligations that would otherwise apply under Articles 13–14 GDPR
- Tax reporting: DAC6, FATCA, CRS/AEOI, and national VAT legislation compel controllers to process and transmit personal data to tax authorities — Article 6(1)(c) is the sole appropriate basis; consent would imply impermissible optionality
- Sanctions screening: EU Regulation 2580/2001 and subsequent sanctions regimes impose obligations to screen customers and counterparties — the necessity test is readily satisfied given the mandatory nature of the obligation
Employment & Healthcare
- Employment law: National labour codes requiring payroll processing, occupational health records, workplace accident reporting (RIDDOR in UK; DGUV in Germany), and social security disclosure all engage Article 6(1)(c); the specific national law must be identified in the RoPA entry
- Healthcare: Mandatory reporting of notifiable diseases (Directive 2011/24/EU), pharmacovigilance obligations under Regulation (EU) 536/2014, and mandatory retention of medical records engage Article 6(1)(c) — typically combined with Article 9(2)(i) for special category data
Corporate Governance & Product Safety
- Corporate governance: Companies Act obligations to maintain shareholder registers, file accounts (Companies House, Handelsregister), and disclose directors' data in public filings engage Article 6(1)(c) — confirmed in CJEU C-710/23 (Ministerstvo zdravotnictvà II, April 2025) as capable of grounding disclosure in official documents, subject to proportionality
- Product safety: Obligations under the General Product Safety Regulation (EU) 2023/988 and sector-specific legislation (medical devices, food safety) to maintain traceability records and notify regulators and consumers of safety risks engage Article 6(1)(c)
The Necessity Test: Doctrinal Analysis and Common Misapplications
The Doctrinal Standard
The EDPB and national DPAs consistently hold that "necessary" means the processing must be objectively required to fulfil the legal obligation — it is not sufficient that processing is useful, helpful, or commercially advantageous alongside compliance. Controllers must demonstrate that no less privacy-intrusive means of compliance exists.
This standard is reinforced by the Charter of Fundamental Rights (Article 52(1)) and the data minimisation principle under Article 5(1)(c) GDPR, operating as independent constraints even where necessity is established.
CJEU Mousse v CNIL (C-394/23, January 2025)
The CJEU confirmed that collecting title/gender data for travel ticket sales was not necessary under Article 6(1)(b) or (c) — the legal obligation of issuing a travel ticket did not require collection of this data. The decision reinforces the strict necessity test and data minimisation as independent constraints on Article 6(1)(c) processing, applying proportionality analysis to data fields, not merely processing activities.
Common Misapplications — A Practitioner's Diagnostic
Scope Creep
Using Article 6(1)(c) to justify processing beyond what the underlying legal obligation strictly requires — e.g., retaining AML records for 10 years when the applicable law mandates only 5 years, or collecting additional data fields not required by the regulatory instrument. Excess processing requires a separate lawful basis.
Vague Obligation Identification
A vague reference to "regulatory requirements" or "industry practice" is insufficient. Controllers must point to the specific legal provision, regulatory instrument, or authoritative guidance. The EDPB and ICO both require the specific legal provision to be documented in the RoPA.
Conflating Contractual and Legal Obligations
Article 6(1)(c) does not apply to contractual obligations — these are governed by Article 6(1)(b). A controller cannot convert a contractual obligation into a legal one by incorporating statutory language into a contract. The distinction is critical and frequently misapplied in financial services and employment contexts.
Intersection with Other GDPR Articles: The Normative Web
Article 6(1)(c) does not operate in isolation. It is embedded within a normative web of intersecting GDPR provisions that simultaneously constrain and enable its application. The following analysis maps the key intersections advanced practitioners must navigate.
Article 5 — Principles
Article 6(1)(c) does not displace the Article 5 principles. Processing under a legal obligation must still satisfy: lawfulness, fairness and transparency (5(1)(a)); purpose limitation (5(1)(b)); data minimisation (5(1)(c)); accuracy (5(1)(d)); storage limitation (5(1)(e)); and integrity and confidentiality (5(1)(f)). The accountability principle (5(2)) requires documented evidence of all of these simultaneously.
Articles 13–14 — Transparency
Controllers must identify the specific legal provision in privacy notices. Where underlying law restricts transparency (AML tipping-off; tax investigation secrecy), Article 23 GDPR permits Member State restrictions — but only to the extent strictly necessary.
Article 17 — Erasure
Data subjects cannot exercise the right to erasure where processing is necessary under Article 17(3)(b). However, once the legal obligation ceases (e.g., retention period expires), the exemption falls away and data must be deleted — this transition must be automated.
Article 21 — Right to Object
The right to object does not apply to Article 6(1)(c) processing — a significant practical advantage for controllers. However, this limitation must be clearly communicated in privacy notices to avoid misleading data subjects.
Article 30 — RoPA
Each Article 6(1)(c) processing activity must be recorded in the RoPA with the specific legal obligation cited. A generic reference to "legal obligation" is insufficient per EDPB guidance. The RoPA must include: categories of data, recipients, retention periods, and security measures.
Article 35 — DPIA
Where Article 6(1)(c) processing involves large-scale special category data, systematic monitoring, or high risk, a DPIA is mandatory under Article 35(3). The legal obligation basis does not exempt controllers from DPIA requirements.
Article 9 — Special Category Data
Where the legal obligation requires processing of special category data, Article 6(1)(c) must be combined with an Article 9(2) condition — typically Article 9(2)(b) (employment law) or Article 9(2)(i) (public health). Both conditions must be documented in the RoPA and LBAR.
Articles 44–49 — International Transfers
Where Article 6(1)(c) processing requires third-country transfers (e.g., FATCA reporting to the US IRS), the transfer must independently satisfy Chapter V requirements. The legal obligation basis does not create an automatic transfer derogation. Article 49(1)(e) provides a narrow derogation for important public interest grounds.
20 Cross-Cutting Technical & Organisational Controls for Article 6(1)(c) Compliance
The following controls represent the minimum technical and organisational measures a well-governed organisation should implement to demonstrate accountability under Article 5(2) GDPR for all Article 6(1)(c) processing activities.
Controls 1–7: Foundation & Documentation
Legal Obligation Register
Version-controlled register of all legal obligations mapped to processing activities, data categories, retention periods, and Business Owners; reviewed annually and upon legislative change.
Lawful Basis Assessment Protocol
Documented decision-making protocol for assigning Article 6(1)(c), including a necessity test checklist, specific legal provision identification, and DPO/Legal Counsel sign-off before processing commences.
RoPA Integration
Every Article 6(1)(c) activity recorded in the Article 30 RoPA with specific legal provision cited. Automate RoPA updates when the Legal Obligation Register is amended.
Privacy Notice Management
System that automatically reflects changes to the legal obligation basis in customer-facing and employee-facing notices; must identify the specific legal provision, not merely "legal obligation."
Retention Schedule Automation
Automated data lifecycle management enforcing legally mandated retention periods; data deleted or anonymised immediately upon expiry of the retention period.
Data Minimisation Enforcement
Technical controls (field-level access controls, data masking, schema validation) preventing collection of data fields beyond those required by the specific legal obligation; periodic audits against the Legal Obligation Register.
Purpose Limitation Controls
Technical segregation (separate databases, access controls, data tagging) preventing Article 6(1)(c) data from being repurposed for commercial or analytical uses without a separate lawful basis.
Controls 8–14: Rights, Monitoring & Security
DSAR Triage Protocol
Triage process identifying Article 6(1)(c) processing activities and applying correct exemptions (legal professional privilege, regulatory investigation secrecy); automate flagging of DSARs touching Article 6(1)(c) data.
Erasure Request Handling
Automated workflows identifying Article 17(3)(b) exemptions for erasure requests; generate documented refusal notices citing the specific legal obligation and retention period.
Legislative Change Monitoring
Regulatory intelligence feeds (EUR-Lex, national gazette alerts, DPA guidance); change management process triggering review of affected processing activities within 30 days of any legislative amendment.
DPIA Trigger Assessment
Screening tool automatically assessing whether new or changed Article 6(1)(c) processing meets Article 35(3) high-risk thresholds; DPIA outcomes integrated into the RoPA.
Processor Due Diligence
Vendor risk management process verifying processors have compliant Article 28 DPAs, adequate security measures, and sub-processor controls; annual audits for high-risk processing.
International Transfer Assessment
Transfer impact assessment (TIA) for all Article 6(1)(c) cross-border data flows; document the Chapter V mechanism relied upon and assess whether the legal obligation itself creates a transfer derogation under Article 49.
Access Control & Audit Logging
RBAC limiting access to Article 6(1)(c) data to personnel with legitimate compliance need; immutable audit logs of all access, modification, and deletion events for the full legally mandated retention period.
Controls 15–20: Security, Reporting & Governance
Encryption & Pseudonymisation
Apply encryption at rest and in transit to all Article 6(1)(c) data; implement pseudonymisation where technically feasible; document in the RoPA security column.
Breach Notification Protocol
Breach response playbook for Article 6(1)(c) data accounting for Articles 33–34 GDPR notification obligations and sector-specific requirements (NIS2, DORA, PSD2).
Training & Awareness
Role-specific training covering specific legal obligations, data minimisation requirements, and prohibition on repurposing; training records maintained as accountability evidence.
Third-Country Law Assessment
Where the legal obligation originates from third-country law (US FCPA, FATCA), assess GDPR compatibility using the EDPB's conflicting laws guidance and the Schrems II framework; document the assessment and mitigating measures.
Regulatory Correspondence Management
Secure, auditable system for managing correspondence with regulatory authorities receiving Article 6(1)(c) data; ensure data transmitted is limited to what the specific request requires.
Compliance Attestation & Board Reporting
Annual compliance attestation by business unit owners; Board/Audit Committee reporting of compliance status as part of the Article 5(2) accountability framework.
How Large Organisations Operationalise Article 6(1)(c): Governance Architecture
Large organisations embed Article 6(1)(c) compliance within the Three Lines of Defence framework. The DPO's role under Articles 37–39 GDPR is advisory and monitoring, not operational ownership — this distinction is critical for accountability architecture.
Governance Roles & Ownership
- Legal Obligation Ownership: Each legal obligation is assigned a named Business Owner (e.g., Head of Tax for DAC6; Head of Financial Crime for AML) accountable for ensuring processing remains within the scope of the obligation and the RoPA entry is current
- Privacy Centre of Excellence (CoE): DPO, privacy counsel, privacy engineers, and data governance specialists; maintains the Legal Obligation Register, RoPA, and DPIA library; provides guidance to business units on Article 6(1)(c) assessments
- Privacy by Design integration: Article 6(1)(c) requirements embedded into project management and change management frameworks — any new system, process, or third-party engagement triggers a Privacy Impact Screening (PIS) before implementation
Oversight & Intelligence Infrastructure
- Regulatory horizon scanning: Dedicated regulatory intelligence functions or subscriptions (Refinitiv, LexisNexis Regulatory Compliance, Wolters Kluwer EHS) monitor legislative developments across all operating jurisdictions; changes triaged and assigned to the relevant Business Owner within defined SLAs
- Cross-functional governance committees: Data Governance Committee meets quarterly to review the Legal Obligation Register, approve new Article 6(1)(c) processing activities, and escalate high-risk issues to the Board; membership typically includes the DPO, General Counsel, CISO, CRO, and relevant business unit heads
- Accountability trail: All governance decisions are documented, version-controlled, and accessible to Internal Audit and supervisory authorities — the accountability principle under Article 5(2) requires a demonstrable, not merely asserted, compliance framework
10-Stage Process Map: From Receipt of Legal Obligation to Completion and Monitoring
Stages 1–5: Assessment & Documentation
- Stage 1 (Days 1–5): Legal/Compliance team identifies new or amended legal obligation; logged in Legal Obligation Register with jurisdiction, source instrument, effective date, data categories, and preliminary risk rating; DPO notified within 24 hours
- Stage 2 (Days 5–15): Business Owner and Privacy CoE conduct structured necessity assessment: identify specific data elements required; assess whether existing processing satisfies the obligation; apply data minimisation test; document in Lawful Basis Assessment Record (LBAR)
- Stage 3 (Days 10–15): DPIA screening checklist applied; if high-risk thresholds met (Article 35(3) or DPA blacklist), full DPIA commissioned; DPO reviews and signs off; if residual risk is high, prior consultation with supervisory authority under Article 36 initiated
- Stage 4 (Days 15–20): RoPA entry created or updated in GRC/privacy management platform; Business Owner reviews and approves; all mandatory fields populated including specific legal provision
- Stage 5 (Days 15–25): Privacy notices reviewed and updated; works council consultation may be required under national labour law for employee-facing processing; updated notices published and version-controlled
Stages 6–10: Implementation & Monitoring
- Stage 6 (Days 20–60): IT/Security implements technical controls — access controls, encryption, audit logging, retention automation, data segregation; Privacy Engineer validates implementation against LBAR and DPIA; Privacy by Design sign-off obtained before go-live
- Stage 7 (Days 20–45): Vendor risk management conducts third-party due diligence; Article 28 DPAs executed or updated; international transfer mechanisms verified; processor security assessments completed and documented
- Stage 8 (Days 30–50): Role-specific training delivered to all personnel involved; covers specific legal obligation, data minimisation requirements, DSAR handling, and breach reporting; training completion recorded in HR/LMS as accountability evidence
- Stage 9 (Day 60): Business Owner signs off Compliance Readiness Checklist; DPO issues compliance opinion; processing commences; post-implementation review scheduled for 90 days after go-live
- Stage 10 (Continuous): Automated monitoring of data volumes, retention compliance, access log anomalies, DSAR volumes, breach incidents; quarterly Business Owner attestation; annual DPO review; triennial Internal Audit deep-dive
Monitoring Compliance: Detailed Operational Framework
Ongoing monitoring is not a passive activity — it requires a layered architecture of automated tools, structured review cycles, and defined SLAs that together constitute the continuous assurance framework for Article 6(1)(c) compliance.
Continuous Automated Monitoring
Deploy privacy management platforms (OneTrust, TrustArc, DataGrail, GDPR Register) to provide real-time dashboards of Article 6(1)(c) processing activities. Automated alerts trigger when:
- Retention periods are approaching or have passed expiry
- Data volumes exceed minimisation thresholds
- Access anomalies are detected by SIEM tools
- DSAR response deadlines are at risk
- Legislative changes affect the underlying obligation
Regulatory Change Response SLAs
- Tier 1 — Material change to existing obligation: LBAR review within 15 days; RoPA update within 30 days; privacy notice update within 45 days
- Tier 2 — New obligation: Full Stage 1–9 compliance process within 60 days of effective date
- Tier 3 — Minor amendment: RoPA update within 60 days
Quarterly Compliance Attestation Cycle
Business Owners complete structured attestation confirming: (i) legal obligation remains in force and unchanged; (ii) processing activities remain within scope; (iii) data minimisation controls functioning; (iv) retention schedules enforced; (v) no material incidents. Attestations reviewed by DPO; issues escalated to Data Governance Committee.
Annual DPO Review
Comprehensive review of all Article 6(1)(c) processing activities: review of Legal Obligation Register against current legislation; assessment of continuing necessity; review of DPIA outcomes; processor compliance assessment; data subject rights handling assessment; Annual Privacy Report produced for Board.
Internal Audit Programme
Triennial deep-dive audit including: testing of access controls; sampling of DSAR responses; verification of retention schedule enforcement; review of processor DPAs; assessment of training completion rates. Audit findings reported to Audit Committee with management responses and remediation timelines.
Incident & Near-Miss Reporting
Privacy incident reporting capturing near-misses (data retained beyond legally mandated period; data shared with unauthorised recipient) as well as actual breaches. Near-miss data analysed quarterly for systemic control weaknesses; root cause analysis conducted for all material incidents. Supervisory authority engagement log maintained; DPO notified of all regulatory contact within 24 hours.
Key Artefacts Supporting Article 6(1)(c) Compliance
The accountability principle under Article 5(2) requires controllers to be able to demonstrate compliance. The following artefacts constitute the documentary evidence base that supervisory authorities will examine during investigations and audits.
Legal Obligation Register (LOR)
Structured, version-controlled register of all legal obligations mapped to processing activities, data categories, retention periods, and Business Owners. Includes: jurisdiction, source instrument, article/section reference, effective date, review date, and compliance status. The foundational document for all Article 6(1)(c) compliance.
Lawful Basis Assessment Record (LBAR)
Documented assessment recording: the specific legal obligation; necessity test analysis; data minimisation assessment; proportionality analysis; DPO's opinion; and Business Owner sign-off. The primary evidence of compliance with the accountability principle and the first document a DPA will request.
Record of Processing Activities (RoPA)
Article 30 RoPA entry for each Article 6(1)(c) activity with all mandatory fields. Automated RoPA tools (DataGrail, Cerivo, GDPR Register) reduce manual effort. AI-powered tools such as DataGrail's "Vera" agent automatically scan systems to identify processing activities and pre-populate RoPA fields, reducing manual effort by up to 70%.
DPIA & Privacy Notices
DPIA documents necessity, proportionality, risks, and mitigating measures; must be reviewed upon material change to processing or underlying legal obligation. Privacy notices (Articles 13–14) must disclose the specific legal obligation, data categories, retention periods, and inapplicability of the right to object; version-controlled and archived.
Article 28 DPAs & Retention Schedule
Compliant DPAs with all processors, including provisions on processing only on documented instructions, confidentiality, security measures, sub-processor controls, data subject rights assistance, breach notification, deletion/return of data, and audit rights. Retention schedule specifying legally mandated retention period, trigger event, and deletion/anonymisation method.
Training, Attestation & Correspondence Records
Training records (content, delivery date, attendees, assessment results) are accountability evidence under Article 5(2) and are typically requested by DPAs during investigations. Compliance attestation records from Business Owners reviewed and signed off by the DPO quarterly. Regulatory correspondence register logging all data transmissions to supervisory and regulatory authorities.
Automation of Article 6(1)(c) Compliance: Tools, Techniques and Emerging Approaches
The compliance burden of Article 6(1)(c) — particularly for large multinational organisations subject to complex matrices of intersecting legal obligations — has driven rapid adoption of AI-powered compliance automation. The following analysis maps the leading tools and emerging approaches.
Privacy Management & DSAR Automation
- Enterprise platforms: OneTrust, TrustArc, DataGrail, Cerivo, GDPR Register, Smart Integrity Platform automate RoPA maintenance, DPIA workflows, DSAR management, and breach notification
- AI-powered RoPA: DataGrail's "Vera" agent automatically scans systems to identify processing activities and pre-populate RoPA fields — reducing manual effort by up to 70%; Smart Integrity Platform claims up to 70% time saved through customised automation replacing manual compliance routines
- DSAR automation: AI-powered tools (DataGrail, Transcend, Mine) automatically identify and collate personal data across all systems; for Article 6(1)(c) data, automated triage identifies applicable exemptions and generates documented refusal or partial disclosure responses; response time reduced by up to 90%
Data Discovery & Retention Automation
- Data discovery and classification: Automated discovery tools (Varonis, Microsoft Purview, BigID) scan structured and unstructured data stores to identify personal data processed under Article 6(1)(c) obligations; classification tags enable automated enforcement of retention schedules and access controls; shadow data identified and remediated
- Retention automation: Data lifecycle management tools (IBM Guardium, Informatica, Veritas) enforce retention schedules by automatically archiving, anonymising, or deleting data upon expiry of legally mandated retention periods; automated deletion certificates generated as accountability evidence
- Audit log automation: SIEM platforms (Splunk, Microsoft Sentinel, IBM QRadar) aggregate and analyse access logs, generating automated alerts for anomalous access patterns; immutable audit logs maintained for the full retention period
Regulatory Intelligence Automation
Tools such as Refinitiv Regulatory Intelligence, Wolters Kluwer EHS, and LexisNexis Regulatory Compliance provide automated monitoring of legislative changes across multiple jurisdictions. AI-powered tools can now map legislative changes to affected processing activities in the Legal Obligation Register, triggering automated review workflows.
AI-Powered Legal Obligation Mapping
Emerging AI tools (Harvey AI, Luminance, Kira) can analyse legislative texts and regulatory guidance to automatically identify processing obligations and map them to data categories and processing activities. Increasingly used to accelerate the Stage 1–2 process in the compliance lifecycle. Practitioners must conduct a DPIA on any AI compliance tool before deployment and ensure outputs are subject to human review.
GRC Platform Integration
Leading organisations integrate privacy management platforms with broader GRC platforms (ServiceNow GRC, MetricStream, Archer) to provide a unified view of legal obligation compliance alongside NIS2, DORA, and the AI Act. This integration enables cross-framework control mapping and reduces duplication of effort — a critical efficiency driver as the legislative obligation landscape expands.
Key Metrics for Article 6(1)(c) Compliance Performance
The following KPIs constitute a robust performance measurement framework for Article 6(1)(c) compliance. Each metric should be reported quarterly to the Data Governance Committee and annually to the Board as part of the accountability framework under Article 5(2) GDPR.
LOR Currency Rate
Legal obligations reviewed within last 12 months. A rate below 90% indicates a systemic gap in regulatory horizon scanning.
RoPA Completeness
Article 6(1)(c) processing activities with complete, accurate, and current RoPA entries; all mandatory fields populated and legal provision cited.
LBAR Completion Rate
New or materially changed processing activities with completed and DPO-approved LBAR before processing commences. Below 95% indicates a Privacy by Design gap.
Retention Compliance
Article 6(1)(c) data deleted or anonymised within 30 days of legally mandated retention period expiry. Non-compliance is a significant enforcement risk.
DSAR Response Time
Average time to respond to DSARs involving Article 6(1)(c) data, including time to identify applicable exemptions, tracked separately from other DSAR categories.
Reg. Change Response
Average time from identification of a Tier 1 legislative change to completion of the full Stage 1–9 compliance process; reported against defined SLAs quarterly.
Additional Performance Indicators
- DPIA completion rate: 100% of high-risk Article 6(1)(c) processing activities with a completed and current DPIA; DPIAs reviewed within 3 years or upon material change
- Training completion rate: 95%+ of personnel handling Article 6(1)(c) data completing role-specific training within the last 12 months; tracked by business unit and legal obligation type
Risk Indicators
- Processor DPA coverage rate: 100% of processors with current, compliant Article 28 DPA; measured by vendor risk management system; gaps are a significant enforcement risk following the EDPB's October 2024 Opinion on processor obligations
- Privacy incident rate: Number of incidents (breaches and near-misses) per quarter tracked by type; target is zero material breaches; near-miss rate should trend downward over time as control maturity increases
Industry Trends Shaping Article 6(1)(c) Compliance in 2025–2026
The Proliferating Obligation Landscape
The volume of EU and Member State legislation imposing data processing obligations on private controllers has accelerated significantly. Since 2022, the following instruments have created new Article 6(1)(c) processing obligations:
- NIS2 (Directive 2022/2555) — ICT incident reporting and supply chain oversight
- DORA (Regulation 2022/2554, effective January 2025) — ICT risk management, incident reporting, and third-party oversight for financial entities
- EU AI Act (Regulation 2024/1689) — transparency, accuracy, and human oversight requirements for AI systems processing personal data
- CSRD — sustainability reporting obligations engaging personal data of employees, directors, and supply chain individuals
- AML Package (Regulation 2024/1624) — enhanced CDD, beneficial ownership, and transaction monitoring obligations
Organisations face an increasingly complex matrix of intersecting obligations requiring dynamic, cross-framework compliance architecture.
Enforcement Escalation & Financial Exposure
- €1.2 billion in GDPR fines issued by European supervisory authorities in 2025
- 22% year-on-year growth in personal data breach notifications
- CJEU C-383/23 (ILVA, February 2025): Fines calculated on the basis of the entire group's worldwide turnover — significantly increasing financial exposure of large multinationals for Article 6(1)(c) compliance failures
- Priority enforcement areas (EDPB 2024–2025 work programme): Lawful basis documentation, retention schedule enforcement, and processor oversight — the three core pillars of Article 6(1)(c) compliance
- Article 6(1)(c) compliance failures frequently appear as aggravating factors in enforcement decisions even where the primary violation is a different article
AI Act & GDPR Intersection
Where AI systems are used to fulfil Article 6(1)(c) obligations (AI-powered AML transaction monitoring, AI-assisted tax compliance), the AI Act's transparency, accuracy, and human oversight requirements must be satisfied alongside GDPR. The EDPB has confirmed that GDPR and the AI Act operate cumulatively, not alternatively.
AI-Powered Compliance Automation
AI agents can now autonomously maintain RoPAs, conduct DPIA screenings, respond to DSARs, and monitor legislative changes. However, AI tools used for compliance must themselves be GDPR-compliant (including Article 6(1)(c)) and AI Act-compliant. Practitioners should conduct a DPIA on any AI compliance tool before deployment.
Cross-Framework Control Convergence
Leading organisations are moving towards integrated GRC frameworks that map controls across GDPR, NIS2, DORA, ISO 27001, and the AI Act. Article 6(1)(c) compliance controls (access controls, audit logging, retention management, processor oversight) are increasingly recognised as foundational controls satisfying requirements across multiple frameworks simultaneously.
Member State Divergence
Despite GDPR's harmonisation objective, Member States continue to exercise Article 6(2) and (3) discretion to introduce more specific provisions — Germany's BDSG, France's Loi Informatique et Libertés, and Ireland's Data Protection Act 2018 all contain sector-specific provisions modifying Article 6(1)(c) application. Multinational organisations must maintain jurisdiction-specific compliance layers within their overarching framework.
Advanced Practitioner Considerations: Edge Cases, Tensions and Unresolved Questions
The following issues represent the doctrinal frontier of Article 6(1)(c) practice — areas where the law is unsettled, where competing obligations create genuine tension, or where common practitioner errors create material compliance risk.
Conflicting Legal Obligations Across Jurisdictions
Where a controller is subject to conflicting legal obligations from different jurisdictions (e.g., a US discovery order requiring disclosure of data that EU law prohibits transferring), Article 6(1)(c) cannot simultaneously ground both obligations. The controller must assess which obligation takes precedence under applicable conflict of laws rules and document the analysis. The EDPB's guidance on conflicting laws and Article 48 GDPR (transfers not authorised by Union law) are the primary reference points.
Voluntary Compliance with Non-Binding Regulatory Guidance
Where a controller voluntarily complies with non-binding regulatory guidance (e.g., ESMA guidelines, EBA recommendations), Article 6(1)(c) is not available as the lawful basis — the guidance does not constitute a "legal obligation." The controller must identify an alternative basis (typically Article 6(1)(f)) and conduct a legitimate interests assessment. This is a common error in financial services and requires careful documentation.
Anticipatory Processing Before Obligation Takes Effect
Where a controller processes personal data in anticipation of a future legal obligation (e.g., collecting data before a new AML regulation enters into force), Article 6(1)(c) is not yet available. The controller must identify an alternative basis for the anticipatory processing and transition to Article 6(1)(c) when the obligation takes effect. The transition must be documented and communicated to data subjects.
Article 6(1)(c) as a Shield Against Data Subject Rights
While Article 6(1)(c) restricts the right to erasure (Article 17(3)(b)) and the right to object (Article 21), it does not restrict all data subject rights. The rights of access (Article 15), rectification (Article 16), and restriction (Article 18) continue to apply. Controllers must implement processes to handle these rights even for Article 6(1)(c) data — a frequently overlooked obligation.
The "Controller Is Subject" Requirement — Processor Exposure
Article 6(1)(c) requires that the legal obligation applies to the controller — not to a third party. Where a processor is subject to a legal obligation (e.g., a cloud provider subject to a law enforcement data request), the processor cannot rely on Article 6(1)(c) as the lawful basis for processing the controller's data. The controller must assess whether the processor's compliance with the legal obligation is compatible with the controller's GDPR obligations.
Post-Brexit UK GDPR Divergence
Practitioners advising UK-established controllers must note that the UK GDPR (as amended by the Data (Use and Access) Act 2025) is diverging from EU GDPR in material respects. The ICO's guidance on legal obligation (last updated April 2026) reflects these divergences. Dual EU/UK compliance programmes must account for these differences — a single-framework approach is no longer safe for organisations operating across both jurisdictions.
Enforcement Landscape: Regulatory Decisions and CJEU Jurisprudence
CJEU Jurisprudence: 2025
- C-394/23 (Mousse v CNIL, January 2025): Collecting title/gender data for travel ticket sales was not necessary under Article 6(1)(b) or (c) — the legal obligation of issuing a ticket did not require this data; reinforces the strict necessity test and data minimisation as independent constraints; controllers must interrogate each data field against the specific legal obligation
- C-383/23 (ILVA, February 2025): GDPR fines calculated on the basis of the entire group's worldwide turnover, not just the infringing entity's — significantly increases financial exposure of large multinationals; has prompted widespread strengthening of group-wide compliance frameworks
- C-710/23 (Ministerstvo zdravotnictvà II, April 2025): Article 6(1)(c) and (e) can ground the disclosure of personal data in official documents, subject to proportionality; clarifies the interaction between GDPR and national freedom of information laws — public access to official documents can constitute a legal obligation for Article 6(1)(c) purposes
National DPA Enforcement
- Clearview AI (Netherlands AP, May 2024): €30.5 million fine for processing biometric data without a valid lawful basis; confirmed that Article 6(1)(c) cannot be invoked by a controller that is not itself subject to the legal obligation — Clearview's argument that law enforcement customers' legal obligations grounded its processing was expressly rejected; the Dutch AP found Clearview violated Article 5(1)(a) read in conjunction with Article 6(1) GDPR
- Rabobank (Netherlands, Court of Appeal): Bank's obligation to register credit default data in the Central Credit Information System (CKI) properly grounded in Article 6(1)(c); rejected Article 6(1)(f) as the only available basis — courts will uphold Article 6(1)(c) where the regulatory framework clearly mandates the processing
Aggregate Enforcement Trends
€1.2 Billion
GDPR fines issued by European supervisory authorities in 2025 — a record level reflecting sustained enforcement escalation across the EU since GDPR's entry into force.
22% YoY Growth
Year-on-year increase in personal data breach notifications to supervisory authorities in 2025 — a leading indicator of underlying compliance weaknesses in processing, including Article 6(1)(c) obligations.
Priority Sectors
Financial sector, healthcare, and technology account for the majority of enforcement actions. Article 6(1)(c) compliance failures frequently appear as aggravating factors in enforcement decisions even where the primary violation is a different article.
EDPB Work Programme
The EDPB's 2024–2025 work programme identified lawful basis documentation, retention schedule enforcement, and processor oversight as priority enforcement areas — the three core pillars of Article 6(1)(c) compliance. Coordinated enforcement actions are ongoing.
Strategic Imperatives for Advanced Practitioners
"Most GDPR enforcement actions punish drift, not absence: drifted inventories, manual privacy operations, unclear ownership, shadow AI and SaaS, and privacy run as a silo from cyber and third-party risk."
Treat Article 6(1)(c) as a Dynamic Obligation
The legal obligation landscape is changing faster than at any point since GDPR's entry into force. NIS2, DORA, the AI Act, CSRD, and the AML Package have all created new Article 6(1)(c) obligations since 2022. Organisations that treat their legal obligation register as a one-time exercise rather than a living document are systematically exposed to enforcement risk.
Invest in the Necessity Test as a Core Competency
The necessity test is the most frequently misapplied element of Article 6(1)(c). Practitioners must develop the analytical rigour to distinguish between what the legal obligation strictly requires and what is merely convenient or commercially advantageous. This requires close collaboration between legal counsel, the DPO, and business units — it cannot be delegated to a compliance checklist alone.
Integrate into Enterprise Risk Management
Privacy compliance must be embedded within the organisation's broader risk management framework — not operated as a silo. The convergence of GDPR, NIS2, DORA, and the AI Act means that Article 6(1)(c) controls are increasingly foundational controls that satisfy requirements across multiple frameworks. Integrated GRC platforms are the most efficient vehicle for achieving this convergence.
Leverage Automation Strategically
AI-powered compliance tools can dramatically reduce the manual burden — but they must themselves be GDPR and AI Act compliant. Conduct a DPIA on any AI compliance tool before deployment and ensure that tool outputs are subject to human review and accountability. The 70% time saving claimed by leading platforms is achievable, but only with appropriate governance.
Prepare for Enforcement Escalation & Engage Proactively
With €1.2 billion in fines in 2025 and a 22% increase in breach notifications, the enforcement environment is more demanding than at any point since GDPR's entry into force. Organisations must be able to demonstrate — not merely assert — compliance. Engage proactively with EDPB and national DPA guidance, participate in public consultations, and seek informal guidance from your lead supervisory authority on novel Article 6(1)(c) questions before processing commences.
The material within this site is provided for general guidance only and does not constitute legal, regulatory, or professional advice. Datari accepts no liability for any actions taken or not taken based on this content. Organisations should seek their own independent advice before making decisions.