| Scope boundary | Covers fair access to and use of data, including connected products and related services, user and third-party access, B2B data-sharing terms, B2G exceptional-need requests, switching between data processing services, and interoperability for data spaces and smart contracts. | Covers reuse of certain protected data held by public-sector bodies, data intermediation services, data altruism organisations, single information points, European registers, and EDIB work on best practices and cross-sectoral interoperability. | Use Data Act controls when a covered product, related service, contract, public-sector request, cloud service, or interoperability duty drives the work. Use DGA controls when the issue is protected public-sector reuse, neutral intermediation, altruistic data sharing, or DGA governance infrastructure. |
|---|
|
| Covered actors | Key roles include users, data holders, data recipients, third parties, manufacturers, related-service providers, public-sector bodies, Union bodies, providers of data processing services, competent authorities, data coordinators, and EDIB for consistent application. | Key roles include public-sector bodies, reusers, data intermediation service providers, recognised data altruism organisations, data holders, data users, competent authorities for intermediation and altruism, the Commission, and EDIB. | Create two role maps when a project touches both regimes. The same organisation can be a Data Act data holder, a DGA data holder, a reuser, a cloud customer, or an intermediary participant depending on the exact service and dataset. |
|---|
|
| Trigger | Creates duties around making product and related-service data accessible, sharing with users or third parties under conditions, protecting trade secrets proportionately, preventing unfair B2B terms, responding to valid B2G requests, enabling data processing service switching, and meeting interoperability requirements. | Creates governance conditions for protected public-sector data reuse, neutrality and structural separation for data intermediaries, notification to competent authorities, recognised labels and registers, not-for-profit and safeguard expectations for data altruism, and common consent-form support. | Do not merge the obligation lists. Data Act work usually changes product, API, contract, support, procurement, or cloud-exit operations. DGA work usually changes reuse conditions, intermediary structure, transparency, registration, consent, or public-sector metadata operations. |
|---|
|
| Core obligations | Does not create the DGA intermediary or altruism model. It can still affect reuse projects where connected-product data, B2B access terms, public-sector exceptional-need requests, data-space interoperability, or cloud-switching rights are part of the same project. | Directly regulates reuse of protected public-sector data, neutral data intermediation services, and data altruism where individuals or companies voluntarily make data available without reward for general-interest objectives. | If the project is a marketplace, data trust, data donation, research reuse, public-sector data room, or single-information-point workflow, start with the DGA. Add Data Act controls only for the connected-product, contract, B2G, switching, or interoperability layer that actually exists. |
|---|
|
| Evidence record | Keep the Data Act source article or chapter, product or service facts, data category, access request or delivery record, recipient terms, trade-secret safeguards, contract review, B2G request file, switching plan, interoperability note, complaint record, or authority correspondence. | Keep the DGA basis, protected-data category, reuse decision, secure-processing or confidentiality safeguards, intermediary notification and neutrality evidence, altruism transparency and consent materials, register entry, single-information-point metadata, and competent-authority correspondence. | A combined EU data-sharing file should contain two labeled evidence indexes. One proves Data Act access, contract, B2G, switching, or interoperability handling; the other proves DGA reuse, intermediation, altruism, register, or EDIB-related governance handling. |
|---|
|
| Timing and deadlines | Product teams may need access-by-design, user instructions, access methods, recipient processes, and trade-secret safeguards. Cloud and procurement teams may need switching clauses, exportable-data registers, open interfaces, functional-equivalence planning, and charge withdrawal tracking. Contract teams may need unfair-term review and model-term alignment. | DGA work is less about redesigning connected products or cloud exits and more about reuse permissions, secure processing, confidentiality, intermediary legal separation, transparent terms, recognised logos or registers, altruism consent, and national single-information-point implementation. | Route product and cloud engineering work to the Data Act owner. Route protected-data reuse, intermediary structure, altruism, and ERPD or single-information-point work to the DGA owner. In data spaces, bring both owners into the same review only when both technical and governance layers are present. |
|---|
|
| Enforcement | Member States designate competent authorities and, where relevant, data coordinators. The Data Act includes complaint rights, judicial remedies, information requests, cooperation between authorities, and Member State penalty rules that must be effective, proportionate, and dissuasive. | DGA supervision is tied to the relevant DGA activity: competent-authority notification and monitoring for data intermediation services, recognised status and registers for data altruism organisations, reuse conditions for protected public-sector data, and EDIB best-practice coordination. | Escalate through the enforcement route for the activity at issue. Do not quote a single fine threshold for this comparison unless a specific Member State penalty source is added; the Data Act grounding here supports national penalty-setting, not a universal penalty table. |
|---|
|
| Overlap and reuse | Choose the Data Act analysis when the next action is to give or refuse access, provide data to a third party, protect trade secrets, review a B2B term, answer an exceptional-need public-sector request, switch a data processing service, or meet interoperability duties. | Choose the DGA analysis when the next action is to permit protected public-sector data reuse, run a neutral data intermediation service, register or operate a data altruism organisation, prepare single-information-point metadata, or rely on DGA governance structures. | If the answer affects product design, access delivery, cloud exit, or contract terms, Data Act owners should lead. If the answer affects reuse safeguards, intermediation neutrality, altruism safeguards, registers, or information points, DGA owners should lead. If both are true, keep two cited conclusions. |
|---|
|
| Practical decision rule | The Data Act includes interoperability requirements for common European data spaces and support from EDIB on standards, common specifications, smart contracts, and data processing service interoperability. | The DGA created EDIB to share best practices on data intermediation, data altruism, protected public-sector data use, and prioritisation of cross-sectoral interoperability standards. | For a common European data space, distinguish technical interoperability and access duties from the governance trust model. EDIB appears in both laws, but its role does not collapse Data Act access rights and DGA trust structures into one obligation. |
|---|
|