Search every question across sub-FAQs

The Data Act context is the starting point for this answer. Keep enough evidence to show whether the request was valid, how the company responded, what data was made available or withheld, and which safeguards governed the data after transfer. The evidence file should be built around the Article 17 request contents and the Article 18 response, not around generic compliance notes.

A useful record includes the written request, requester identity, statutory task and legal provision, exceptional-need route, public-emergency declaration or non-emergency exhaustion analysis, data scope and metadata, personal-data analysis, trade-secret identification, timestamps, refusal or modification reasons, compensation calculation, delivery logs, onward-sharing notices, erasure notice, and competent-authority communications.

For b2g exceptional need, the Data Act record should identify the source clause, Commission guidance, actor role, dataset, request or contract trigger, and the owner who approved the interpretation.

For b2g exceptional need, keep the cited external URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the answer remains auditable.

For b2g exceptional need, the Data Act workflow should name the legal, product, procurement, cloud, support, or security owner who can change the affected process.

For b2g exceptional need, use one accountable owner per action, then record consulted teams and evidence dependencies separately.

For b2g exceptional need, the Data Act evidence should be concrete enough for a later reviewer to reconstruct why the team classified the product, service, request, or contract in scope.

For b2g exceptional need, useful evidence includes source URLs, data inventories, contract clauses, request logs, technical controls, customer notices, and approval records.

For b2g exceptional need, the Data Act answer should be reviewed when the product, service model, dataset, customer role, public-sector request path, or contract wording changes.

For b2g exceptional need, set a review date and an event trigger instead of relying on a one-time legal note.

Start by confirming that the supplier is providing a data processing service to a customer, such as cloud or edge services using configurable, scalable computing resources. The Commission FAQ explains that the Data Act concept covers common IaaS, PaaS, and SaaS delivery models when the service has the Article 2(8) characteristics.

Then ask whether the contract removes the obstacles listed in Article 23: termination after the permitted notice and successful switch, new contracts with another provider, porting exportable data and digital assets, functional equivalence where applicable, and technically feasible unbundling.

The Data Act context is the starting point for this answer. Article 25 requires the customer's switching rights and the provider's obligations to be clearly set out in a written contract that the customer can store and reproduce before signing. Procurement should therefore reject exit language that is only in a help-center article, commercial slide, or support policy outside the contract pack.

The contract should cover at least switching or porting on request, support for the customer's exit strategy, termination mechanics, a maximum notice period, exportable data categories, provider-internal data exemptions, a retrieval period, erasure after retrieval or an agreed later date, and any permitted switching charges.

The Data Act context is the starting point for this answer. For switching or porting, Article 25 requires reasonable assistance, due care to maintain business continuity, clear information on known continuity risks, and high security during transfer and retrieval. A procurement checklist should ask for named support channels, technical documentation, migration tooling, continuity risk notices, and security controls during the switch.

Article 26 adds a separate information obligation: the provider must give switching and porting procedures, methods, formats, known restrictions, technical limitations, and a reference to an up-to-date online register for data structures, data formats, relevant standards, and open interoperability specifications.

For cloud switching procurement checklist, the Data Act record should identify the source clause, Commission guidance, affected service, decision owner, and the evidence used to approve the supplier's switching terms. Keep the contract pack, supplier redlines, export tests, fee schedule, and online-register snapshot together so the decision can be checked later.

Review the checklist again when the service architecture, supplier documentation, standards references, or renewal timetable changes. A later reviewer should be able to see what was agreed, why it was acceptable, and what would require a fresh review.

Under the Data Act, Article 29 phases out switching charges, including data egress fees, so that from 12 January 2027 providers cannot impose them, and in the interim period any charge must not exceed the costs the provider actually incurs. Procurement should ask the supplier to confirm which date its contract reflects and how any interim charge is calculated.

A buyer should reject open-ended egress pricing and require the contract to state that switching charges fall away on the statutory date, so the cost of leaving is predictable rather than a lock-in lever.

Under the Data Act, exportable data covers the data the customer generated or imported and the digital assets it is entitled to, but it excludes assets protected by third-party intellectual property rights or that would reveal the provider's own trade secrets. Procurement should ask the supplier to define the boundary in the contract rather than discovering it during a migration.

The checklist should confirm the formats, the metadata included, and the configuration or schema material needed to make the export usable on the destination service, not just a raw dump that the customer cannot rebuild from.

Under the Data Act, functional equivalence applies to switching between services of the same service type, mainly IaaS, where the destination should deliver a materially comparable outcome after the customer has reconfigured the service. For PaaS and SaaS the obligation is the lighter duty to export the data and digital assets in a structured, commonly used, machine-readable format.

Procurement should establish which obligation applies to the service being bought, because expecting functional equivalence from a SaaS provider, or accepting only a raw export from an IaaS provider, both misread the Regulation.

Under the Data Act, the contract should give the customer a minimum 30-day retrieval period to recover its exportable data after the switch is initiated, after which the provider erases the data unless a longer period is agreed or another legal duty applies. Procurement should make sure the retrieval window and the erasure trigger are both explicit.

A buyer should also confirm how erasure is evidenced, so it can show that the data left the old provider once the migration and any agreed retention period ended.

Under the Data Act, Article 30 expects providers of the same service type to support interoperability through open interoperability specifications and harmonised standards listed in a central repository, and Article 26 requires the provider to reference an up-to-date register of data structures, formats, and standards. Procurement should ask which standards the export actually uses.

The checklist should confirm that the supplier's stated formats and interfaces map to those open specifications, so the destination provider can ingest the data without a bespoke, supplier-controlled conversion.

Under the Data Act, custom-built services not offered at broad commercial scale and services supplied as a non-production test version are treated differently, and providers may claim that some Chapter VI duties do not apply. Procurement should require the supplier to state the exemption it relies on and the factual basis, rather than accepting a bare assertion.

A buyer should treat an exemption claim as a risk to price and document, because a service that genuinely sits outside the switching rules offers far weaker exit protection than a standard data processing service.

Under the Data Act, switching should be technically feasible and the provider should support a managed transition, which in practice means a buyer can run the old and new services in parallel for a period and unbundle interdependent services where feasible. Procurement should ask how the supplier supports a phased cutover rather than a single hard switch.

The checklist should confirm the assistance, documentation, and continuity measures available during the overlap, so the migration does not force an all-or-nothing move that risks business continuity.

Under the Data Act, the core cloud-switching obligations apply from 12 September 2025, and switching charges must be removed by 12 January 2027, so procurement should track which obligations a contract already meets and which depend on a future date. A renewal or new signature is the moment to align the contract with the applicable date.

The team should also set event triggers, such as a change of service architecture or supplier documentation, so the contract is re-checked when the underlying service or the applicable obligation changes.

Under the Data Act, a connected product is an item that obtains, generates, or collects data concerning its use or environment and can communicate product data through an electronic communications service, a physical connection, or on-device access. The definition also excludes items whose primary function is storing, processing, or transmitting data for a party other than the user.

The practical question is whether the product itself produces or captures operational data and has a route to communicate that data. Smart-home appliances, connected cars, medical or fitness devices, industrial machinery, agricultural machinery, planes, robots, and similar sensor-equipped products are typical examples when the rest of the scope test is met.

Yes. For connected-product scope, the Data Act applies to manufacturers of connected products placed on the market in the Union and providers of related services, regardless of where those manufacturers or providers are established. It also applies to users in the Union of those connected products or related services.

The Commission FAQ explains that placing on the market happens once for each individual product after the manufacturing stage, when ownership, possession, or another property right is transferred between economic actors. Later transactions are making available on the market, not a new first placement.

Under the Data Act, a user is a natural or legal person that owns the connected product, has contractually received temporary rights to use it, or receives related services. The user can be a consumer, business, or public sector body; the key point is a stable ownership, rental, lease, or related-service position rather than casual physical interaction.

The Commission FAQ gives the example of an airplane passenger: use of a connected aircraft through a transport service does not itself transfer property-type rights over the aircraft, so the passenger is not a Data Act user of the aircraft.