EU Data Act requests for connected-product data: Cyprus operator guide

Identify the connected product, related service and data holder

A connected product generates data about its use or environment and can communicate those data through an electronic communications service or physical connection. The Data Act covers many consumer and industrial objects, from a wearable or smart appliance to agricultural machinery. A related service is a digital service connected to the product's functions, such as an app that adjusts the appliance's operation. A Cyprus retailer selling third-party devices may have pre-contract information duties but may not hold the data. A manufacturer, cloud operator and app provider can have different obligations. Map the actual technical and contractual roles before assigning one team to answer every request.

The user can be a natural or legal person that owns, rents or leases the connected product or receives a related service. The data holder is the party with the right or obligation under the Regulation or other law to use and make data available. The Commission's explanation notes that a fridge and its related app can have two potential data holders. A customer may therefore need a clear route to the correct holder for each stream. Document which entity controls sensor data, service-event data, retention and export, including where a Cyprus subsidiary relies on a group company abroad.

This is a different query from a GDPR right of access. A business user can request non-personal machine data under the Data Act, and the request can concern data about device performance rather than information about an identified person. Conversely, device data may include personal data, so GDPR still applies. Do not redirect every Data Act request to a privacy inbox with a one-month GDPR template, or deliver personal data solely because the requester owns the hardware. Build one intake workflow that identifies the legal route and escalates overlapping cases to privacy specialists.

For the distinct GDPR response process, see the Cyprus GDPR access-request guide.

Basis and guidance: Regulation (EU) 2023/2854, Data Act, Articles 3–5 and 50; European Commission: Data Act explained; European Commission: Data Act gives users control over connected-device data

Inventory raw, pre-processed and readily available data

Chapter II concerns product data and related-service data, including metadata needed to interpret and use them. The Commission says raw and pre-processed data readily available to the holder are in scope. Examples include a machine's temperature, pressure, location or operating-state readings. Highly inferred or derived data and content are generally outside that Chapter II access category; an analytics score developed through substantial interpretation is not automatically the same as the sensor values behind it. Record for each field its source, processing stage, whether the holder can lawfully obtain it without disproportionate effort and whether the requester can use it without metadata.

Avoid two opposite errors. A company should not withhold a raw stream because it is commercially useful or because a dashboard already shows a summary. Nor should it promise access to every proprietary model output, film or software asset associated with a smart product. The Commission's example distinguishes data about a television's screen brightness from the audiovisual film being watched. Give engineers a classification guide with representative fields and exceptions; a legal reviewer should test borderline processed metrics against the statutory definitions and Commission guidance rather than relying on a product team's label of 'derived'.

Keep an operational inventory: product family, model, firmware version, sensor or event name, unit, sampling interval, timestamp standard, retention period, storage location and export format. The same term can refer to different data in a device and its app. If a user's request concerns three months of machine operation, the export should specify time zone, gaps, calibration or units as necessary to interpret it. Article 4 speaks of relevant metadata and the same quality available to the data holder; a raw CSV without a field dictionary may technically contain numbers yet fail to make the data usable.

For the separate privacy retention design, consult the GDPR retention-schedule guide.

Basis and guidance: Regulation (EU) 2023/2854, Data Act, Articles 3–5 and 50; European Commission: Data Act explained

Apply the 2025 general date and 2026 design date correctly

Article 50 states that the Data Act applies from 12 September 2025, while the specific design obligation in Article 3(1) applies to connected products and related services placed on the market after 12 September 2026. A company releasing a device in October 2026 should assess default direct user access in the product design; it should not assume that a 2025 model and a new 2026 model have identical design obligations. At the same time, the later design date does not suspend the whole Regulation or Article 4 request route until 2026. A request received now needs an actual legal assessment.

Article 3 also contains pre-contract information duties about the type, format and estimated volume of product data, continuous generation, storage and how the user can access, retrieve or erase data. Related-service providers have their own information list. Check product pages, order flows, rental terms and app sign-up against the exact Article 3 paragraphs that apply. This is not solved by a privacy notice alone: business users need to know the data generated and the access mechanism before contracting. Give commercial and support teams an accurate data-sheet maintained with firmware changes.

For new product design, test whether the user can obtain product and related-service data easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format and, where relevant and technically feasible, directly. A dashboard screenshot may be useful for a person but may not satisfy a machine-readable export. A technical API may work for developers while being unusable to an ordinary consumer without instructions. Product management should document the technically feasible route, authentication, metadata and user support, with separate testing of an API, download and third-party transfer path.

For the separate personal-data access process, see the GDPR access-request guide.

Basis and guidance: Regulation (EU) 2023/2854, Data Act, Articles 3–5 and 50; European Commission: Data Act explained; European Commission: Data Act gives users control over connected-device data

Build a simple user-request process with secure verification

Article 4 says that where data are not directly accessible, the holder must make readily available data and relevant metadata accessible to the user without undue delay, in the quality available to the holder, easily, securely and free of charge, using a comprehensive, structured, commonly used and machine-readable format. A simple electronic request should be available where technically feasible. Design an intake form that identifies the requester, product, period, data stream and preferred delivery method without forcing the user to justify the commercial reason. Confirm ownership, rental or service entitlement and protect another person's data when devices have multiple users.

Log the request date, device ID, data map, verification result, legal basis for any personal data, export generated, security review, delivery and any refusal or restriction. A ticket should be traceable to the fields delivered. If the holder cannot produce a requested category, distinguish data it never obtained or could not readily obtain from data it deleted under a legitimate retention schedule. Explain the actual reason and offer an available alternative rather than sending an unexplained empty file. The company should avoid charging the user for access covered by Article 4, while recognising that other data-sharing regimes can have different compensation rules.

For a fleet or shared device, identify who is the Data Act user for the requested period. A lessee, owner, driver and maintenance provider may each have different interests, and sensor data can reveal a person's movements. Do not assume that the current account login authorises transfer of all historic data from previous users. Apply access controls to the time and product entitlement, then run a GDPR assessment for any personal-data disclosure. Support staff should have an escalation route for disputed entitlement rather than improvising a release or denying all data by default.

For the separate GDPR access deadline and identity checks, use the GDPR access guide.

Basis and guidance: Regulation (EU) 2023/2854, Data Act, Articles 3–5 and 50; European Commission: Data Act explained

Handle a user's instruction to share with a third party

Article 5 provides a route for the user to ask the data holder to make readily available data available to a third party chosen by the user, subject to the Regulation's conditions. This can support an independent repairer or maintenance service. The Commission notes that designated gatekeepers under the Digital Markets Act are excluded from this third-party route. Build a verification step for the named recipient, the data categories and the instruction. A user should not have to export a large dataset manually if the statutory direct-sharing route applies, but the holder should not send an open link to an unverified email address.

Document the technical interface and agreement governing the third party's use, including purposes agreed with the user, data protection, trade secrets and security. The Data Act restricts certain uses by third parties, including use to develop a competing connected product. This is not a blanket ban on an aftermarket repair business competing for service revenue. The request record should show the user's choice, recipient, product, period and delivery evidence. If the third party later misuses the data, the holder needs an audit trail of what it transmitted and on what basis.

Where personal data are involved, Data Act access does not replace a valid GDPR legal basis. The Commission says that if the Data Act user is not the data subject, the holder must check an appropriate basis before making that person's personal data available. For example, a business that leases vehicles should not presume it can send every driver's location history to an outside analytics provider merely because it is the contracting user. Identify personal fields, data subjects and lawful sharing conditions before transmission; separate non-personal machine data where the law permits a narrower response.

For related joint-controller questions when organisations jointly set purposes, see the GDPR joint-controller guide.

Basis and guidance: Regulation (EU) 2023/2854, Data Act, Articles 3–5 and 50; European Commission: Data Act explained

Use security and trade-secret safeguards precisely

The Data Act has safeguards for product safety, security and trade secrets; they are not a generic exemption for commercially sensitive data. Article 4 permits a contractual restriction or prohibition where access, use or further sharing could undermine legally required product security and seriously affect health, safety or security of natural persons, subject to its conditions. Where the holder refuses on that basis, the Regulation provides for notice to the competent authority. Record the exact risk, affected dataset and why a narrower safe release would not suffice. A statement that 'security policy prohibits exports' is too broad to be a reliable decision file.

Trade secrets can be protected through agreed technical and organisational measures. Article 5 has detailed rules for third-party sharing and exceptional case-by-case refusal where serious economic damage is highly likely despite safeguards. The Commission proposal to amend some Data Act provisions is under discussion, so check the current consolidated text before applying a refusal. Do not treat all data from a patented or proprietary device as automatically secret; identify the particular secret, who holds it and the confidentiality measure needed. If only a subset is affected, assess whether the remaining data and metadata can be delivered.

Do not mistake cybersecurity for opacity. Strong authentication, scoped tokens, encrypted transport, rate limits and logs can enable lawful data access while reducing leakage risk. An export path that requires a developer to email raw database files is both unsafe and hard to maintain. The engineering design should protect unrelated users, prevent device-command injection and make data integrity verifiable. Document cases where a real-time stream is not technically feasible, because Articles 3 and 4 expressly qualify continuous or direct access by relevance and technical feasibility.

For separate product-security lifecycle obligations, see the Cyber Resilience Act guide.

Basis and guidance: Regulation (EU) 2023/2854, Data Act, Articles 3–5 and 50; European Commission: Data Act explained; Commission proposal COM(2025) 837, Digital Omnibus

Test three Cyprus connected-product requests

A Cyprus agricultural-equipment supplier provides connected irrigation controllers. A farm asks for time-stamped flow and pressure readings so an independent service company can optimise water use. The supplier identifies the farm as the product user, maps the readily available sensor fields, includes units and timestamp metadata, and checks the named third party's access route. It does not withhold raw pressure data because its own dashboard sells analytics, and it does not assume its proprietary predictive score is automatically part of the same dataset. The file records the Data Act basis and technical transfer.

A rental company operates connected vehicles and requests driver-location history for its whole fleet. The device vendor separates non-personal vehicle telemetry from location data linked to individual drivers, verifies the rental company's user status and escalates the personal-data portion for GDPR analysis. It does not provide every driver's historic route merely because the company signed the fleet lease. Where a lawful basis supports release, the export is limited to authorised vehicles and periods and contains metadata so the recipient can interpret gaps and time zones.

A smart-home manufacturer places a new device on the EU market after 12 September 2026. It has a polished app chart but no structured user export, and the support team sends screenshots on request. Product and legal teams review Article 3(1) access by design, build a secure machine-readable download and document the relevant data fields. They also update pre-contract information so buyers understand data volume, retention and access. The design review is prospective for the new device; Article 4 requests for products already in use are assessed separately against readily available data.

For unrelated website privacy rights, review the GDPR request resource.

Basis and guidance: Regulation (EU) 2023/2854, Data Act, Articles 3–5 and 50; European Commission: Data Act explained; European Commission: Data Act gives users control over connected-device data

Maintain a product-level Data Act control file

The control file should include role mapping, the product and service data inventory, user-identity rules, pre-contract disclosures, export format, metadata dictionary, Article 3 design assessment, Article 4 request workflow, third-party transfer process, GDPR assessment and security or trade-secret decisions. Record firmware or cloud changes that add data streams or alter retention. Test a sample request from start to finish with a person who does not know the engineering system: can they find the route, authenticate, obtain an understandable file and see where a refusal was explained? Operational testing catches problems that a policy alone will not.

Assign ownership across product, support, security, privacy and legal teams. The support desk should know whether it is answering a Data Act request, GDPR request or cloud-switching request; each has a different scope. Keep records of data delivered and the technical quality available to the holder at the time. If the device is shared, document how the process avoids exposing another user's data. For a third-party transfer, retain the user's instruction and recipient verification. Review templates when new products, sensors or related services launch instead of waiting for the first difficult request.

As of October 2026 the Digital Omnibus proposal would amend parts of the Data Act, but it remains a proposal and must not be substituted for the current Regulation. Verify the current EUR-Lex text and Commission implementation guidance before changing refusals or product design. This page concerns connected-product and related-service data; the Data Act's cloud provider switching obligations require a separate analysis. The practical goal is a response that gives the user the data the law covers in a usable form, while documenting genuine boundaries for privacy, secrets and safety.

Basis and guidance: Regulation (EU) 2023/2854, Data Act, Articles 3–5 and 50; European Commission: Data Act explained; Commission proposal COM(2025) 837, Digital Omnibus

Primary sources and scope

Sources checked: October 8, 2026. This guide concerns the Republic of Cyprus. Examples are hypothetical, not client case studies. Check current official requirements before making a filing.

• Regulation (EU) 2023/2854, Data Act, Articles 3–5 and 50
• European Commission: Data Act explained
• European Commission: Data Act gives users control over connected-device data
• Commission proposal COM(2025) 837, Digital Omnibus

Practical guides for this topic

• EU Data Act cloud-switching terms for a Cyprus SaaS provider

  An Article 23–30 Data Act contract and product checklist for Cyprus SaaS/cloud providers: exportable data, notice, transition, retrieval, interfaces and the 2027 switching-charge rule.