EU Data Act: Automating Your Data Portability and Sharing Register with n8n

The Data Act (EU Regulation 2023/2854) took effect on September 12, 2025 for most of its provisions, without the media attention GDPR or the AI Act received. Yet for any company operating connected devices, hosting cloud services for business customers, or negotiating a SaaS contract with a reversibility clause, this text is a direct game-changer: the right to access data generated by a connected product, an obligation to share it with a third party designated by the user, fee-free cloud portability, and a phased ban on unfair contract terms. As with GDPR back in 2018, the hard part isn't understanding the text — it's maintaining, over time, an up-to-date register of who asked for what, on which data, and how quickly you responded.

What the Data Act actually changes

The regulation distinguishes several obligations that don't all apply to the same companies:

• Access to data generated by a connected product — the user of a connected device (industrial machine, vehicle, IoT sensor, connected appliance) has the right to access the data it generates, and to have it transmitted directly to a third party of their choice (a competitor of the manufacturer, an integrator, a maintenance provider).
• Regulated B2B sharing — the data holder can't refuse a legitimate sharing request, but may charge reasonable compensation and negotiate technical terms, except for SME beneficiaries, who get more favorable conditions.
• Lock-in-free cloud portability — IaaS/PaaS/SaaS providers must let their business customers switch providers (or move back in-house) without prohibitive transfer fees, with a maximum two-month termination notice.
• Banned unfair contract terms — clauses that unilaterally prevent a customer (particularly an SME) from exercising its rights over its own data are void, mirroring how unfair terms are already regulated in consumer law.

Unlike NIS2 or the Cyber Resilience Act, which impose security and reporting obligations, the Data Act is primarily a traceability and response-time text: every access or sharing request must be handled "without undue delay" — a fuzzy standard that, in practice, is far easier to defend with a timestamp and a full history than with a after-the-fact declaration.

What research shows about practical implementation

A study by Shahlaei and Berente, An Analysis of European Data and AI Regulations for Automotive Organizations (2024), which examines how automotive-sector organizations must simultaneously handle GDPR, the AI Act, and the Data Act, points out that the main difficulty isn't understanding each text in isolation, but achieving operational consistency across obligations that partially overlap without fully aligning — exactly the situation of an SME already deep into a GDPR compliance effort that discovers the Data Act adds a distinct traceability layer over a different data scope. A second study, Measuring data access and re-use in the European Legal Framework for Data, published in Open Research Europe by Crepax and coauthors, uses the case of vehicle data to show that the gap between the theoretical right of access and its technical implementation stays wide as long as no structured system systematically tracks requests and response times. The common thread: without a reliable, timestamped register, declared compliance and actual compliance quietly drift apart.

Building the request register in n8n

The approach mirrors what we already covered for the GDPR record of processing activities and the GDPR audit trail on Supabase, adapted to the specifics of the Data Act:

1. Request intake — a hosted Form Trigger collects access or sharing requests (requester identity, product or service involved, type of data targeted, third-party recipient if applicable), whether they come from a customer or a partner. For requests received by email, an IMAP Email Trigger paired with an Information Extractor rebuilds the same structured fields from the raw message.
2. Automatic triage — an LLM chain with a Structured Output Parser classifies each request (connected-product access, B2B sharing, cloud portability) and flags whether it's a standard case or one requiring negotiation, following the same pre-analysis principle as our NIS2 and DORA compliance workflows: the workflow sorts and prepares, a responsible person validates the final response.
3. Timestamped logging — each triaged request is written to a dedicated Supabase table, following the audit logging workflow from the Compliance & Audit Pack (€149): requester, product or service, request type, date received, date answered, status.

Clocking "without undue delay"

The regulation doesn't always set a hard numeric deadline the way the CRA does with its 24 hours, but a "reasonable delay" standard that's far easier to defend when it's measured rather than estimated. A second workflow, modeled on the pack's automatic follow-up tracking, queries the table at a regular interval via a Schedule Trigger: it alerts the legal or technical team as soon as a request exceeds an internal threshold (say, 15 business days, calibrated to your practice and sector), and clearly separates requests handled on time from those that are lagging — a far more solid signal than a reminder buried in a shared spreadsheet. As with our other compliance workflows, an Error Workflow covers the case where the pipeline itself fails, so you never confuse "no requests received" with a silently broken tracking system.

Documenting proof of diligence

The pack's AI-generated summary report workflow, pointed at this table, produces an actionable register: number of requests received by type, average processing time, requests still open, and missed deadlines. That register — not an approximate recollection of email threads — is what stands as proof of diligence in the event of an audit or a dispute with a business customer invoking their right of access. For companies handling GDPR, NIS2, or DORA in parallel, our article on automating ISO 27001 / SOC 2 compliance evidence covers how to run several regulatory registers on the same Supabase base without mixing them up.

Common pitfalls

• Treating the Data Act as a simple GDPR extension — the scope (non-personal data included), the obligated parties (manufacturers and cloud providers, not just data controllers), and the redress mechanisms differ; a GDPR register doesn't automatically cover Data Act requests.
• Ignoring the cloud contracts angle because you don't manufacture connected devices — if you're a SaaS provider or a host for business customers, the fee-free portability obligations apply to you directly, regardless of any IoT product.
• Confusing automatic triage with a legal decision — the workflow sorts, clocks, and alerts; it never decides on its own whether a sharing request should be refused or under what conditions — that decision stays human, especially for financial compensation clauses.
• A register that starts too late — unlike a one-off incident report, the Data Act has applied continuously since September 2025; the earlier the register starts, the more defensible history it covers in the event of a retroactive audit.

Going further

The Data Act has been in effect since September 2025, and its most demanding provision for cloud providers (fee-free portability) is ramping up through 2027: better an imperfect but active register now than an improvised compliance scramble the day a lagging portability request lands on your desk. The Compliance & Audit Pack (€149) provides the timestamped audit trail, automatic follow-ups, and summary report to get started quickly; for companies also juggling GDPR, NIS2, or the CRA, the FlowKit Complete Bundle (€269) bundles every FlowKit pack, including the RAG Assistant Pack to make your own Data Act contractual documentation searchable as requests come in.