Search every question across sub-FAQs

Under the Data Act, a harmonised standard whose reference is published in the Official Journal gives a presumption of conformity for the essential requirements it covers, which means a team that follows it is presumed to meet those requirements unless shown otherwise. It is a rebuttable presumption tied to the specific requirements the standard addresses.

Teams should not read the presumption more broadly than the standard's scope, and should keep evidence of how their implementation maps to the covered requirements.

Under the Data Act, an Article 36 vendor or deployer must carry out a conformity assessment and draw up an EU declaration of conformity covering robustness, access control, safe termination and interruption, data archiving, and consistency with the data-sharing agreement. The declaration is the artifact that demonstrates the essential requirements were tested.

The evidence file should connect each essential requirement to a test result and a version of the smart contract, so the conformity claim can be re-checked after a code change.

Under the Data Act, an Article 33 participant offering data or data services must describe dataset content, use restrictions, licences, collection methodology, data quality, and uncertainty in machine-readable form, and describe data structures, formats, vocabularies, taxonomies, and code lists in a public and consistent way where available. These descriptions are what make a data-space offer interoperable.

A participant should also document technical access means such as APIs, terms of use, and quality of service, so another participant can consume the data without bespoke negotiation.

Under the Data Act, the interoperability position should be revisited whenever a harmonised standard reference is published in the Official Journal, a common specification is adopted by implementing act, or a repository reference for data processing services is added. Each event can change what a team must support and what merely supports conformity.

Teams should also revisit the position when an M/614 deliverable advances or a relevant standard is amended or replaced, so the implementation tracks the current references rather than an outdated draft.

No. Under the Data Act, the Commission recommends the model contractual terms and cloud clauses as non-binding drafting tools, and parties can amend them to fit the deal. Their value is as a source-linked baseline for review, not as a compulsory template.

That said, voluntary wording cannot override mandatory Data Act protections. In particular, Chapter IV makes unfair terms in enterprise data-access and data-use contracts non-binding, and Article 12 prevents data-sharing agreements from excluding or varying Chapter III obligations to the detriment of a covered party or user.

The Commission material separates Data Act data sharing into three mandatory-sharing relationships under Chapters II and III: Data Holder to User, User to Data Recipient, and Data Holder to Data Recipient. It also includes a separate Data Sharer to Data Recipient set for voluntary data sharing.

For contract teams, the first step is to identify which relationship the deal actually creates. A connected-product manufacturer sharing data with a user, a user authorising a recipient, and a data holder sharing with that recipient need different obligations, data descriptions, permitted-use terms, compensation language, and safeguards.

Yes. Under the Data Act, the Commission says the terms were mainly drafted for business-to-business contracts. It also says they can be used in business-to-consumer relationships if relevant consumer-protection rules are added.

That distinction matters because the Data Act's unfair-contract-term control in Article 13 applies to terms unilaterally imposed by one enterprise on another enterprise. A B2C deployment needs a separate consumer-law check instead of assuming the B2B model wording is enough.

Under the Data Act, Article 41 specifically calls out model terms on data access and use, including reasonable compensation and the protection of trade secrets. Those topics should therefore be visible in the contract review file: what data is covered, who may use it, for what purpose, whether compensation is charged, and what confidentiality or technical measures protect trade secrets.

The model terms should not be copied as a single undifferentiated block. Each clause should be tied to the relevant data-sharing relationship, the data description, the recipient's permitted uses, and any safeguards needed to protect trade secrets without defeating the Data Act access right.

Start by classifying the deal. Decide whether it is a data-sharing contract or a cloud-switching contract, and then identify the Data Act roles on each side. That tells you which Commission model set to use and which mandatory provisions need a closer look.

Next, check whether the wording affects access, use, compensation, trade secrets, or switching. If it does, compare the drafted clause against the Data Act text before you accept the model wording or begin redlining.

For cloud contracts under the Data Act, start with the switching and exit wording, the termination mechanics, the notice period, and the data retrieval and erasure terms. Those points line up with Article 25's written-contract requirements and the broader switching obligations in Chapter VI.

Then check the information on exportable data, digital assets, exemptions for provider-internal data linked to trade secrets, continuity, security during transfer, and any switching charges. If those points are missing or vague, the contract needs a closer review before it is signed.

Under the Data Act, the Commission says the mandatory-sharing model sets are compliant with Chapter IV on unfair contractual terms, but that does not make every negotiated contract fair automatically. Article 13 still requires a term-by-term check where one enterprise supplied a term and the other enterprise could not influence it despite trying to negotiate.

High-risk clauses include terms that exclude liability for intentional acts or gross negligence, remove remedies, give one party exclusive power to interpret conformity, significantly detrimentally access the other party's data, restrict use of data the other party provided or generated, block termination within a reasonable period, or permit unilateral changes to price or substantive data-sharing conditions without a valid reason and termination right.

Keep evidence that shows the contract team used the model terms as a grounded drafting aid and checked the mandatory Data Act rules that matter to the deal. The file should let a reviewer see the party roles, relationship type, data categories, clause set selected, redlines, reason for deviations, unfair-term review, and cloud-switching review where relevant.

For cloud contracts, keep a separate switching evidence pack: exportable data and digital assets, known technical limits, switching method and formats, retrieval and erasure terms, continuity and security commitments, charges information, and any provider-internal data categories excluded because of trade-secret risk.

Start with the Data Act itself for the binding rule. Use Article 41 for the Commission's mandate, Articles 12 and 13 for data-sharing and unfair-term controls, and Articles 23 to 31 for cloud switching and porting.

Then use the Commission MCT and cloud SCC publication page for the voluntary model wording, the relationship sets, and the clause groups. The Commission's FAQ and contract-law pages are useful supporting context, but they should not be cited as if they replace the regulation.

Under the Data Act, the Commission published two distinct sets: model contractual terms for data access and use under Chapters II to IV, and standard contractual clauses for cloud computing and other data processing services under Chapter VI switching. They address different contracts and should not be mixed in a single review.

A reviewer should pick the cloud SCC set for a data processing service contract and the data-sharing model terms for a connected-product or B2B data-sharing contract, since the obligations, definitions, and risks differ between them.

Under the Data Act, voluntary model wording cannot be used to contract out of mandatory protections, and Article 12 prevents a data-sharing agreement from excluding or varying Chapter III obligations to the detriment of a covered party or user. The model terms are a drafting aid, not a way to weaken statutory rights.

A reviewer should treat any deviation that reduces a mandatory right as a red flag, even if it is dressed in Commission-style wording, and record why the change is still compliant.

Under the Data Act, the model contractual terms and cloud standard contractual clauses are Commission recommendations that can be updated, so teams should re-check their contract library when the Commission revises the model sets or issues new implementation guidance. A version note in the contract file makes that easier to track.

Teams should also re-check the wording when the underlying obligation changes, such as the removal of switching charges, so the contract reflects the current rule rather than an earlier draft.

A public emergency request is one branch of the Data Act's exceptional-need mechanism. Article 15 treats an exceptional need as limited in time and scope, and the public emergency branch applies where the requested data are necessary to respond to a public emergency and the requester cannot obtain them by alternative means in a timely and effective way under equivalent conditions.

This is narrower than a general public-interest request. The Commission's Data Act explainer gives examples of public emergencies such as major natural or human-induced disasters, pandemics, and cybersecurity incidents, and says the existence of a public emergency is determined under national or EU procedures or laws.

The Data Act context is the starting point for this answer. Article 17 requires the requester to put the request in writing, in clear, concise, plain language, and to specify the data required, including relevant metadata needed to interpret and use the data. The request must also explain the purpose, intended use, duration of use, requester authority, deadline for making data available, and the deadline for the data holder to decline or seek modification.

The request must justify why the chosen data holder is being asked, identify any other public bodies or third parties expected to receive the data, and commit to avoiding liability for the data holder where possible. If personal data are requested, the request must specify protection measures and whether the data holder can anonymise the data before disclosure.

The Data Act context is the starting point for this answer. A data holder that receives a Chapter V request must make the data available without undue delay, taking account of necessary technical, organisational, and legal measures. If the data holder declines or seeks modification of a public emergency request, Article 18 requires it to do so without undue delay and no later than five working days after receipt.

The five-working-day period is not a deadline for every operational task in the company. It is the outer limit for declining or seeking modification of a request for data necessary to respond to a public emergency. Internal intake should therefore identify the request date, the requester, the claimed emergency, the requested data, and any Article 17 defects immediately.

The Data Act context is the starting point for this answer. Article 18 gives three grounds: the data holder does not control the requested data, a similar request for the same purpose has already been submitted by another eligible body and erasure has not been notified, or the request does not meet the Article 17 request-content and form conditions.

Use those grounds precisely. A data holder should not refuse simply because the request is inconvenient, commercially sensitive, or urgent. But it should seek modification where the request is overbroad, lacks the required legal or factual justification, asks for data outside the holder's control, or duplicates an unresolved prior request.