Last updated: 4 September 2026
An EU Data Act Related Service Data Notice is more complicated than a Product Data Notice.
That is because Article 3(3) does not merely ask what data a device can generate. Before a contract for a related service is concluded, the provider must give the user a broader set of information covering the data the prospective data holder expects to obtain, the related-service data that will be generated, storage and retention, how the data holder intends to use the data, third-party use, contact details, user-requested sharing, complaint rights, trade secrets, and contract duration/termination.
This is why a three-field section labelled “app / provider / URL” is not enough for a serious Article 3(3) implementation.
Current manufacturer/service-provider notices make the distinction visible:
- Signify publishes Article 3(3) notices for connected lighting services;
- Vorwerk publishes a service notice for Cookidoo;
- Hikvision publishes a dedicated Related Service Data Notice for Hik-Connect;
- LEDVANCE publishes Article 3(3) pre-contractual information for several apps and cloud services;
- Xperi publishes Article 3(3) information for TiVo-related services.
This guide explains:
- what a “related service” is;
- how it differs from the connected product;
- what Article 3(3)(a)–(i) requires;
- how to structure a Related Service Data Notice;
- how real companies are implementing it;
- how the notice interacts with GDPR/privacy notices;
- a practical Article 3(3) checklist.
Using RegCatalog? The free Product Data Notice Generator supports Article 3 product-information workflows. Where a related-service module is used, it should be reviewed against the full Article 3(3) information set described here.
Important: This guide is informational, not legal advice. Whether a digital service is a “related service,” who the prospective data holder is, and which data/contractual roles apply can require fact-specific analysis.
Quick answer: what is a related service under the EU Data Act?
Article 2(6) defines a related service as a digital service, other than an electronic communications service, including software, that is connected with the product at the time of purchase/rent/lease in such a way that its absence would prevent one or more functions of the connected product from operating, or that is subsequently connected by the manufacturer or a third party to add to, update or adapt the connected product's functions.
The Commission's Data Act explainer gives a simple example: a connected washing machine paired with an application that uses sensor data and adjusts the washing cycle can involve a related service.
Official explanation:
European Commission — Data Act explained
The practical test is not:
“Does the product have an app?”
It is:
“Is the digital service linked to the connected product in the way Article 2(6) describes, and does it affect product functionality?”
Not every app is a related service
An app can be connected to a product without necessarily qualifying as a related service.
Examples that deserve separate analysis:
- a generic marketing app;
- a support/documentation app;
- an unrelated media service;
- an optional dashboard that does not affect any product function;
- third-party software with no product-function relationship.
By contrast, stronger related-service patterns can include software that:
- configures the product;
- changes operating modes;
- sends commands;
- controls schedules;
- enables remote functions;
- updates/adapts functions;
- provides cloud functionality necessary for the product feature.
Document the function relationship rather than using “app = related service” as a shortcut.
For the connected-product side, see:
What Is a Connected Product Under the EU Data Act?
Product Data Notice vs. Related Service Data Notice
The distinction is structural.
Product Data Notice — Article 3(2)
Focuses on the connected product and asks for:
- type, format and estimated volume;
- continuous/real-time generation;
- storage/retention;
- access/retrieval/erasure;
- technical means;
- terms;
- quality of service.
Related Service Data Notice — Article 3(3)
Focuses on the related-service contract and prospective data holder and requires a broader set of information.
That can include both:
- Product Data expected to be obtained by the prospective data holder;
- Related Service Data that will be generated during the service.
It also asks what the data holder intends to do with readily available data and who else may use it.
That is why a company may need:
Product Notice + Related Service Notice
rather than one generic “Data Act policy.”
Article 3(3)(a): product data the prospective data holder expects to obtain
The first Article 3(3) group asks about the nature, estimated volume and collection frequency of Product Data that the prospective data holder is expected to obtain.
It also asks, where relevant, how the user can access/retrieve those data, including:
- storage arrangements;
- retention duration.
This is different from Article 3(2).
Article 3(2) asks what the connected product is capable of generating.
Article 3(3)(a) asks what Product Data the prospective data holder expects to obtain in connection with the related service.
Example
A smart-building controller may generate:
- sensor values;
- device state;
- configuration;
- diagnostics.
But a cloud dashboard may only receive:
- device state;
- selected sensor values;
- alarms.
The related-service notice should describe what the service/data holder actually expects to obtain, not blindly copy every product-data category.
Suggested fields
- Product Data category
- Nature/description
- Estimated volume
- Collection frequency
- User access/retrieval
- Storage location
- Retention
Article 3(3)(b): Related Service Data to be generated
Article 3(3)(b) separately addresses Related Service Data.
Article 2(16) defines Related Service Data around digitised user actions or events related to the connected product during provision of the related service, including data intentionally recorded by the user and data generated as a by-product of the user's action.
The notice should describe:
- nature;
- estimated volume;
- access/retrieval arrangements;
- storage;
- retention.
Examples of possible related-service data
Depending on the service:
- app configuration changes;
- account/device pairings;
- dashboard interactions;
- user-created schedules;
- remote-control commands;
- service usage events;
- cloud-created configuration history.
Do not copy these examples as facts. They illustrate the category.
Why separating Product Data from Related Service Data matters
Signify's current Data Notices make this distinction explicit.
Its MasterConnect Article 3(3) notice uses separate columns for:
- Product Data;
- Related Service Data.
It then describes format, collection frequency, volume and other service-specific details.
See:
Signify — Data Notice for MasterConnect
Philips Hue follows a similar pattern, distinguishing Product Data from Related Service Data and explicitly saying that its Privacy Notice applies to personal data.
See:
For product-data teams, this suggests a source model with two datasets rather than one giant “data generated” list.
Article 3(3)(c): data holder's intended use and third-party use
The related-service notice must state whether the prospective data holder expects to use readily available data itself and the purposes for which the data will be used.
It must also state whether the data holder intends to allow one or more third parties to use the data for purposes agreed with the user.
This is materially broader than the Article 3(2) product notice.
Practical source fields
- Will the data holder use readily available data? Yes/No
- Purposes of use
- Third-party use intended? Yes/No
- Purposes/categories
- Conditions/agreements with user
Real implementation: Vorwerk Cookidoo
Vorwerk's Cookidoo Article 3(3) service notice is a strong real-world example.
It describes purposes that include service performance, maintenance/security, support, product improvement and other stated business uses, and discusses third-party recipients.
See:
Vorwerk — Cookidoo Service Notice under Article 3(3)
The implementation lesson is not to copy Vorwerk's purposes. It is to make your own purposes explicit.
Article 3(3)(d): identity of the prospective data holder
The user should be told who the prospective data holder is.
Article 3(3)(d) includes:
- identity/trading name;
- geographical address;
- where applicable, other data-processing parties.
This matters because the connected-product manufacturer and related-service data holder can be different entities.
Example
A hardware manufacturer could use:
- its own cloud subsidiary;
- a separate group company;
- a third-party service provider.
The related-service notice should not assume the manufacturer is always the data holder.
Real implementation: LEDVANCE
LEDVANCE Article 3(3) notices identify service/data-holder entities and addresses for different tools/cloud services.
See:
Article 3(3)(e): efficient means of communication
Article 3(3)(e) requires a means of communication that allows the user to contact the prospective data holder quickly and communicate efficiently.
Useful examples:
- dedicated email;
- support portal;
- Data Act request form;
- service account support channel.
Do not bury this inside a corporate homepage.
A user should be able to understand where to ask a Data Act-related service question.
Real example
LEDVANCE publishes service-specific support/contact channels in its Article 3(3) implementation.
Article 3(3)(f): how the user requests third-party sharing
The notice needs to explain how the user can ask for data to be shared with a third party and, where applicable, how that sharing can be ended.
This connects the pre-contractual notice to one of the Data Act's central user rights: sharing data with a third party of the user's choice under the relevant Chapter II rules.
Practical fields
- Request method
- Third-party information required
- Request URL/contact
- Authentication/authorisation requirements
- Stop-sharing mechanism where relevant
Do not say:
“Third-party sharing supported”
without explaining the route.
Real example
LEDVANCE documents that users can export/share certain configuration/dashboard data themselves in current service notices.
Hikvision's Related Service Data Notice also explains data sharing/request processes for Hik-Connect.
See:
Hikvision — Related Service Data Notice
Article 3(3)(g): right to lodge a complaint
The notice must tell users about the right to lodge a complaint concerning Chapter II infringement with the competent authority designated under Article 37.
A practical notice can include:
- the statutory right;
- optionally a link to the relevant authority or general Data Act authority information;
- a general note that competent authorities vary by Member State/context.
Do not guess the competent authority if you have not verified it for the relevant jurisdiction.
The European Commission now also operates a Data Act Legal Helpdesk for questions about the Regulation, although that is not a replacement for the statutory complaint route.
See:
European Commission — Data Act Legal Helpdesk
Article 3(3)(h): trade secrets
The related-service notice must state whether the prospective data holder is the holder of trade secrets contained in relevant accessible/generated data and, where the prospective data holder is not the trade-secret holder, identify the trade-secret holder.
This is another field that simplistic “app privacy policy” implementations miss.
Practical fields
- Relevant trade secrets present? Yes/No/Unknown
- Prospective data holder is trade-secret holder? Yes/No
- If no: identity of trade-secret holder
Do not use “trade secret” as a blanket reason to hide the Article 3 notice.
The Data Act contains a broader safeguard framework for trade-secret protection and data sharing.
Article 3(3)(i): contract duration and termination
The notice must disclose:
- duration of the contract between user and prospective data holder;
- arrangements for terminating the contract.
This is a clear example of why Article 3(3) is not simply “the Article 3(2) Product Data Notice plus an app name.”
Possible structures
- fixed 12-month service;
- monthly subscription;
- indefinite until account closure;
- connected to product ownership;
- enterprise agreement.
Then explain termination:
- cancel in account;
- contact administrator;
- terminate under master agreement;
- delete service account;
- other contract-specific route.
Real example
LEDVANCE's Article 3(3) templates include contract-duration/termination information.
idem telematics also publishes a detailed Article 3(3) structure including contract duration/termination.
Practical Related Service Data Notice template
A serious Article 3(3) notice can use the following structure.
EU Data Act Related Service Data Notice
Notice information
- Version
- Effective date
- Last updated
- Service name
Related service
- Service name
- Connected product(s)
- Service provider
- Terms URL
- Privacy notice URL
Prospective data holder
- Trading/legal name
- Address
- Contact
- Other processing parties where applicable
A. Product Data expected to be obtained
For each category:
- nature;
- estimated volume;
- collection frequency;
- access/retrieval route;
- storage;
- retention.
B. Related Service Data to be generated
For each category:
- nature;
- estimated volume;
- access/retrieval;
- storage;
- retention.
C. Intended use
- data holder expects to use readily available data? Yes/No
- purposes
- third-party use intended?
- purposes agreed with user
D. Data holder identity
- identity
- geographical address
- other processing parties
E. Contact
- efficient communication method
F. Third-party sharing
- how user requests sharing
- how user ends sharing where applicable
G. Complaint right
- Article 37 complaint statement
- authority/source link where verified
H. Trade secrets
- prospective data holder trade-secret holder?
- other trade-secret holder identity
I. Contract
- duration
- termination arrangements
This structure maps much more closely to Article 3(3)(a)–(i) than a generic privacy notice.
Can Product Data Notice and Related Service Data Notice be combined?
Potentially, but the combined document must remain understandable.
There are three patterns in the market:
Separate notices
Example:
- Product Data Notice
- Related Service Data Notice
This is clean where product and service have different entities/data models.
Combined notice
Some companies publish one document with clearly separated product and service sections.
Generic + specific annexes
Signify uses generic and product/service-specific notices across parts of its portfolio.
The best structure depends on:
- product portfolio;
- service portfolio;
- data-holder entities;
- variation between models/services;
- publication channels.
Do not merge simply to reduce document count.
Real Article 3(3) implementation examples
Signify / MasterConnect
Signify explicitly identifies the notice as providing information required by Article 3(3), separates Product Data and Related Service Data, and provides service-specific information.
Vorwerk / Cookidoo
Vorwerk's service notice identifies service/provider/data-holder and explains intended uses and third-party categories.
Hikvision / Hik-Connect
Hikvision publishes a Related Service Data Notice describing the connected products associated with the service and the product/related-service data framework.
LEDVANCE
LEDVANCE uses a structured, letter-by-letter Article 3(3) implementation for its app/cloud service portfolio.
Xperi / TiVo
Xperi publishes pre-contractual Article 3(3) disclosure for TiVo Smart TV-related services.
See:
These examples demonstrate that Article 3(3) is already a concrete public-document workflow.
Related Service Data Notice vs GDPR Privacy Notice
A related-service notice can include personal and non-personal data.
GDPR still applies to personal-data processing.
Signify states this very clearly in its Data Notices: for personal data, its Privacy Notice applies and takes priority.
A service provider should therefore avoid thinking:
“We published a Data Act notice, so our privacy transparency is done.”
The two frameworks ask different questions.
Data Act notice
Focus:
- what product/service data;
- access;
- storage;
- use;
- sharing;
- data holder;
- contract.
Privacy notice
Focus:
- controller;
- purposes/legal basis;
- data subjects;
- GDPR rights;
- recipients;
- international transfers;
- retention;
- other GDPR transparency.
Where personal data overlap, both analyses may apply.
See:
EU Data Act vs GDPR for Connected Products
Article 3(3) and the user's third-party rights
The Commission's Data Act explainer emphasizes that users can access data from connected products/related services and can ask data holders to share relevant data with third parties of their choice, subject to the Regulation's rules.
This explains why Article 3(3) asks for the user-facing third-party sharing route before the related-service contract is concluded.
The service provider should decide operationally:
- how a user initiates sharing;
- how identity/authority is checked;
- what recipient details are needed;
- how sharing stops;
- how security/trade-secret/GDPR safeguards apply.
Those operational details should not be invented after the first customer request arrives.
Who should own the Article 3(3) notice internally?
This notice crosses more functions than Article 3(2).
Product / engineering
Owns:
- service data categories;
- collection;
- technical access;
- storage architecture.
Cloud/backend
Owns:
- storage;
- retention;
- export;
- APIs;
- logging.
Legal
Owns:
- contract duration/termination;
- data-use terms;
- third-party use;
- trade-secret framework.
Privacy
Owns:
- GDPR overlap;
- data subjects;
- legal basis;
- privacy notice alignment.
Product Compliance
Coordinates:
- Article 3 completeness;
- publication;
- versioning.
A spreadsheet owned only by ecommerce is unlikely to be sufficient.
Article 3(3) implementation workflow
Step 1 — identify the related service
Document what product functions depend on or are added/updated/adapted by the service.
Step 2 — identify the prospective data holder
Do not assume it is the hardware manufacturer.
Step 3 — split Product Data and Related Service Data
Create separate data inventories.
Step 4 — document volumes/frequency/storage/retention
Use actual service architecture.
Step 5 — document intended use
Legal/product/data teams should agree on stated purposes.
Step 6 — document third-party use
State intended third-party use and user-requested sharing route.
Step 7 — add contact/complaint/trade-secret/contract fields
These are essential Article 3(3) items.
Step 8 — review GDPR overlap
Where personal data are involved, conduct a separate privacy analysis.
Step 9 — publish before contract
Article 3(3) is pre-contractual information.
Step 10 — assign update triggers
Review when:
- service adds new data;
- retention changes;
- new third parties/processors are added;
- purposes change;
- contract duration/termination changes;
- product-service relationship changes.
Common Article 3(3) mistakes
Mistake 1: treating every app as a related service
Apply Article 2(6).
Mistake 2: copying the Product Data Notice
Article 3(3) is broader.
Mistake 3: not separating Product Data and Related Service Data
Real notices often distinguish them explicitly.
Mistake 4: omitting collection frequency
Article 3(3)(a) specifically asks for it for Product Data expected to be obtained.
Mistake 5: omitting the data holder's intended use
Article 3(3)(c) requires it.
Mistake 6: listing “manufacturer” as data holder without checking
Entities can differ.
Mistake 7: omitting geographical address
Article 3(3)(d) includes it.
Mistake 8: providing no practical communication route
Article 3(3)(e) asks for efficient contact.
Mistake 9: saying third-party sharing exists without explaining how to request/stop it
Article 3(3)(f).
Mistake 10: forgetting complaint rights
Article 3(3)(g).
Mistake 11: no trade-secret statement
Article 3(3)(h).
Mistake 12: no contract duration/termination
Article 3(3)(i).
Mistake 13: using the GDPR Privacy Notice as a substitute
Different transparency framework.
Article 3(3) checklist
- Related service identified under Article 2(6).
- Connected product(s) identified.
- Provider identified.
- Prospective data holder identified.
- Geographical address included.
- Other processing parties reviewed.
- Product Data expected to be obtained documented.
- Estimated Product Data volume documented.
- Product Data collection frequency documented.
- Product Data access/retrieval documented.
- Product Data storage documented.
- Product Data retention documented.
- Related Service Data documented.
- Related Service Data estimated volume documented.
- Related Service Data access/retrieval documented.
- Related Service Data storage/retention documented.
- Data holder own-use expectation stated.
- Purposes stated.
- Intended third-party use stated.
- Efficient contact route included.
- User-requested third-party sharing route included.
- Stop-sharing route included where applicable.
- Complaint right stated.
- Trade-secret holder position stated.
- Contract duration stated.
- Termination arrangements stated.
- Privacy/GDPR overlap reviewed.
- Notice version/date assigned.
- Update owner assigned.
Frequently asked questions
What is an EU Data Act Related Service Data Notice?
It is a practical name for the pre-contractual information required under Article 3(3) for a related service. The regulation does not require that exact document title.
What is a “related service”?
A digital service, including software, connected to the product in the manner defined by Article 2(6), such that it affects product functionality at purchase or later adds/updates/adapts product functions.
Is every mobile app a related service?
No. The app's relationship to the connected product's functions matters.
How is Article 3(3) different from Article 3(2)?
Article 3(2) focuses on the connected product's data characteristics and user access. Article 3(3) adds a broader related-service/data-holder disclosure including purposes, third-party use, identity/address, complaint rights, trade secrets and contract duration/termination.
Does the notice need Product Data and Related Service Data?
Where relevant, yes. Article 3(3) distinguishes Product Data expected to be obtained by the prospective data holder from Related Service Data that will be generated.
Who is the data holder?
That depends on the actual legal/technical arrangement. It may be the manufacturer, related-service provider, another group company or other party with the relevant rights/obligations.
Do I need to disclose intended data use?
Article 3(3)(c) asks whether the prospective data holder expects to use readily available data itself and the purposes, plus whether third parties are intended to use data for purposes agreed with the user.
Do I need a postal/geographical address?
Article 3(3)(d) includes the geographical address at which the prospective data holder is established.
Must the user be told how to request third-party sharing?
Article 3(3)(f) requires information on how the user can request sharing and, where applicable, end it.
Is there a complaint-right requirement?
Yes. Article 3(3)(g) addresses the user's right to lodge a complaint with the competent Article 37 authority.
Why does the notice mention trade secrets?
Article 3(3)(h) asks whether the prospective data holder is the trade-secret holder and, where not, the identity of the trade-secret holder.
Do I need to state contract duration?
Yes. Article 3(3)(i) addresses contract duration and termination arrangements.
Can this be combined with the Product Data Notice?
Potentially, if the structure remains clear and complete. Separate documents can be easier when product/service entities and data models differ.
Is the Related Service Data Notice the same as the Privacy Notice?
No. GDPR/privacy transparency remains separate and can apply alongside the Data Act.
Next steps
For the product side:
EU Data Act Product Data Notice Guide
For a copyable Article 3(2) structure:
For GDPR overlap:
EU Data Act vs GDPR for Connected Products
Primary sources and real implementation examples
Primary / official
- Regulation (EU) 2023/2854 — EU Data Act
- European Commission — Data Act explained
- European Commission — Data Act implementation FAQs
- European Commission — Data Act Legal Helpdesk
Implementations
- Signify — Generic Data Notices
- Signify — MasterConnect Article 3(3) Data Notice
- Vorwerk — Cookidoo Article 3(3) Service Notice
- Hikvision — Related Service Data Notice
- LEDVANCE — Article 3(3) example
- Xperi — EU Data Act related-service disclosure
RegCatalog provides product-data tooling and informational resources. It does not provide legal advice or certification. Related-service scope and Article 3(3) obligations can depend on the actual service/product/contractual arrangement.