Artifact GuideEU

GDPR vs EU Data Act

The Data Act can create access and use rights for connected-product data, while GDPR governs any personal data within the same dataset or workflow.

GDPR prevails where the regimes conflict on personal-data protection. A Data Act access right does not remove the need for a GDPR role, lawful basis, notice, rights process, security control, and transfer assessment.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
5

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 25, 2026
Overview

The Data Act and GDPR can govern the same dataset. For Chapter II, identify the user, data holder, related service, and readily available data. The Data Act covers personal data and non-personal data, while GDPR applies to every personal-data operation in the workflow. Article 1(5) of the Data Act preserves data-protection law and makes it prevail in a conflict.

Side-by-side comparison

GDPR vs EU Data Act: privacy and data-access decisions

Use these rows to decide which regime applies, which actor must act, and which evidence can be shared without merging the legal tests.

Review all sources
First framework
GDPR

Covers personal-data processing, lawful basis, rights, transfers, security, controller and processor accountability, and records.

Second framework
EU Data Act

Covers access to and use of data from connected products and related services, business-to-business data terms, public-sector exceptional need, cloud switching, interoperability, and related duties.

Comparison row 1

Scope boundary

GDPR

Covers processing of personal data, including information relating to an identified or identifiable natural person.

EU Data Act

Covers data broadly, including connected-product and related-service data, and can apply to personal and non-personal data. Other chapters govern specified data-sharing, contract, public-sector, switching, and interoperability situations.

Operational implication

Run Data Act scope on the product, service, data, and relationship. Run GDPR scope on every personal-data operation within it.

Comparison row 2

Covered actors

GDPR

Requires role allocation for controllers, joint controllers, processors, representatives where relevant, DPO tasks where applicable, processor contracts, RoPA, security, breach, DPIA, and accountability records.

EU Data Act

Relevant Data Act actors include users of connected products or related services, data holders, third-party data recipients, enterprises receiving contractual terms, public-sector bodies making exceptional-need requests, and providers and customers of data-processing services.

Operational implication

Record Data Act and GDPR roles separately. A Data Act user may also be a GDPR data subject, controller, or neither, depending on the facts.

Comparison row 3

Trigger

GDPR

Requires a lawful basis for each processing purpose and accountability evidence for lawfulness, fairness, transparency, purpose limitation, minimisation, accuracy, storage limitation, integrity, and confidentiality.

EU Data Act

A Data Act right or duty to make data available does not erase GDPR conditions for personal-data processing. The Data Act preserves data-protection law and makes it prevail where the rules conflict.

Operational implication

Document both the Data Act access basis and the GDPR lawful basis before personal data is disclosed or reused.

Comparison row 4

Core obligations

GDPR

Requires transparent information and data-subject rights handling, including access, rectification, erasure, restriction, portability, objection, and automated-decision safeguards where applicable.

EU Data Act

Chapter II gives users rights to access data generated by connected products and related services and to have data made available to third parties, subject to conditions including limits on recipient use and trade-secret safeguards.

Operational implication

A single portal may accept both requests, but it must distinguish a GDPR data-subject request from a Data Act user or third-party access request.

Comparison row 5

Evidence record

GDPR

Requires a Chapter V transfer basis or safeguard when personal data is transferred to a third country or international organisation.

EU Data Act

The Data Act has safeguards against unlawful third-country government access to non-personal data held in the Union. Those safeguards are distinct from GDPR Chapter V mechanisms for personal data.

Operational implication

Classify the data first. Use GDPR transfer tools for personal data and the Data Act's non-personal-data safeguard where its conditions apply.

Comparison row 6

Timing and deadlines

GDPR

GDPR duties follow the processing lifecycle: lawful basis and notice before processing, DPIA before likely high-risk processing, rights clocks on request, and breach assessment after awareness.

EU Data Act

The Data Act generally applies from 12 September 2025. Article 3(1) design duties apply to covered products and related services placed on the market after 12 September 2026; other chapters have their own contract and switching transitions.

Operational implication

Track GDPR event-based clocks and Data Act application or transition dates in separate fields.

Comparison row 7

Enforcement

GDPR

The GDPR gives supervisory authorities powers to monitor application, handle complaints, investigate, and impose corrective measures, including suspension of data flows or administrative fines where needed.

EU Data Act

Member States designate one or more competent authorities for the Data Act and lay down penalties. Data-protection authorities remain responsible for monitoring personal-data protection where the Data Act involves personal data.

Operational implication

Route the privacy issue to the competent data-protection authority and the Data Act issue to the designated Data Act authority; coordinate when both are engaged.

Comparison row 8

Overlap and reuse

GDPR

The GDPR analysis can still run even when another EU data regime is also relevant, and the same factual workflow may need a separate lawfulness, transfer, or security review.

EU Data Act

The Data Act can add a user access or sharing right to the same data while restricting how a third-party recipient may use it.

Operational implication

Reuse shared facts, not legal conclusions. The Data Act access result and GDPR disclosure or reuse result must both permit the planned action.

Comparison row 9

Practical decision rule

GDPR

Start with GDPR if any personal data is present, and determine scope, lawful basis, rights, transfers, security, and accountability for the planned processing.

EU Data Act

If a connected-product, data-sharing, contract, public-sector request, cloud-switching, interoperability, or smart-contract fact pattern is present, identify the applicable Data Act chapter, role, duty, safeguard, and date.

Operational implication

Proceed only when both results allow the action: the Data Act result for access or use and the GDPR result for any personal-data processing.

Practical decision rule

How should teams use this comparison?

  • Identify the Data Act chapter, or other fact pattern, user, data holder or other actor, data in scope, right or duty, safeguards, and application date.
  • Classify the requested fields as personal, non-personal, or mixed and document which data is readily available, inferred, derived, content, or outside the request.
  • For personal data, confirm the GDPR role, purpose, lawful basis, notice, rights, processor, minimisation, security, retention, and transfer result before disclosure or reuse.
  • Record the release method, recipient, permitted purpose, trade-secret measures, contract restrictions, exceptions, notices, reviewer, and completion evidence.
  • Keep one factual inventory where useful, but issue separate GDPR and Data Act findings and require both to permit the planned action.
Section 1

Classify the product, data, people, and roles

The Data Act applies across several data-economy relationships. Its connected-product rules concern users, data holders, and third-party data recipients; other chapters address legally required business-to-business data access, unfair contractual terms imposed on enterprises, public-sector requests based on exceptional need, switching between data-processing services, interoperability, and smart contracts.

For a or related service, identify the user, data holder, available product data, readily available related-service data, intended third-party recipient, trade-secret issues, and whether any person is identifiable. If personal data is present, separately identify the GDPR controller, processor, purpose, lawful basis, transparency duties, and data-subject rights.

  • Do not assume all device data is personal data; assess whether the data relates to an identified or identifiable person.
  • Do not assume non-personal data is outside the Data Act; the regulation covers data broadly and contains specific protections for non-personal data.
  • Record the Data Act access or sharing right and the GDPR lawful basis as separate conclusions.
  • Apply trade-secret safeguards without using them as an automatic reason to reject every access request.
Section 2

Keep lawful basis, rights, and accountability separate from Data Act analysis

A Data Act workstream does not supersede GDPR Article 6 lawful-basis analysis, transparency duties, data-subject rights handling, processor terms, security controls, or breach documentation. Article 1(5) says Data Act Chapter II rights complement GDPR access and portability rights where users are data subjects, and data-protection law prevails in a conflict.

For controller and processor accountability, maintain a record that shows who determines purposes and means, who processes on documented instructions, which processor terms apply, and how data-subject requests reach the accountable controller.

  • For each data-use scenario, name the GDPR processing purpose before discussing data sharing.
  • Store lawful-basis reasoning beside privacy notice text and data-subject request handling steps.
  • Keep controller, joint-controller, and processor decisions tied to the actual purposes and means of processing.
  • Use RoPA entries to link purposes, categories of data subjects, categories of personal data, recipients, transfers, retention, and security measures.
Section 3

Preserve transfer safeguards when data-sharing crosses borders

If a data-access, recipient, vendor, cloud, support, or analytics path sends personal data outside the EU/EEA or to an international organisation, keep the GDPR Chapter V transfer analysis separate from any Data Act comparison.

The Data Act's safeguards against unlawful third-country government access concern non-personal data held in the Union. They do not replace the GDPR Chapter V mechanism required when a sharing or access path transfers personal data to a third country or international organisation.

  • Identify exporter, importer, roles, destination, categories of personal data, and onward-transfer points.
  • Attach the transfer mechanism, SCC module or adequacy basis, and any supplementary-measures assessment to the processing record.
  • Do not treat a Data Act access or sharing label as a substitute for GDPR transfer safeguards.
  • Reassess transfers when recipients, hosting locations, support models, subprocessors, or government-access risk facts change.
Section 4

Evidence to keep when both regimes may be discussed

Use one factual inventory with two legal layers. The Data Act layer should record the product or service, user, data holder, data in scope, access method, requested recipient, permitted purpose, trade-secret safeguards, contract terms, and applicable date. The GDPR layer should record the personal-data purpose, role, lawful basis, notice, rights, processor, security, retention, and transfer controls.

The Data Act entered into force on 11 January 2024 and generally applies from 12 September 2025. Its Article 3(1) design obligation applies to connected products and related services placed on the market after 12 September 2026. Separate transition rules apply to specified contract chapters and cloud switching charges.

  • GDPR scope note: personal data, processing operation, data subjects, purposes, recipients, and systems.
  • GDPR safeguard note: lawful basis, notice, rights route, security measures, breach workflow, retention, and transfer mechanism.
  • Role note: controller, joint controller, processor, subprocessors, and contract or arrangement evidence.
  • Data Act evidence: product and service scope, user and data-holder roles, access route, third-party request, trade-secret decision, contract rule, switching plan, and application date.
Section 5

Work a connected-product access request from facts to release

First identify the , related service, user, data holder, requested data, period, access method, and intended third-party recipient. Separate product data and related-service data from content, highly enriched inferred or derived data, and data that is not readily available to the data holder. Keep the technical evidence for that boundary, including where the data is generated, stored, retrieved, pre-processed, or transmitted.

Then classify every field as personal, non-personal, or mixed. If the user is the data subject, the Data Act right complements GDPR access and portability rights. If the user is not the data subject, do not disclose another person's personal data until a GDPR controller has identified a valid lawful basis and the other GDPR conditions are met.

Before release, record the recipient, purpose, format, metadata, security method, trade-secret status, agreed protection measures, prohibited uses, and any refusal or suspension ground. Trade-secret identification starts a safeguard process; it is not an automatic veto. A refusal needs the specific legal ground, supporting facts, notice, escalation route, and review owner.

  • Scope record: product placement, product or service function, user right, data-holder role, requested period, and applicable date.
  • Data boundary: raw, pre-processed, metadata, inferred, derived, content, personal, non-personal, and readily available status.
  • GDPR gate: data subject, controller, processor, purpose, lawful basis, transparency, rights, minimisation, security, retention, and transfer.
  • Release record: recipient, permitted purpose, access method, format, frequency, protection measures, contract terms, and completion evidence.
  • Exception record: trade secret, security concern, third-party rights, technical limit, refusal or suspension ground, reviewer, notice, and reassessment date.
Section 6

Test the overlap with concrete scenarios

A fleet operator requesting vehicle telemetry may be the Data Act user while drivers and passengers are GDPR data subjects. The operator's Data Act access position does not supply a GDPR lawful basis for every location, behavior, or in-cabin data point. The release record must separate the operator's access right from the controller's personal-data decision.

A manufacturer can be the data holder for product data and a GDPR controller for its own analytics, while processing other personal data for a customer on documented instructions. Record the role per purpose and data flow. One organization can hold several roles, but one label should not be stretched across all processing.

A cloud-switching project may engage the Data Act even without a . If customer exports contain personal data, keep the GDPR processor, security, deletion, return, subprocessor, and international-transfer controls alongside the Data Act switching plan. Article 32 safeguards for non-personal data do not replace GDPR Chapter V.

  • Vehicle or equipment data: separate the organizational user from each identifiable driver, operator, patient, worker, or bystander.
  • Third-party service: test the Data Act recipient restrictions and the GDPR controller or processor position for the recipient's intended purpose.
  • Edge data: document whether raw or pre-processed data was ever accessible, stored, retrievable, or externally transmittable.
  • Cloud switching: record export, continuity, interoperability, deletion, security, personal-data transfer, and transition-date evidence.
Primary sources

References and citations

eur-lex.europa.eu
Referenced sections
  • Primary source for the GDPR-first decision rule when personal data is involved.
"protection of personal data"
Related guides

Explore more topics

Does the EU GDPR apply outside the EU under Article 3?
A GDPR Article 3 territorial-scope FAQ covering EU establishment, non-EU targeting, monitoring in the EU, public-international-law cases, and Article 27 representatives.
EU GDPR Applicability Test for Products, Vendors, and Data Flows
A concrete GDPR scope test for personal data, controller and processor roles, EU establishment, EU targeting or monitoring, special-category and child data, transfers, vendors, and evidence.
EU GDPR Article 30 RoPA Intake Workflow
This GDPR Article 30 RoPA intake workflow helps capture controller and processor fields, owners, transfers, retention, security measures, and evidence before a processing activity goes live.
EU GDPR Article 6 Legal Bases FAQ
FAQ on the six Article 6 GDPR lawful bases, consent caveats, legitimate interests, public-task and legal-obligation limits, and Article 9 special-category data.
EU GDPR Automated Decision-Making and Profiling: Article 22 Scope, Safeguards, and Evidence
GDPR guide to profiling and Article 22 decisions: scope, transparency, lawful basis, DPIA triggers, safeguards, human intervention, challenge rights, and evidence.
EU GDPR Breach Notification 72 Hours: Article 33 and 34 workflow
Official source EU GDPR breach notification workflow covering awareness, 72-hour supervisory authority notices, processor escalation, high-risk data-subject communication, delay reasons, and evidence logs.
EU GDPR Breach Notification Workflow: 72-hour clock, risk assessment, and records
A concrete EU GDPR breach notification workflow for detecting and triaging incidents, starting the awareness clock, assessing risk, notifying authorities or data subjects, and keeping Article 33 records.
EU GDPR Checklist: scope, lawful basis, DSARs, DPIA, RoPA, transfers
This GDPR checklist helps review scope, lawful basis, notices, DSAR handling, DPIAs, RoPA, processor contracts, SCC transfers, breach notification, retention, security, and evidence.
EU GDPR Children and Special-Category Data Guide
GDPR guide to children's consent and special-category data: Article 8 national age variation, Article 9 conditions, transparency, DPIA triggers, safeguards, and evidence.
EU GDPR Compliance Checklist: scope, rights, DPIA, RoPA, transfers
Practical EU GDPR compliance guide for mapping scope, lawful basis, notices, data-subject rights, DPIAs, RoPA, processor terms, breaches, transfers, retention, security, and penalties.
EU GDPR Controller, Processor, and Joint Controller Roles
Classify GDPR controllers, processors, and joint controllers from actual decision-making, then document Article 26 allocation, Article 28 terms, instructions, and vendor evidence.
EU GDPR Data Subject Rights and DSAR Workflow
GDPR rights-request workflow for intake, identity checks, request scope, the one-month response clock, extensions, refusals, processor coordination, and evidence.
EU GDPR deadlines and compliance calendar
EU GDPR calendar for calculating rights-request deadlines, breach notification, DPIA and prior-consultation gates, transfer reviews, and retention checks.
EU GDPR DPIA and Prior Consultation Workflow
Screen high-risk processing, run a GDPR Article 35 DPIA, record mitigation, and identify when Article 36 prior consultation is required.
EU GDPR DPIA and risk management under Articles 35 and 36
EU GDPR DPIA guide covering Article 35 triggers and contents, CNIL and DPC PIA methods, residual risk, mitigation records, and prior consultation limits.
EU GDPR DSAR Exceptions: refusal, extensions, identity checks
FAQ on when EU GDPR controllers may extend, charge for, narrow, redact, or refuse a data subject access request under Articles 12 and 15.
EU GDPR DSAR Workflow: Intake, Clock, Rights, and Evidence
Run a GDPR DSAR workflow for intake, identity checks, rights scoping, one-month response timing, extensions, refusals, processor handoffs, and evidence records.
EU GDPR FAQ: scope, lawful basis, rights, DPIA, breaches, transfers
Direct EU GDPR FAQ answers on scope, controller and processor roles, lawful basis, data subject rights, DPIAs, breach notification, international transfers, and Article 83 fine tiers.
EU GDPR International Transfers and SCCs: Chapter V evidence guide
GDPR Chapter V guide to adequacy decisions, SCCs, transfer assessments, supplementary measures, Article 49 derogations, and EU-US DPF checks.
EU GDPR Lawful Basis and Consent Guide
Focused GDPR guide to Article 6 lawful bases, consent conditions, legitimate interests, special category data, withdrawal, and evidence records.
EU GDPR Lawful Basis and LIA Workflow for Article 6(1)(f)
Assess GDPR legitimate interests with a purpose, necessity, balancing, Article 21 objection, and evidence-record workflow based on Article 6(1)(f).
EU GDPR Lead Supervisory Authority and One-Stop-Shop
How GDPR main establishment, cross-border processing, Article 56 lead authority competence, and Article 60 cooperation fit together.
EU GDPR LIA Template for Article 6(1)(f)
This EU GDPR legitimate interests assessment template helps document Article 6(1)(f) purpose, necessity, balancing, safeguards, objection rights, and evidence.
EU GDPR penalties and fines: Article 83 tiers and evidence
EU GDPR penalties guide covering Article 83 fine ceilings, the EDPB calculation method, CJEU conditions, Article 58 powers, and evidence.
EU GDPR Processor Contracts and Vendor Management | Article 28 Evidence Guide
EU GDPR Article 28 guide for processor contracts, sub-processor controls, controller-processor role boundaries, vendor evidence, and SCC transfer clauses where applicable.
EU GDPR Record of Processing Activities Template: Article 30 RoPA Fields
Build a GDPR Article 30 record of processing activities with separate controller and processor fields for purposes, data categories, recipients, transfers, erasure time limits, and security measures.
EU GDPR Requirements: scope, rights, security, DPIA, RoPA, and transfers
Overview of core EU GDPR requirements covering scope, principles, lawful basis, notices, data-subject rights, processors, RoPA, security, breaches, DPIAs, and international transfers.
EU GDPR Retention and Erasure Schedule
Build an EU GDPR retention and erasure schedule with purpose-based periods, expiry actions, Article 17 decisions, recipient notices, and deletion evidence.
EU GDPR SCC Transfer Impact Assessment FAQ
FAQ on when SCC transfer impact assessments are needed, what Clause 14 records, and when supplementary safeguards or transfer suspension are required.
EU GDPR Transfer TIA and SCC Workflow
A GDPR workflow for checking adequacy, selecting SCC modules, documenting transfer impact assessments, and recording supplementary measures for third-country transfers.
EU GDPR Transparency Notices: Articles 12, 13 and 14
GDPR privacy-notice guide for Articles 12, 13, and 14: direct collection, other data sources, purposes, lawful bases, recipients, transfers, retention, rights, and timing.
EU GDPR vs Brazil LGPD: scope, legal bases, rights, incidents, and transfers
Compare EU GDPR and Brazil LGPD scope, actors, legal bases, rights timing, security incidents, international transfers, evidence, regulators, and penalties.
EU GDPR vs California CCPA: scope, rights, opt-outs, and evidence
Compare EU GDPR and California CCPA scope, roles, consumer rights, response times, sale and sharing opt-outs, risk assessments, contracts, transfers, and enforcement.
EU GDPR vs ePrivacy Directive: personal data, cookies, consent, and communications
Compare the EU GDPR and ePrivacy Directive for personal data processing, consent and lawful basis, cookies and terminal access, electronic communications, and parallel compliance.
EU GDPR vs UK GDPR: Scope, Rights, Transfers, and Evidence
Compare the EU GDPR and amended UK GDPR across scope, rights, automated decisions, accountability, breaches, regulators, and international transfers.
GDPR processor vs controller: role boundaries and evidence
Decide whether a party is a GDPR controller, processor, or joint controller using purpose-and-means tests, Article 28 terms, Article 26 arrangements, and Article 30 records.
GDPR vs EU AI Act: privacy controls for AI systems
Map the GDPR work that remains necessary when an AI system processes personal data, including lawful basis, notices, DPIAs, Article 22, rights, security, records, and transfers.
When does the EU GDPR require a DPIA?
Answer the EU GDPR DPIA threshold question with Article 35 triggers, high-risk criteria, supervisory-authority list checks, and DPIA content requirements.
When does the GDPR 72-hour breach notification clock start?
GDPR breach-awareness FAQ covering the Article 33 clock, processor escalation, delayed or phased notifications, risk assessment, and records to keep.