Artifact GuideEU

EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2G Exceptional Need Requests

Respond to Chapter V requests fast-without over-sharing, breaking GDPR, or leaking trade secrets.

A playbook for data holders: validate the request, scope the dataset, apply safeguards, calculate compensation, and create an audit trail.

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 23, 2026

Updated

Feb 23, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 23, 2026

Updated Feb 23, 2026

Overview

EU Data Act Chapter V is a narrow, high stakes mechanism: a public sector body (and certain EU bodies) can request data from a private data holder only when an 'exceptional need' is demonstrated and the request is duly reasoned. Your goal is to comply without creating new risks: minimise the dataset, document the legal basis and purpose, apply trade secret and GDPR safeguards, and keep an evidence trail that shows proportionality and security.

Section 1

1) The 'exceptional need' test (Article 15) - two lanes, different rules

Article 15 creates two distinct lanes. Treat them differently from day one because they have different constraints and compensation expectations.

A strong response starts by forcing the request into one of the lanes and documenting why.

Lane A (public emergency): data is necessary to respond to a public emergency and cannot be obtained by alternative means in time under equivalent conditions
Lane B (non-emergency statutory task): limited to non-personal data; requester must show a specific public-interest task set by law and that all other means were exhausted (including offering market rates to purchase data)
SME carve-out: Lane B does not apply to microenterprises and small enterprises

Section 2

2) What a 'complete request' must contain (Article 17) - your acceptance checklist

Article 17 is your control: it specifies what the requester must include. Use it as an intake form and do not proceed until the request is complete and proportionate.

Missing request fields almost always translate into operational risk later.

Exact data + metadata requested (granularity, volume, and frequency must be proportionate)
Purpose, intended use, duration of use, and whether third parties will process the data
If personal data: which safeguards are required (e.g., pseudonymisation) and whether anonymisation can be applied by the data holder
Erasure expectations (when the data should be erased by all parties) and security measures for transfer/storage
Justification for selecting you as the data holder and identification of any planned onward sharing
Deadlines: when the data must be made available and the deadline by which you may decline or seek modification

Section 3

3) Data holder triage workflow - a 72-hour playbook

Even if the request allows more time, your internal window for safe decision-making is short. Use a standard playbook so you can respond under pressure and still be proportionate and secure.

Treat the output as a case file: request versioning, decisions, approvals, dataset definition, and delivery evidence.

Validate: requester identity, legal basis, and which Article 15 lane applies (A emergency vs B non-emergency)
Minimise: define dataset, time window, and metadata strictly necessary; document exclusions and why
Safeguard: trade secret marking + confidentiality controls; GDPR safeguards; secure transfer; access restriction
Compensation: calculate costs (including anonymisation/pseudonymisation/aggregation/technical adaptation) and margin where applicable
Deliver + close: delivery receipt, integrity checksums, retrieval window, deletion milestones, and final closure memo

Section 4

4) Trade secrets and confidentiality - 'share, but protect'

Chapter V explicitly expects trade secret protection. Requests must respect the legitimate aims of the data holder and commit to safeguards, and disclosure should only occur with appropriate technical and organisational measures in place.

In practice: your data package must include a confidentiality and use protocol, not just a file export.

Mark trade secret content in the dataset and metadata; document necessity and proportionality
Limit onward sharing and require equivalent safeguards for any third party receiving data
Use secure transfer + storage, strict access control, and audit logs that prove who accessed what and when

Section 5

5) Compensation (Article 20) - when it's free and when it's paid

Compensation differs by lane. For emergencies, the data necessary to respond is provided free of charge (subject to the Chapter V rules). For non-emergency statutory tasks, data holders are entitled to fair compensation that covers technical and organisational costs plus a reasonable margin.

Build a repeatable cost model now (time, compute, anonymisation, engineering, security) so you can respond quickly and defend your numbers.

Emergency: data necessary to respond to a public emergency is provided free of charge; you may request public acknowledgement
Non-emergency: fair compensation covers costs (including anonymisation/pseudonymisation/aggregation/technical adaptation) and a reasonable margin; be ready to explain the calculation basis
Dispute path: requester can complain to the competent authority if it disagrees with compensation level

Section 6

6) Sharing with researchers and statistics bodies (Article 21) - keep purpose control

The requester may share Chapter V data with research organisations or statistical bodies under conditions, including purpose compatibility and restrictions designed to prevent preferential access by commercial undertakings.

Operationally: require notification details and capture them in your case file.

Confirm purpose compatibility and recipient eligibility conditions
Ensure onward recipients follow the same security/confidentiality obligations as the requester
Log notifications: identity, purpose, usage period, and safeguards for each onward disclosure

Section 7

Evidence pack - what to keep for audits and disputes

Because Chapter V is exceptional and sensitive, expect scrutiny. Keep a complete evidence pack: decision basis, minimisation rationale, safeguard implementation, compensation calculation, and delivery receipts.

Use immutable logs and a consistent case file structure so you can answer regulator or counterparty questions quickly.

Request packet: original request + clarifications + final accepted scope and deadlines
Decision memo: exceptional need lane, proportionality, and safeguards (trade secrets + GDPR)
Dataset manifest: schema, transformations, minimisation notes, and access restrictions
Delivery receipts: transfer channel, hashes/checksums, access logs, and acknowledgements
Deletion/erasure proof: confirmations, retention exceptions, and closure memo

Recommended next step

Use EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2G Exceptional Need Requests as a cited research workflow

Research Copilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2G Exceptional Need Requests from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Research workflow

Open Research Copilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2G Exceptional Need Requests

Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2G Exceptional Need Requests and answer scope, timing, and interpretation questions with cited outputs.

Explore next step

Talk to Sorena

Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching

Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2G Exceptional Need Requests.

Explore next step

Primary sources