Last updated: 4 September 2026
If you need an EU Data Act Product Data Notice template, the first thing to know is that the regulation does not prescribe one official PDF, Word document or webpage layout.
Article 3(2) of Regulation (EU) 2023/2854 requires specific pre-contractual information to be provided before the purchase, rent or lease of a connected product. Manufacturers and sellers have responded by publishing documents with names such as Product Data Notice, Data Notice, Product Information Notice, Data Act Information Sheet, or pre-contractual information.
The title is flexible. The required information is not.
A useful template should therefore begin with the actual Article 3(2) information groups, then add only the operational fields that make the notice maintainable across product families, websites, distributors and marketplaces.
This page provides a practical blank Product Data Notice structure, an annotated explanation of each field, a fictional worked example, guidance for product families and variants, webpage/PDF/QR publication guidance, a marketplace handoff checklist, and common mistakes to avoid.
Want to generate rather than copy a template manually? Use the free EU Data Act Product Data Notice Generator. It structures Article 3(2) fields, highlights missing information and can produce review-ready outputs locally in your browser.
Important: This is an informational template, not an official European Commission form, legal opinion, certification or guarantee of compliance. Product scope, enterprise status, contractual roles and sector-specific rules can affect the analysis.
Quick template: what should an EU Data Act Product Data Notice contain?
For a connected product, Article 3(2) requires the seller, rentor or lessor — which may be the manufacturer — to provide at least the following information clearly and comprehensibly before the contract is concluded.
Article 3(2)(a)
- type of product data;
- format;
- estimated volume.
Article 3(2)(b)
- whether the product can generate data continuously;
- whether it can generate data in real time.
Article 3(2)(c)
- whether data can be stored on the device;
- whether data can be stored on a remote server;
- intended retention where applicable.
Article 3(2)(d)
- how the user can access the data;
- how the user can retrieve the data;
- how the user can erase the data where relevant;
- technical means;
- terms of use;
- quality of service.
Primary legal source:
Regulation (EU) 2023/2854 — EU Data Act
That four-part structure should be the backbone of the template.
Copyable Product Data Notice template
The following is a practical blank structure.
It contains two kinds of fields:
- Article 3 information — intended to map to the regulation;
- document-management fields — useful for identifying, maintaining and distributing the notice but not presented here as separate Article 3(2)(a)–(d) requirements.
EU Data Act Product Data Notice
Pre-contractual product information — Regulation (EU) 2023/2854, Article 3(2)
Notice information
Notice version: [Version]
Effective date: [YYYY-MM-DD]
Last updated: [YYYY-MM-DD]
Canonical notice URL: [https://manufacturer.example/eu-data-act/product]
Issuer
Legal/trading name: [Organization]
Role: [Manufacturer / seller / rentor / lessor / other]
Business address: [Address]
Country: [Country]
Website: [URL]
Data Act / product-data contact: [Email or contact URL]
Manufacturer
If different from the issuer:
Manufacturer: [Manufacturer legal/trading name]
Manufacturer website: [URL]
Connected product
Brand: [Brand]
Product name: [Product]
Product family: [Family]
Model: [Model]
SKU / GTIN / EAN: [Identifier]
Covered models or variants: [List]
Product URL: [URL]
1. Product data generated — Article 3(2)(a)
For each meaningful product-data category, provide:
| Data category | Nature / description | Format | Estimated volume |
|---|---|---|---|
| [Category] | [What the data represent] | [JSON / CSV / etc.] | [Value/range + basis] |
| [Category] | [Description] | [Format] | [Estimate] |
Where useful, also state:
- generation trigger/frequency;
- example data points;
- variability assumptions;
- data structure/API specification link.
2. Continuous and real-time generation — Article 3(2)(b)
For each category or for the product as a whole:
Continuous generation: [Yes / No / Conditional]
Real-time generation: [Yes / No / Conditional]
Generation frequency / trigger: [Example: every five minutes; event-based; during active sessions]
Conditions or exceptions: [Explanation]
3. Storage and retention — Article 3(2)(c)
On-device storage
Can the product store data on-device? [Yes / No / Conditional]
Description: [Storage method]
Retention: [Duration/rule, e.g. 48-hour rolling buffer, until overwritten, configurable]
Remote-server storage
Can data be stored on a remote server? [Yes / No / Conditional]
Description: [Cloud/backend context]
Retention: [Duration/rule]
Transient data
Where applicable:
Data processed transiently / not persistently stored: [Description]
4. User access, retrieval and erasure — Article 3(2)(d)
Access method: [App / web portal / API / direct-device interface / physical connection / request process]
Access description: [How the user obtains the data]
Technical means: [REST API / USB / app export / portal download / other]
Access URL or endpoint: [URL where relevant]
Retrieval/export format: [CSV / JSON / ZIP / etc.]
Erasure
Can relevant data be erased? [Yes / No / Not relevant / Conditional]
Erasure method: [How]
Limitations/conditions: [If applicable]
Terms of use
Terms URL: [URL]
Relevant terms note: [Short explanation]
Quality of service
Quality-of-service information: [Availability, expected processing/export time, reliability, support or other relevant service information]
Contact and supporting links
Product support: [URL/email]
Data access contact: [URL/email]
Privacy notice: [URL if personal data are involved]
Related Service Data Notice: [URL where Article 3(3) applies]
This notice should be reviewed against the actual product and applicable legal obligations before publication.
That is the template. The rest of this guide explains how to fill it correctly.
Why the template begins with data categories
A common weak implementation starts with legal prose:
“Our product may collect certain information in connection with its operation.”
That is difficult to maintain and difficult for a customer to use.
Article 3 asks for the type, format and estimated volume of product data. That pushes the manufacturer toward an inventory of actual data categories.
Real manufacturer notices demonstrate this pattern.
EZVIZ's Product Data Notice separates product-data type, format, estimated volume, real-time characteristics, retention and user access.
HIKMICRO's Product Data Notice uses a similar structure.
Ruijie's Product Data Notice also follows the recurring Article 3 pattern.
ABB's 2026 notices show that more complex industrial products may need detailed product-family information, direct/indirect access descriptions, several formats, variable data volumes and multiple retention models.
The practical conclusion is simple:
Build the notice from a product-data inventory, not from a blank legal document.
How to fill in “type of product data”
“Type” should tell the user what the data represent.
Examples:
- temperature readings;
- humidity readings;
- operating state;
- battery status;
- fault events;
- diagnostic logs;
- energy consumption;
- device configuration;
- location information;
- maintenance information;
- usage events.
Avoid treating “JSON” as a data type. JSON is a format.
Weak
Type: JSON data
Better
Type: environmental sensor measurements including temperature, humidity and air-quality readings Format: JSON / CSV
The distinction matters because Article 3(2)(a) asks for both type and format.
How to document format
Use the actual technical format available to the user or data holder.
Common examples include JSON, CSV, XML, TXT/log, image/video formats, ZIP archives, proprietary binary formats and API responses.
If the product uses a proprietary structure, identify it accurately and, where useful, link to documentation.
Do not claim a standard format merely because the engineering team could theoretically convert the data into it.
The notice should describe the real product/access mechanism.
How to estimate data volume
Estimated volume is one of the fields manufacturers often struggle with.
The regulation asks for an estimate, which means the answer does not have to pretend the product produces an identical number of bytes every day.
A practical volume model can use:
Fixed estimate
Approximately 250 KB/day.
Range
Approximately 1–5 MB/month depending on device activity.
Event-dependent
Variable. Approximately 2–10 KB per fault event.
Session-based
Up to 50 MB per service session.
Storage-capacity-driven
Video volume depends on recording duration, resolution and installed storage capacity.
ABB's public product notices illustrate why range/usage explanations can be appropriate for industrial devices where survey frequency, sessions or configuration affect volume.
Avoid N/A unless it is genuinely not applicable and you can explain why.
“Unknown” is better treated as an internal review flag, not as the final public answer.
Continuous generation and real-time generation are not identical
The template keeps these as separate questions because Article 3 does.
A product may generate data continuously but only synchronize periodically, generate events in real time but otherwise remain idle, record data locally and make it accessible only later, or produce some categories in real time and others on demand.
Example
Environmental sensor:
- measurements every five minutes;
- emergency threshold alarms in real time;
- diagnostics only when a fault occurs.
The public notice can summarize the differences rather than forcing a blanket Yes/No across the entire product.
How to document storage correctly
Article 3(2)(c) distinguishes storage on the connected product from storage on a remote server.
Your source record should do the same.
Example
On-device
Measurements are held in a rolling 48-hour device buffer and overwritten automatically.
Remote server
Measurements synchronized to the manufacturer cloud are retained for 12 months by default; administrators can configure shorter retention.
That is far more useful than:
Storage: cloud.
Transient data
Some products generate data that are not persistently stored.
BenQ's current EU Data Act notice provides a practical example of transient device data that are available locally while the device operates and cleared after power-off.
If that is how the product works, document it explicitly.
How to document user access and retrieval
The user needs to understand the practical route.
Possible access mechanisms include API, mobile application, web portal, local network, direct-device display, USB, downloadable export, or manufacturer request.
Article 3(2)(d) also explicitly refers to the technical means, terms of use and quality of service.
A good template therefore keeps them visible instead of hiding them in “other notes.”
Example
Access method
Customer portal and REST API.
Technical means
Authenticated HTTPS API using the customer's administrator account.
Retrieval format
JSON API response and CSV export.
Terms
Manufacturer Data Access Terms: [URL]
Quality of service
Portal access is provided as part of the connected service. Large historical exports may take up to 24 hours to prepare.
The last sentence is an example only. Do not invent a service level if the manufacturer has not defined one.
How to handle erasure
Article 3 says “where relevant” in relation to erasure.
That is why the template allows Yes, No, Not relevant or Conditional.
Do not force every product to claim a deletion feature.
But if deletion exists, describe the method.
Examples include delete through account portal, factory-reset local buffer, administrator API, support request, or automatic rolling overwrite.
If personal data are involved, do not confuse the Product Data Notice's technical erasure description with the full set of GDPR rights.
Recommended fields vs. Article 3 fields
Fields such as notice version, last updated, effective date, canonical URL, SKU/GTIN, product-family coverage and contact are highly useful.
But they should not be presented as if Article 3(2)(a)–(d) separately lists each one.
Why include them?
Because manufacturers need to maintain and distribute the notice.
A document without product/version identification becomes difficult to manage when firmware changes, new models are added, retention changes, a marketplace asks for a stable URL, or a distributor has an old PDF.
A good regulatory artifact is also a good document-management artifact.
Product family template: can one notice cover several models?
Yes, potentially — if the notice accurately identifies the covered products and the relevant data characteristics are actually common.
Example
Product family: Smart Sensor X Series
Covered:
- X100
- X110
- X120
If X100 and X110 are functionally identical for data purposes, one notice may work.
If X120 adds GPS/location data, the family notice should either document that difference clearly, add a model-specific annex, or use a separate notice.
Do not optimize for fewer documents at the expense of accuracy.
Fictional worked example
The following example is fictional and exists only to show how the template can look when completed.
EU Data Act Product Data Notice
Fictional example — Smart Sensor X100
Notice information
Version: 1.0 Effective: 2026-09-04 Canonical URL: https://example.invalid/eu-data-act/x100
Issuer
Example Devices GmbH Role: Manufacturer Germany Contact: data-act@example.invalid
Connected product
Brand: ExampleSense Product: Smart Sensor X100 Model: X100 SKU: ES-X100
1. Product data generated
| Data category | Description | Format | Estimated volume |
|---|---|---|---|
| Environmental readings | Temperature, humidity and air-quality measurements | JSON, CSV | Approx. 1–5 MB/month |
| Device status | Battery, connectivity and operating-state events | JSON | Approx. 100–500 KB/month |
| Diagnostics | Fault codes and diagnostic events | JSON | Event-dependent, typically <50 KB/event |
2. Continuous and real-time generation
Environmental readings are recorded every five minutes. Threshold alarms can be generated in real time. Device diagnostics are event-based.
3. Storage and retention
On-device: rolling 48-hour buffer. Remote server: 12 months by default after synchronization.
4. Access, retrieval and erasure
Access: customer portal and REST API. Retrieval: JSON API and CSV download. Erasure: administrators may delete cloud history from the account portal; local buffer data are overwritten automatically. Technical means: authenticated web portal/API. Terms: [fictional URL] Quality of service: [manufacturer-defined service information would appear here].
Again: these values are examples, not suggested defaults.
Should the notice be HTML, PDF or both?
There is no single official Article 3(2) file format.
A practical manufacturer setup often uses both.
Stable webpage
Advantages:
- update one source;
- direct link from retailer/marketplace;
- canonical current version;
- accessible on mobile;
- easy to reference via QR.
Advantages:
- distributor uploads;
- offline review;
- document-management systems;
- marketplace workflows such as bol's manufacturer-document route.
Structured record
JSON/CSV can support internal handoff and future marketplace mappings.
The strongest architecture is:
structured source → webpage + PDF + marketplace-specific output
Stable URLs and QR codes
Recital 24 of the Data Act discusses the possibility of fulfilling the information obligation through a stable URL distributed by web link or QR code, provided the information can be retained for future reference and reproduced unchanged.
That makes the canonical URL field operationally useful.
A durable structure might be:
manufacturer.com/eu-data-act/product-family
rather than a transient news/article URL.
The first is easier to hand to sellers and keep stable.
How this template maps to marketplaces
The same source information can support different channel workflows.
Kaufland
Current Kaufland guidance uses a Data Act status and Smart Device Info URL.
A canonical manufacturer page can serve as the URL source.
Read:
Kaufland EU Data Act Seller Guide
bol
bol currently supports a manufacturer document or bol template containing Article 3 information.
A PDF generated from the canonical notice can serve that workflow.
Read:
MediaMarktSaturn
MediaMarktSaturn documentation maps Article 3 information into structured PROD_FEAT_94000–94006 fields and/or manufacturer information links depending on the channel setup.
Read:
MediaMarktSaturn EU Data Act Attributes
The lesson is straightforward:
do not maintain separate technical truths for each marketplace.
Product Data Notice vs. Related Service Data Notice
This template is focused on Article 3(2) and the connected product.
A related digital service can create a separate Article 3(3) disclosure.
Article 3(3) is broader. It can require information about product data the prospective data holder expects to obtain, related-service data, collection frequency, storage and retention, intended data use, third-party use, data-holder identity/address, third-party sharing requests, complaint rights, trade-secret holder information, contract duration and termination.
Do not force those fields into the four-part Product Data Notice template.
See:
EU Data Act Related Service Data Notice: Article 3(3) Guide
Product Data Notice vs. privacy notice
A Product Data Notice is not simply a renamed GDPR Privacy Notice.
The Data Act can concern both personal and non-personal product data.
Privacy law still governs processing of personal data.
Manufacturers such as Philips/Signify expressly separate their Data Notices from Privacy Notices.
If the same dataset is personal data, the Data Act access/transparency question still needs analysis, and GDPR lawful basis, rights and controller/processor rules still need analysis.
See:
EU Data Act vs GDPR for Connected Products
Who should fill this template internally?
The template usually needs more than one team.
Product / engineering
Provides data categories, formats, generation frequency, storage architecture and access methods.
Product Compliance / Regulatory Affairs
Owns scope review, completeness, legal coordination and publication governance.
Product Data / PIM
Helps maintain product identifiers, family/variant relationships and channel-ready structured data.
Ecommerce / marketplace team
Needs manufacturer URL, PDF and marketplace mappings.
Legal / privacy
Reviews contractual wording, Data Act/GDPR interaction and related-service/data-holder arrangements.
A common failure is asking Legal to invent technical values that only engineering knows.
Common template mistakes
1. Treating the template as an official EU form
There is no universal official Product Data Notice form prescribed by Article 3(2).
2. Copying another manufacturer's values
Use other notices for structure, not for your technical facts.
3. Confusing data type and format
“JSON” is not the data category.
4. Writing “variable” for volume with no explanation
Explain what drives the variation.
5. Combining continuous and real-time into one field
Keep them conceptually separate.
6. Saying “cloud” for storage and stopping there
State retention where applicable.
7. Saying “contact support” without technical means or route
Give a usable access/retrieval mechanism.
8. Omitting terms and QoS
They are explicitly relevant in Article 3(2)(d).
9. Reusing one family notice where models materially differ
Document variations or separate them.
10. Publishing without version/date
Not necessarily a separate statutory line item, but poor operational practice.
11. Using a privacy notice instead
Different legal purpose.
12. Publishing a PDF no seller can find
Maintain a stable source URL where practical.
Product Data Notice pre-publication checklist
- Product/issuer clearly identified.
- Connected-product scope reviewed.
- Article 7 checked where relevant.
- Product-data categories documented.
- Formats documented.
- Estimated volume provided or explained.
- Continuous generation stated.
- Real-time generation stated.
- On-device storage stated.
- Remote storage stated.
- Retention stated where applicable.
- Access method documented.
- Retrieval/export method documented.
- Erasure documented where relevant.
- Technical means documented.
- Terms documented.
- Quality of service documented.
- Related-service analysis completed separately where necessary.
- Privacy/GDPR interaction reviewed where personal data are involved.
- Notice version/date added.
- Canonical URL tested.
- Product-family/model coverage checked.
- Marketplace/reseller handoff prepared.
- Internal owner assigned for updates.
Frequently asked questions
Is there an official EU Data Act Product Data Notice template?
Article 3(2) specifies information that must be provided but does not prescribe one universal document layout or require the artifact to be titled “Product Data Notice.” RegCatalog's template is a practical structure based on the current legal information groups and real manufacturer implementations.
What are the four main Article 3(2) sections?
Type/format/estimated volume; continuous/real-time generation; storage/retention; and access/retrieval/erasure including technical means, terms of use and quality of service.
Is product identification legally required in the same way as Article 3(2)(a)–(d)?
Product identification is operationally necessary for a useful notice, but the four Article 3(2) lettered requirements focus on the data characteristics and access information. This template distinguishes recommended document-management fields from the core Article 3 groups.
Can I publish the notice as a webpage?
Yes, a clear stable webpage can be a practical publication method. Recital 24 discusses stable URLs/web links and QR codes as a way the information obligation could be fulfilled.
Do I also need a PDF?
Not universally, but PDFs are useful for distributor, document-management and marketplace workflows. bol, for example, accepts a manufacturer document in its current Data Act seller process.
Can one notice cover a whole product family?
Potentially, if all covered models are clearly identified and the data characteristics are accurate. Material model differences should be documented or handled separately.
What should I write for estimated volume when usage varies?
Give a range, usage-dependent estimate or event/session basis and explain the assumptions. Avoid false precision.
Is “data available through app” enough for user access?
Usually not a strong final description. Explain which app/interface, what the technical means are, what can be retrieved, the format where relevant, and applicable terms/QoS.
What if data are never stored?
State that the data are transient/not persistently stored and explain the actual access behavior rather than inventing a retention period.
Is a Privacy Notice enough?
No. A GDPR Privacy Notice and a Data Act Product Data Notice address different questions, although both may apply to the same personal-data-containing dataset.
What if the product has a related app?
Assess whether the app is a “related service” under Article 2(6). If so, Article 3(3) has a broader pre-contractual information set.
Can RegCatalog generate this template?
Yes. The free generator structures the Article 3(2) information, supports review states and provides several local export formats without requiring an account.
Use the free generator
You can copy this template into your own document workflow, but a structured generator is easier to maintain when products have multiple data categories.
Open the free Product Data Notice Generator
For the broader legal/context explanation:
Read the EU Data Act Product Data Notice Guide
Primary sources and implementation examples
Primary / official
- Regulation (EU) 2023/2854 — EU Data Act
- European Commission — Data Act
- European Commission — Data Act explained
- European Commission — Data Act implementation FAQs
Manufacturer / marketplace implementation examples
- EZVIZ Product Data Notice
- HIKMICRO Product Data Notice
- Ruijie Product Data Notice
- bol European Data Act template
- ABB EU Data Act information
RegCatalog provides product-data tooling and informational resources. It does not provide legal advice, certification, or a guarantee that a Product Data Notice satisfies every obligation applicable to a particular product or company.