EU Data Act Data Access Request Template — Article 4 (2026)

Last updated: 11 September 2026

The EU Data Act gives users of connected products a right to access certain data generated through the products and related services they use.

For many products, the cleanest implementation is direct access: the user can retrieve the relevant data from the product, app, portal or API without asking the data holder to intervene.

But where the data are not directly accessible, Article 4(1) creates a request-based route. The data holder must make readily available data and the metadata needed to interpret and use them accessible to the user, subject to the conditions and safeguards in the regulation.

That makes a practical EU Data Act data access request template useful for two audiences:

users that need to ask for their connected-product data;
manufacturers/data holders designing the request workflow that receives and fulfils those requests.

This guide explains what Article 4 requires, what “readily available data” means, what a request should contain, how verification should work, the required output characteristics, trade-secret/security/GDPR limits, and how a manufacturer can turn Article 4 into an operational support process.

Important: This guide is informational, not legal advice. Whether a dataset is within Article 4 can depend on the connected product, related service, user relationship, personal-data context, trade-secret status and technical architecture.

Quick answer: what does Article 4 require?

Where the user cannot directly access the relevant data from the connected product or related service, Article 4(1) says the data holder must make available:

readily available data;
relevant metadata necessary to interpret and use those data.

The data must be made accessible:

without undue delay;
of the same quality as available to the data holder;
easily;
securely;
free of charge to the user;
in a comprehensive, structured, commonly used and machine-readable format;
continuously and in real time where relevant and technically feasible.

The request should be possible through a simple electronic request where technically feasible.

Primary source:

Regulation (EU) 2023/2854 — Article 4

The European Commission also maintains current implementation support including its Data Act FAQ, Data Act explained and Data Act Legal Helpdesk.

Article 3 direct access vs Article 4 request-based access

The Data Act architecture is easier to understand if you separate two routes.

Direct access

Article 3(1) is the design/accessibility rule for connected products and related services placed on the market after 12 September 2026.

Where relevant and technically feasible, product data and related-service data should be directly accessible to the user.

Examples can include:

device interface;
downloadable file;
customer portal;
API;
local network interface.

Indirect / request-based access

Article 4(1) applies where the relevant data cannot be directly accessed by the user.

The user sends a request to the data holder.

The data holder then provides the readily available data and necessary metadata.

This distinction matters operationally:

Article 4 is not only a “failure path.” It is an intended access route where the product/service architecture does not provide direct access.

For the September 2026 design requirement, see:

EU Data Act 12 September 2026 Deadline: Article 3(1) Guide

What are “readily available data”?

For product-scope definitions and examples, see the Connected Product Guide.

Article 2(17) defines readily available data as product data and related-service data that a data holder lawfully obtains or can lawfully obtain from the connected product or related service without disproportionate effort going beyond a simple operation.

That means an Article 4 request is not automatically a right to every internal dataset a manufacturer can theoretically create.

Useful distinctions include:

raw product data;
pre-processed data;
metadata needed to interpret/use the data;
inferred/derived analytics;
content;
data not technically retrievable without disproportionate work.

For the broader definitions, see the EU Data Act on EUR-Lex and the Commission's Data Act explained.

What metadata should the user ask for?

The user does not only have a practical interest in bytes.

Without metadata, a CSV or JSON file may be difficult to interpret.

Relevant metadata can include:

field names;
units;
timestamps/timezone;
sampling interval;
event codes;
code lists;
value ranges;
schema versions;
field descriptions;
device identifiers;
calibration/context information where necessary;
API/schema documentation.

Article 4(1) expressly covers relevant metadata necessary to interpret and use the data.

A practical request should therefore ask for:

the requested readily available data and the relevant metadata necessary to interpret and use them.

Copyable EU Data Act Article 4 request template

The following template is a practical drafting aid. It is not an official European Commission form.

Subject: Request for access to connected-product data under Article 4 of Regulation (EU) 2023/2854

Dear [Data holder / Data Act contact],

I am requesting access to data generated through my use of the connected product and/or related service identified below, under Article 4 of Regulation (EU) 2023/2854 (EU Data Act).

Requester / user

Name or organization: [Name]

Contact: [Email / portal account]

Relationship to product/service: [Owner / renter / lessee / authorized user / business customer]

Product: [Product name]

Brand / manufacturer: [Brand/manufacturer]

Model: [Model]

Serial number / product identifier: [Identifier where necessary]

Related service / account: [Service/account identifier where necessary]

Data requested

Please provide the readily available product data and/or related-service data generated through my use of the product/service for:

Period: [Date/time range]

Data categories requested: [All readily available data / specific categories]

Examples where relevant:

sensor measurements;
device state/operation data;
diagnostics/events;
energy/usage data;
configuration/status data;
related-service data.

Please also provide the relevant metadata necessary to interpret and use the data, including applicable field descriptions, units, timestamps, code lists/schema information or other documentation necessary to understand the export.

Delivery

Where applicable, please make the data available:

without undue delay;
easily and securely;
free of charge to me as the user;
in a comprehensive, structured, commonly used and machine-readable format;
at the same quality available to the data holder;
continuously/in real time where relevant and technically feasible.

Preferred delivery method, if available:

[Portal / API / secure download / other]

Preferred format, if supported:

[JSON / CSV / other machine-readable format]

Verification

Please let me know if additional information is genuinely necessary to verify that I qualify as the user of this connected product or related service.

Personal data

Where the requested dataset contains personal data relating to persons other than me, I understand that additional data-protection requirements may apply. Please identify any information or legal basis required to process the request lawfully rather than treating this request as authority to disclose third-party personal data automatically.

Security / trade-secret safeguards

If particular data are subject to security restrictions or trade-secret safeguards under the Data Act, please identify the specific data concerned and the safeguards or other measures proposed for lawful access.

If data are withheld, suspended or refused, please provide the required written reasoning and information on available challenge/redress routes where applicable.

Please confirm receipt of this request and the method by which the data will be made available.

Kind regards, [Name / organization]

What should you include in the request?

Article 4 does not require users to submit a huge compliance questionnaire.

A practical request needs enough information to:

identify the user;
identify the product/service;
identify the requested data/time period;
deliver the data securely.

User identification

Use the least information necessary.

Examples:

account login;
customer identifier;
product ownership/lease reference;
serial number;
organization/contact details.

Product identification

Use enough information to distinguish the correct connected product.

Possible values:

model;
serial number;
device ID;
VIN;
machine ID;
tenant/site ID.

Time range

A defined time period can make fulfilment easier:

1 August 2026 to 31 August 2026

or:

all readily available data associated with my account/product.

Data categories

If you know exactly what you need, identify the categories.

If not, requesting:

all readily available product data and related-service data generated through my use

can be a reasonable starting point, subject to the actual scope and legal context.

How much verification can the data holder demand?

Article 4(5) limits verification.

For the purpose of determining whether the requester qualifies as a user, the data holder must not require information beyond what is necessary.

Article 4 also limits retention of information/logs about access beyond what is necessary for:

sound execution of the access request;
security and maintenance of the data infrastructure.

That should influence request-form design.

Good verification design

sign in to existing customer account;
verify device ownership/lease;
verify authorized business user;
verify a device/account relationship.

Poor verification design

collecting unrelated personal details;
demanding extensive corporate documents where a customer account already proves the user relationship;
storing access-request telemetry indefinitely without operational/security reason.

What format must the data holder provide?

Article 4 uses several important descriptors:

comprehensive;
structured;
commonly used;
machine-readable.

That makes formats such as these often practical:

JSON;
CSV;
XML;
API;
structured bulk export.

A PDF report can be helpful documentation, but a PDF by itself may not satisfy a request for machine-readable operational data if the actual data exist in structured form.

The right output depends on the dataset.

Same quality as available to data holder

The user should not receive an intentionally degraded version merely because the request is external.

Article 4 says the data should be of the same quality as is available to the data holder.

That does not necessarily mean the user receives every internal transformation or derived analytic product.

The starting question remains:

Which readily available product/related-service data are in scope?

Is Article 4 access free?

Article 4(1) says the data must be made accessible free of charge to the user.

That should be distinguished from Article 5/Chapter III compensation mechanics involving data recipients.

A user requesting its own Article 4 access should not be charged simply for exercising the Article 4 right.

How quickly must the data be provided?

The regulation uses:

without undue delay

rather than one universal number of days.

That means fulfilment time can depend on the technical workflow and context, but organizations should not design request handling around arbitrary long delays.

For recurring requests or continuous access, a portal/API architecture may be far more efficient than manually preparing exports each time.

Continuous and real-time access

Where relevant and technically feasible, Article 4 contemplates data being available continuously and in real time.

This can matter for:

predictive maintenance;
fleet operations;
smart building monitoring;
industrial optimization;
aftermarket services;
live analytics.

A one-time CSV export may be enough for a historical request but unsuitable for a legitimate use case requiring continuous access.

The technical architecture should match the product and purpose.

Security limits

Article 4(2) allows users and data holders to contractually restrict or prohibit access/use/further sharing where the processing could undermine security requirements of the connected product laid down in Union or national law and produce a serious adverse effect on health, safety or security of natural persons.

This is not a generic:

security concern = deny request

rule.

Where a data holder refuses sharing under this security provision, the regulation requires notification to the competent authority designated under Article 37.

Manufacturers should therefore create a documented security-decision process rather than ad hoc support answers.

Trade secrets

Trade secrets do not automatically remove all Article 4 data from access.

Article 4(6)–(9) establishes a safeguard process.

At a high level:

trade secrets must be preserved;
the data holder/trade-secret holder identifies the trade-secret data;
necessary confidentiality measures can be agreed before disclosure;
if measures are not agreed/implemented or confidentiality is undermined, specific trade-secret sharing may be withheld/suspended with substantiation and authority notification;
in exceptional circumstances, where the trade-secret holder can objectively demonstrate a high likelihood of serious economic damage despite safeguards, specific data can be refused case by case;
the user has challenge/redress routes.

For a dedicated explanation:

EU Data Act Trade Secrets: Articles 4 and 5 Guide

What may the user do with the data?

Article 4 gives substantial rights, but it also contains restrictions.

Article 4(10) says the user must not use requested data to:

develop a connected product that competes with the connected product from which the data originate;
share the data with a third party with that intent;
derive insights about the economic situation, assets or production methods of the manufacturer/data holder.

This does not mean the user cannot use the data for competitive aftermarket services.

The Data Act's structure deliberately supports third-party services, repair, analytics and other data-driven uses, subject to the legal restrictions.

Personal data and Article 4

The Data Act does not replace GDPR.

Where the user is not the data subject whose personal data are requested, Article 4(12) requires a valid legal basis under GDPR Article 6 and, where relevant, additional conditions for special-category/ePrivacy contexts.

Examples:

company owns connected vehicle used by employee;
landlord owns smart building system used by tenants;
family account includes several individuals;
employer requests device data containing employee information.

The fact that the organization is the Data Act “user” does not automatically authorize disclosure of every person's personal data.

For a deeper comparison:

EU Data Act vs GDPR for Connected Products

Data holder use of non-personal data

Article 4 is not only about the user's rights.

Article 4(13) says a data holder may use readily available non-personal data only on the basis of a contract with the user.

It also prohibits using such data to derive insights about the user's economic situation, assets, production methods or use in ways that could undermine the user's commercial position.

This can be very important in industrial B2B products.

A manufacturer should therefore review:

connected-product terms;
related-service contract;
data-use purposes;
analytics/product-improvement clauses.

Article 4 request workflow for manufacturers/data holders

For the wider operational role behind this workflow, see the Data Holder Obligations Guide.

A scalable workflow can look like:

Request
  ↓
Verify user
  ↓
Identify product/service
  ↓
Map requested period/data
  ↓
Determine readily available data
  ↓
GDPR/security/trade-secret review
  ↓
Prepare data + metadata
  ↓
Secure delivery/API access
  ↓
Record outcome

Intake fields

Keep the form concise:

requester/user;
product/account;
requested period;
data categories/purpose where useful;
preferred delivery method.

Internal routing

Potential owners:

Product Data / Data Platform;
Support;
Product Compliance;
Privacy;
Legal;
Security.

Do not create a process where every request is manually re-litigated from zero.

How manufacturers can reduce Article 4 request cost

1. Design direct access where feasible

A good portal/API can remove many manual requests.

2. Maintain a data inventory

Know:

dataset;
source system;
format;
metadata;
personal/non-personal;
trade-secret classification;
retention.

3. Reuse verification

Existing customer identity/account controls are often better than bespoke forms.

4. Automate machine-readable exports

Avoid support teams assembling spreadsheets manually.

5. Build request status tracking

At least:

received;
verification needed;
in review;
fulfilled;
partially fulfilled;
refused/suspended with reason.

6. Define escalation paths

For:

third-party personal data;
security;
trade secrets;
unclear user status.

These are different rights.

Data Act Article 4

Can cover:

personal data;
non-personal data;
connected-product data;
related-service data;
relevant metadata.

The requester is the Data Act user.

Covers personal data concerning the data subject and associated information required by GDPR.

The requester is the data subject or authorized representative.

A single dataset can trigger both frameworks.

Do not reject a Data Act request simply because it is “not a GDPR SAR.”

Do not fulfil personal data outside GDPR merely because the Data Act request exists.

Article 4 vs Article 5

Article 4:

make data available to the user.

Article 5:

at the user's request, make data available to a third party.

If the user's goal is:

send my machine data directly to an independent maintenance provider

Article 5 is the more relevant workflow.

See:

EU Data Act Third-Party Data Sharing Request Template

Common mistakes

Article 4 also covers non-personal data.

2. Asking for too much verification

Verification must be limited to what is necessary.

3. Providing screenshots/PDF when machine-readable data are available

Article 4 expressly refers to structured, commonly used, machine-readable format.

4. Omitting metadata

Raw columns without context can be unusable.

5. Charging the user

Article 4 access is free to the user.

6. Saying “trade secret” and denying the entire export

Trade secrets have a safeguard/refusal process.

7. Saying “security” without the serious-adverse-effect test

Use the actual Article 4(2) standard.

8. Ignoring personal data of other people

Data Act user status is not automatically a GDPR legal basis.

9. Keeping request logs forever

Article 4 limits retention of access-request information to what is necessary for execution/security/maintenance.

10. Building a manual process where an API would solve the recurring use case

Operational design matters.

Article 4 request checklist — user

Confirm you are the user of the connected product/related service.
Identify product/model/account.
Define data period.
Identify data categories if known.
Ask for relevant metadata.
Ask for machine-readable delivery.
Identify continuous/real-time need if relevant.
Consider personal-data issues involving other individuals.
Keep the response and reason if data are refused/suspended.

Article 4 request checklist — data holder

Simple electronic request channel exists.
Verification is proportionate.
Product/account ownership/use relationship can be checked.
Readily available datasets are mapped.
Metadata are mapped.
Export/API format is machine-readable.
Delivery is secure.
Personal data review exists.
Security escalation exists.
Trade-secret safeguards/refusal workflow exists.
No Article 4 user fee is charged.
Request logs are retained only as necessary.
Reasons/redress route are documented for restrictions/refusals.

Frequently asked questions

What is an EU Data Act Article 4 request?

It is the request-based route through which a user can obtain readily available connected-product/related-service data when the data are not directly accessible from the product or service.

Is there an official Article 4 request form?

The Data Act requires a simple request through electronic means where technically feasible but does not prescribe one universal form. The template in this guide is a practical RegCatalog drafting aid.

What data can I request?

Readily available product data and related-service data, plus relevant metadata necessary to interpret and use them, subject to the Data Act's scope and safeguards.

What are readily available data?

Product/related-service data that the data holder lawfully obtains or can lawfully obtain without disproportionate effort going beyond a simple operation.

Does the request include metadata?

Yes. Article 4(1) expressly includes relevant metadata necessary to interpret and use the data.

Does the data have to be machine-readable?

Article 4 requires a comprehensive, structured, commonly used and machine-readable format.

Does the data holder have to provide it for free?

Yes, Article 4(1) states that access is free of charge to the user.

Is there a fixed deadline?

Article 4 uses “without undue delay” rather than one universal day-count.

Can I ask for continuous or real-time access?

Where relevant and technically feasible, Article 4 contemplates continuous and real-time access.

Can the manufacturer ask for ID or ownership proof?

It may verify whether you qualify as a user, but Article 4 says it must not require information beyond what is necessary.

Can trade secrets be excluded automatically?

No. Trade-secret data are subject to confidentiality measures and a specific withhold/suspend/refuse process in Articles 4(6)–(9).

Can access be denied for security?

Article 4 allows restrictions where the processing could undermine product security requirements and create a serious adverse effect on health, safety or security of natural persons. This is narrower than a generic security objection.

Yes. Data Act rights do not remove data-protection obligations where personal data are involved.

Can I use the data to build a competing connected product?

Article 4(10) prohibits use of requested data to develop a connected product that competes with the source connected product.

What if I want the data sent directly to another company?

Use the Article 5 third-party sharing route.

Primary sources and further reading

RegCatalog provides informational product-data tooling and practical implementation resources. It does not provide legal advice, legal representation or certification.

EU Data Act Data Access Request Template: Article 4 Guide for Connected Products (2026)