Search every question across sub-FAQs

The Article 32 safeguard is aimed at providers of data processing services, including cloud and edge service contexts covered by the Data Act's data processing services chapter. The protected data is non-personal data held in the Union and falling within the scope of the Regulation.

This is narrower than every foreign authority request a company might receive. A product manufacturer, connected-product data holder, support team, or ordinary business system owner should first ask whether the request is addressed to the provider of a data processing service and whether the requested material is non-personal data held in the Union.

The Data Act context is the starting point for this answer. Providers must maintain technical, organisational, and legal measures, including contractual measures, to prevent third-country governmental access or transfer where the access or transfer would conflict with Union law or the national law of the relevant Member State. The Commission's explainer gives implementation examples such as encryption, audits, and adherence to certification schemes.

Article 28 also creates a transparency obligation: providers must publish and keep updated the jurisdictions whose authorities could seek access through the provider's ICT infrastructure, and must describe the technical, organisational, and contractual measures used to prevent conflicting international governmental access or transfer.

The Data Act context is the starting point for this answer. No. A third-country court judgment, tribunal decision, or administrative authority decision requiring access to or transfer of covered non-personal data is recognised or enforceable only if it is based on an international agreement in force between the requesting third country and the Union or a Member State, such as a mutual legal assistance treaty.

The intake question should therefore be: what is the exact legal instrument, and what international agreement does it rely on? Without that link, the provider moves to the fallback Article 32 conditions rather than treating the request as automatically enforceable.

The Data Act context is the starting point for this answer. Article 32 allows access or transfer without an international agreement only if defined safeguards are met. The third-country system must require reasons and proportionality, the decision must be specific, the provider's reasoned objection must be reviewable by a competent third-country court or tribunal, and that court or tribunal must be empowered to take account of relevant legal interests protected by Union or Member State law.

This is the core conflict analysis. A provider should not answer only with a business approval or general law-enforcement cooperation statement; it needs a record showing how each Article 32 condition was checked for the request.

The Data Act context is the starting point for this answer. The provider may ask the relevant national body or authority competent for international cooperation in legal matters for an opinion on whether the Article 32 conditions are met. Article 32 specifically calls out this route where the decision may relate to trade secrets, commercially sensitive data, intellectual property-protected content, or transfer that may lead to re-identification.

The provider must ask that national body or authority for an opinion if it considers that the decision or judgment may affect national security or defence interests of the Union or its Member States. If there is no reply within one month, or the opinion says the conditions are not met, the provider may reject the access or transfer request on those grounds.

The Data Act context is the starting point for this answer. Article 32 requires minimisation. If the conditions for access or transfer are met, the provider must provide the minimum amount of data permissible in response to the request, based on the provider's reasonable interpretation of the request or the interpretation of the relevant national body or authority.

The evidence file should therefore include both the requested data and the data actually disclosed. That lets a later reviewer see why excluded fields, logs, metadata, backups, or derived records were outside the minimum permissible response.

The Data Act context is the starting point for this answer. Yes, Article 32 requires the provider to inform the customer about the existence of a third-country authority request before complying with that request. The exception is where the request serves law-enforcement purposes and withholding notice is necessary to preserve the effectiveness of the law-enforcement activity.

Customer notice should be a controlled workflow, not an informal support message. The record should show whether notice was given, what was said, when it was sent, and, if notice was delayed or withheld, the documented law-enforcement reason.

The Data Act context is the starting point for this answer. International government access under Article 32 is not the same as Chapter V business-to-government data sharing. Chapter V concerns EU public sector bodies, the Commission, the European Central Bank, and Union bodies accessing privately held data where there is an exceptional need. Article 32 concerns third-country governmental access or transfer of non-personal data held in the Union by providers of data processing services.

Keeping those workflows separate matters because their triggers, requesters, data categories, and safeguards differ. A provider receiving a non-EU authority request should not reuse an EU public-emergency request template without checking Article 32.

The Data Act context is the starting point for this answer. The minimum useful evidence set is the received request, the identity and authority of the requester, the requested data inventory, the EU or Member State conflict assessment, any international-agreement analysis, any national-authority opinion request or response, the customer-notice record, the minimisation analysis, and the final disclosure or refusal log.

For standing compliance, keep the published Article 28 web disclosure, contract references to that web page, safeguard descriptions, control-owner assignments, and change history for technical, organisational, legal, and contractual measures. These records show that the provider had preventive controls before the request, not only a one-off response after escalation.

The Data Act context is the starting point for this answer. Start by freezing the request record and routing it to legal, security, cloud operations, and the customer account owner. Then confirm whether Article 32 applies, whether an international agreement supports recognition or enforceability, whether no-agreement safeguards are met, whether a national-authority opinion is needed, whether customer notice is required or temporarily restricted, and what minimum data can be disclosed if compliance is allowed.

The highest-risk shortcut is treating the request as an ordinary support ticket. The Data Act expects a provider-level conflict review, not only identity verification of the requester.

Under the Data Act, record the legal basis first: whether the request is enforceable under an in-force international agreement or must pass the Article 32(3) conflict checks. If there is doubt, document the national-body opinion request, the one-month reply window, and the final reason for accepting or rejecting access.

Then keep the record narrow. Note the minimum amount of data disclosed under Article 32(4), the date and method of customer notice under Article 32(5), and the safeguard controls used to prevent broader access than the Regulation allows.

Under the Data Act, Article 32 governs third-country governmental access to non-personal data held in the Union by providers of data processing services, while access requests touching personal data are governed by the GDPR and its international-transfer rules. A request spanning a mixed dataset can engage both regimes at once.

A provider should therefore separate the personal and non-personal elements of a foreign request, applying the Article 32 safeguards to the non-personal data and the GDPR transfer analysis to any personal data involved.

No. The Data Act sets the legal framework and essential requirements, but teams should not describe the relevant standards as final unless an official reference has actually been published or adopted for the relevant requirement.

For Article 33 data-space interoperability and Article 36 smart contracts, harmonised standards can create a presumption of conformity only to the extent their references are published in the Official Journal of the European Union and only for the requirements they cover. The same articles also allow the Commission to adopt common specifications by implementing act if the conditions in the Data Act are met.

For Article 35 data-processing services, the Act refers to open interoperability specifications, harmonised standards, common specifications, and a central Union standards repository for references used for interoperability between data-processing services.

The Data Act context is the starting point for this answer. Article 33 applies to participants in data spaces that offer data or data services to other participants. It requires those participants to support interoperability of data, data sharing mechanisms and services, and common European data spaces.

The practical requirements are concrete: describe dataset content, use restrictions, licences, collection methodology, data quality, and uncertainty where applicable in machine-readable form; describe data structures, formats, vocabularies, classifications, taxonomies, and code lists in a public and consistent way where available; describe technical access means such as APIs, terms of use, and quality of service; and provide means for interoperability of tools that automate data sharing agreements, such as smart contracts, where applicable.

A useful implementation record for Article 33 should therefore map each data-space offer to metadata, semantic assets, API or access documentation, licence or use restrictions, quality information, and any smart-contract automation used in the transaction.

The Data Act context is the starting point for this answer. Article 35 uses harmonised standards and common specifications as conformity tools, not as a blank replacement for the law. Open interoperability specifications and harmonised standards for data-processing services should support interoperability, portability of digital assets, functional equivalence where technically feasible, and compatibility with security and future innovation.

In practice, teams should follow the published repository reference for Article 35 once it exists, then align service interfaces, export formats, and documentation with the requirements covered by the relevant standard or common specification. The 2026 Union work programme for European standardisation identifies interoperability for data-processing services as an action area under the Data Act, which confirms that the work is still being built out through the standardisation pipeline.

Until a reference is published in the central Union standards repository, teams should treat implementation guidance as preparatory and should not say that a Data Act cloud standard is controlling law.

The Data Act context is the starting point for this answer. Article 36 applies to the vendor of an application using smart contracts, or where there is no vendor, to the person deploying smart contracts for others in the context of executing an agreement or part of it to make data available.

Those smart contracts must meet essential requirements for robustness and access control, safe termination and interruption, data archiving and continuity, access control at governance and smart-contract layers, and consistency with the data-sharing agreement being executed.

For day-to-day implementation, this means vendors and deployers should be able to show how the contract can be stopped or reset, how data and transaction history are archived for auditability, and how access rules match the underlying agreement.

Under the Data Act, keep a standards register rather than a generic legal memo. Each entry should show the Data Act article, affected product or service, data-space or cloud role, standard or specification status, source URL, owner, implementation ticket, test evidence, customer or participant documentation, and next review trigger.

For Article 33, keep evidence of metadata, semantic assets, API or technical access descriptions, terms of use, quality of service, licences, data quality, and uncertainty where applicable. For Article 35, keep switching, portability, interoperability, security, service-type, and repository-reference evidence. For Article 36, keep conformity assessment and EU declaration evidence.

The key audit question is whether the team can show the difference between a binding Data Act requirement, a published harmonised standard, an adopted common specification, an open interoperability specification, and a standardisation deliverable that is still in development.

The Data Act context is the starting point for this answer. The main risk is overstating legal status. A page, contract clause, procurement requirement, or architecture standard should not imply that M/614 deliverables, open specifications, or technical reports are final binding standards unless the cited source says so.

Use precise status language: the Data Act imposes essential requirements; harmonised standards can support presumption of conformity when officially referenced; common specifications can be adopted by implementing act; Article 35 references are to be published in a central Union standards repository; and M/614 identifies requested standardisation deliverables to monitor.

This distinction matters for product and legal teams because implementation choices may change when a standard is adopted, cited, amended, replaced, or covered by a common specification.

Under the Data Act, the Commission issued standardisation request M/614 to CEN and CENELEC to develop deliverables that support the interoperability essential requirements, mainly for Article 33 data spaces. These deliverables are in development rather than published harmonised standards, so a team should track their status rather than treat them as binding.

The practical step is to record, for each deliverable, whether it is requested, drafted, adopted, or referenced in the Official Journal, so the team knows which can support a presumption of conformity and which are still preparatory.

Under the Data Act, Article 30 requires providers of data processing services to support interoperability for switching, while Article 35 is the mechanism that supplies the open interoperability specifications, harmonised standards, and repository references those providers rely on. The duty exists now even though the standards pipeline is still being built.

Teams should treat Article 30 as the live obligation and Article 35 as the source of the technical references, aligning export formats and interfaces with published references as they appear.