Search every question across sub-FAQs

The Data Act context is the starting point for this answer. Chapter IV is framed as protection for all businesses, with particular relevance for SMEs facing stronger bargaining positions in data-sharing negotiations. Article 13 itself applies to an enterprise on which a covered unfair term has been unilaterally imposed by another enterprise.

SME status is still operationally important. The Commission says the model contractual terms were developed to help parties, especially SMEs, implement the Data Act, and the Data Act explainer highlights Chapter IV as a tool against stronger parties imposing non-negotiable data access and use terms.

The Commission model contractual terms are voluntary tools, not a replacement for Article 13. They can help draft Data Act data-sharing contracts and benchmark whether a clause structure is aligned with fair, reasonable, and non-discriminatory rights and obligations.

The Commission source says the model contractual terms for Data Act data sharing are compliant with Chapter IV on unfair contract terms. Teams should still adapt them to the actual data-sharing relationship and keep a clause-by-clause rationale when changing them.

The Data Act context is the starting point for this answer. Keep enough evidence to show the clause text, who supplied it, whether the other party tried to negotiate it, the data-related obligation affected, the Article 13 category considered, and the final outcome. The file should let a later reviewer distinguish a negotiated clause from a unilateral template clause.

For practical contract review, use a matrix with fields for clause location, data type or dataset, contract relationship, Article 13 category, always-unfair or presumed-unfair flag, negotiation evidence, fallback wording, approver, and date. Add model-term comparison where the Commission wording was used or intentionally changed.

Keep the legal basis and the decision trail together. For Article 13 work, the record should cite the Data Act source clause, the specific Article 13 paragraph used, the Commission guidance or model-term reference relied on, and the contract version that was reviewed. That makes it clear why a term was treated as unilaterally imposed, always unfair, presumed unfair, or outside the scope of Article 13.

Teams should also retain the implementation artifact that shows how the decision was applied in practice, such as the redlined contract, review memo, approved template, or deviation note.

Assign one accountable owner who can change the contract or workflow affected by Article 13. For a Data Act unfair-terms review, that is usually the legal or commercial lead for the contract, with procurement, product, cloud, support, or security teams consulted where their process is affected.

For implementation, ownership should track the action: one owner for template updates, one owner for contract review approvals, and one owner for operational follow-up on the workflow or system that uses the clause. That avoids a generic checklist and makes the decision executable.

The Data Act context is the starting point for this answer. A user is a natural or legal person that owns a connected product, has temporary contractual rights to use that connected product, or receives a related service. A company can be a user; a consumer can be a user; and more than one person can be a user of the same connected product when ownership, lease, rental, or service rights support that position.

Do not treat every end customer, passenger, employee, or account contact as a Data Act user. The Commission FAQ explains that the user needs a stable right over the connected product or the related service. A person merely benefiting from a broader service, such as transport, is not automatically a user of the connected product that provides that service.

The Data Act context is the starting point for this answer. The Chapter II role analysis applies to connected products and related services. A connected product obtains, generates, or collects data about its use or environment, can communicate product data electronically, physically, or through on-device access, and is not primarily a data storage, processing, or transmission service for someone other than the user.

A related service is a digital service, including software, that is connected with the product so that the product cannot perform one or more functions without it, or is later connected to add, update, or adapt product functions. The Commission FAQ points to bidirectional data exchange and an effect on the product's functions, behaviour, or operation as key practical indicators.

A data holder is the person or organisation that has the right or obligation under the Data Act, other EU law, or national law to use and make data available. For product and related-service data, the role turns on who can lawfully retrieve, generate, use, and make available the data, not simply on who made the hardware.

A manufacturer will often be a data holder, but the Commission FAQ says it is not always the data holder. A component supplier, related-service provider, or another contracted entity can be a data holder if it receives or controls access to readily available data and is identified in the contractual and pre-contractual setup. A person can also be a user for one product and a data holder for another, but not both for the same data in the same relationship.

The Data Act context is the starting point for this answer. Users can access readily available product data and related service data, together with the metadata needed to interpret and use it. Where the data is not directly accessible from the product or service, the data holder must make it available without undue delay, in the same quality available to the data holder, easily, securely, free of charge, and in a structured, commonly used, machine-readable format.

The Commission FAQ describes the core Chapter II data set as raw and pre-processed data that is readily available to the data holder as a result of technical design. Highly enriched, inferred, or derived data resulting from additional investments, proprietary complex algorithms, or substantial transformation is outside the mandatory Chapter II sharing obligation. Personal data can be in scope, but only subject to GDPR compliance.

Yes, if Article 5 applies. At the user's request, or at the request of a party acting on behalf of the user, the data holder must make readily available data and necessary metadata available to a third party under the Data Act conditions. This right exists even if the user also has direct access, provided there is a data holder with readily available data.

A third party receiving data under Article 5 is a data recipient for that transaction, but not the user. The third party must be acting for purposes related to its trade, business, craft, or profession and must be in the Union for the Chapter II mandatory sharing obligation to apply. Digital Markets Act gatekeepers are not eligible third parties for this mandatory IoT data-sharing mechanism.

The Data Act context is the starting point for this answer. A third party receiving data at the user's request may use the data only for the purposes and under the conditions agreed with the user, subject to personal-data law where personal data is involved. It must erase the data when no longer necessary for the agreed purpose unless the user has agreed otherwise for non-personal data.

Article 6 also sets explicit prohibitions. A recipient must not manipulate the user's choices, use the data for profiling unless necessary for the service requested by the user, pass the data onward except under the Article 6 conditions, give the data to a DMA gatekeeper, develop a competing connected product, undermine product security, disregard trade-secret measures, or prevent a consumer from sharing received data with other parties.

The Data Act context is the starting point for this answer. Data holders should build the request process around access that is easy, secure, non-discriminatory, and limited to necessary verification. They must not make user choices unduly difficult, require unnecessary information to verify a user or third party, or keep access logs beyond what is needed for request execution and infrastructure security and maintenance.

Data holders can protect legitimate interests, but the safeguards are not blanket refusal rights. The Data Act allows security restrictions where lawful security requirements could be undermined with serious adverse effects; it also allows trade-secret measures, withholding, suspension, or exceptional refusal only under the specific Article 4 and 5 conditions. Technical protection measures such as encryption or smart contracts must not discriminate between recipients or hinder Data Act access rights.

The Data Act covers personal and non-personal data, but it does not supersede the GDPR. Article 1(5) says EU and national personal-data and privacy law continue to apply, and those rules prevail in a conflict. The Commission FAQ states that the GDPR is fully applicable to personal-data processing under the Data Act.

If the user is the data subject, Data Act access and sharing complement GDPR access and portability rights. If the user is not the data subject whose personal data is requested, the data holder may make the personal data available to the user or third party only where there is a valid GDPR legal basis and, where relevant, Article 9 GDPR and ePrivacy conditions are met. Data holders and recipients should therefore classify personal data, identify controller roles, and keep the GDPR legal-basis analysis separate from the Data Act role analysis.

Keep a short decision note that links the role analysis to the relevant Data Act article or Commission FAQ, the product or service in scope, the user type, the data holder, any third party or recipient involved, and the date of the decision. That gives later reviewers enough context to see why the team treated a person as a user, a party as a data holder, or a recipient as a third party.

The note should also capture the request path, contract or account reference, the data categories involved, and any GDPR or trade-secret issue that changed the answer.

Assign one accountable owner who can change the product, contract, support, procurement, or privacy process that the role decision affects. For most teams, that is legal, privacy, product, or compliance, depending on which workflow actually controls the Data Act response.

If multiple teams are involved, keep one owner and list the consulted teams separately so the record stays easy to update when the product or service changes.

Keep Data Act evidence that shows how the team decided whether the product or service was in scope and who the relevant actors were. The most useful items are the contract, user-facing notice, product or service description, data inventory, access flow, and any request or refusal record.

If the answer depends on a legal boundary, keep the exact wording that supports it. That matters especially for user status, related-service status, direct versus indirect access, and third-party sharing limits.

Review the Data Act decision whenever the product, service, contract, access method, or data-sharing pathway changes. A new related service, a new user type, a new data holder, or a new third-party recipient can change the answer even if the product itself stays the same.

It is also worth reviewing the decision after any GDPR, security, trade-secret, or contract update, because those changes can affect what data can be made available and to whom.

It is Commission guidance for automotive stakeholders applying Chapter II of the Data Act to vehicle data. The guidance focuses on connected vehicles, vehicle-related services, data within the scope of Chapter II, and the access rules for users and third parties chosen by users.

The guidance is not a new legal obligation and does not extend or modify the Data Act. It is also sector-specific: it concerns the automotive sector, including OEMs, suppliers, aftermarket service providers, and insurance providers, and should not be automatically applied to other industries or the public sector.

The guidance covers vehicles that qualify as connected products under the Data Act: vehicles that obtain, generate, or collect data about use or environment and can communicate product data electronically, by physical connection, or through on-device access.

A vehicle-related service must be a digital service connected with the vehicle in a way that affects the vehicle's operation or behavior. Examples in the guidance include remote vehicle-control services, some predictive maintenance services that exchange data with the vehicle and adapt functionality, cloud-based driver preference services, and dynamic route optimization shown through the vehicle interface.

The Data Act context is the starting point for this answer. For this guidance, vehicle data means product data generated by the use of a connected vehicle and vehicle-related service data. The in-scope set includes raw and pre-processed data, together with relevant metadata needed to interpret and use the data.

The guidance treats inferred or derived information as outside Chapter II. That boundary matters for repair, mobility, and insurance use cases because a measured value such as speed, location, odometer value, battery level, tire pressure, or fault information can be in scope, while a proprietary driver score, route prediction, risk assessment, or other new insight may be outside scope.