This guide describes what you have to configure in your DPS to enable your organization to be compliant with the Data Act.
For the regulatory background, refer to EU Data Act Basic Concepts and Technical Implications of EU Data Act Compliance for OEMs who are Data Holders.
For a capability-level overview of what the DPS provides, refer to DPS Compliance to the Data Act.
Before you start
The configuration steps required, in the recommended order, are:
- Initial DPS configuration
- Raw Data Metrics configuration
- Data Recipient view configuration
- Paid Digital Services configuration for Data Recipients
- Terms of Service and Privacy Policy configuration
1. Initial DPS configuration
If you have not done it yet, follow the Initial DPS Configuration guide to establish the IoT connection, create the base Thing Definition, create the product model, register a product instance, and verify that data is published correctly.
This baseline is a prerequisite for every Data Act function, because you can only document and share data that the DPS is actually collecting.
2. Raw Data Metrics configuration
The Data Act applies to raw and pre-processed data that is readily available. In the DPS, this data is modeled through Simple Raw Data metrics, which are then grouped into a Metric Set that determines what can be exported and shared.
Note that in Servitly a raw metric is a technical concept (a Simple Metric that stores data published directly by a connected product), while the Data Act's raw data is a legal concept (the data the data holder must make available to users and authorized third parties). These usually overlap, but a Servitly raw metric may carry a value produced by a processing function on the device or at the edge, which may fall outside the Data Act's scope. To bridge this gap, every raw metric is included in the predefined Raw Data Metric Set , which governs Data Act operations (user data export and API access). So it is up to the Console user to define which metrics to include according to the Data Act definition.
What to configure:
- Define a Simple Raw Data metric for each data point your product makes available, such as temperature, pressure, error codes, or status.
To ease the configuration in case of many metrics, you can use the import CSV feature. - Review the Raw Data Metric Set grouping all raw data metrics. By default, it includes any created Raw Data metrics, and it is up to the Console user to exclude any metric that should not be shared, for instance, a raw metric that actually carries processed or enriched data produced by edge computing, which is out of scope.
- Document each metric so that recipients can interpret it correctly. For each metric, you can define the Technical Description (e.g., data format, sampling frequency, publishing policy). DPS users will find these details in the Documentation section under the Data Management page.
3. Data Recipient view configuration
A Data Recipient is a third party that a customer has authorized to access their raw data. To let these users operate in the DPS, they can leverage the predefined Data Recipient view.
If the Data Recipient view is missing, here are the steps you can follow to configure the view.
Note that the Data Recipient view is available out of the box, so in most cases no additional configuration is required. Follow the steps below only if the Data Recipient view is missing from your DPS configuration and you need to recreate it.
What to configure:
- In Interfaces / Views, add the view named Data Recipient, and configure the main pages:
- The Customers page, which displays the list of customers authorized to the Data Recipient.
- The Machines page, which displays the list of things authorized by customers.
- The Data Management predefined page providing access to documentation and data sharing.
- Associate the view with the Data Recipient user type.
For this user type, data access is restricted to the Raw Data metric set only.
To define pages, you can leverage the set of ready-to-use templates available in the Data Act component.
4. Paid Digital Services configuration for Data Recipients
The Data Act entitles the ORganization to request reasonable compensation from third parties (other than the end-user) that access data. In the DPS, you turn this right into a managed, recurring revenue stream through Digital Services.
You can define Digital Plans and Add-ons that Data Recipients must subscribe to access shared data.
What to configure:
- Go to the Digital Services page and select the Data Recipient tab.
- Define Digital Plans, Add-ons and related features associated with them.
Note that a Data Recipient to access data via API, must subscribe to a Plan/Add-on with the Raw Data Access feature included. So it is up to the Console user whether to leave this feature in the Base plan or add it to a paid one. This is optional from a strictly technical-compliance point of view, but it is what lets you monetize third-party access rather than simply granting it.
5. Terms of Service and Privacy Policy for Data Recipients
To be compliant with the Data Act, you must publish Terms of Service and a Privacy Policy that reflect the Data Act obligations, for example, which data is made available, the conditions under which users and third parties can access it, and the terms governing data sharing. Customers and Data Recipients (third parties) must accept these legal documents during self-registration and login or, optionally, at the first paid plan purchase.
What to configure :
- Go to Service / User Agreements and update the already present Privacy Policy and Terms of Service agreements.
- In case you want to publish more specific agreements for your Customer and Data Recipient users, you can create new agreements with different targets.
- Optionally, you can define addendums to be accepted when a specific Digital Plans and Add-ons is purchased the first time.
The DPS automatically ensures that every user accepts the latest version of each agreement; when a document is amended, users are asked to review and accept it again at their next login.