Data Governance Act

What the Data Governance Act changes in practice

The Data Governance Act creates a legal operating model for data sharing in the EU, so the security question is not only whether data exists, but who may intermediate it, reuse it, or receive it under controlled conditions. That makes governance, transparency, lawful access, and purpose separation part of the control surface, not just legal background.

For organisations, the key implication is that data-sharing arrangements must be classified correctly before they are operationalised. A service can look like a neutral exchange layer, yet still fall within the scope of regulated intermediary activity if it sits between data holders and data users in a way that affects trust, neutrality, or reuse conditions.

That same logic is why many teams pair policy review with data discovery and access review. NHIMG’s Data Security Guide is useful here because the operational problem is often not just compliance wording, but controlling exposure, over-permissioned data, and shared datasets that have drifted beyond their intended governance model.

Data intermediaries and trusted sharing models

One of the Act’s central ideas is that data intermediaries are supposed to enable sharing without turning into opaque brokers of value extraction. That means the governance model has to distinguish facilitation from commercial re-use, and it has to make the relationship between the data holder, the intermediary, and the recipient intelligible.

This matters because trust depends on separable roles. If a platform combines mediation, analytics, resale, or reuse in the same operating layer, the organisation can lose the neutrality and transparency that the Act is designed to preserve. In practice, that means internal ownership, contractual boundaries, and data-flow documentation need to match the legal role being performed.

The control problem is therefore structural, not cosmetic. If the same party both governs access and benefits from downstream reuse, the arrangement may still be technically functional but no longer aligned with the governance expectations that the regime is trying to enforce.

Re-use of protected public-sector data

The Act also addresses re-use of protected public-sector data, which is significant because public-sector datasets often carry confidentiality, privacy, trade secret, or statutory access constraints that survive beyond the initial custodian. Re-use is therefore not a default permission; it is a governed exception that needs to be justified, scoped, and monitored.

That creates a practical challenge for data owners and data consumers alike. The same dataset can be lawful to store, restricted to inspect, or limited to use only under specific conditions, depending on the legal basis and the protective measures attached to it. The governance burden is to preserve those distinctions after the data leaves its original environment.

Where sharing crosses organisational boundaries, the strongest failure mode is misuse through assumption. A recipient may treat protected public-sector data as broadly reusable once received, even when the original access condition was narrower. The governance design has to prevent that assumption from becoming an operational reality.

Governance controls for lawful access and transparency

In implementation terms, the Data Governance Act pushes organisations toward explicit classification, documented access rules, and traceable sharing workflows. The practical objective is to keep lawful access separate from convenience access, and to ensure that every sharing path has a clear owner, purpose, and handling model.

That is why privacy and trust references are relevant even when the term is not only about privacy law. The NIST Privacy Framework helps frame the governance side of the problem, especially data classification, transparency, and privacy risk management, while Global Privacy Regulatory Map is useful when the sharing model crosses jurisdictions and the organisation needs to compare transfer and localisation constraints.

For practitioners, the important point is that governance controls must survive operational pressure. If a data-sharing programme cannot explain what data is shared, on what basis, with whom, and under what restrictions, then it has not yet turned legal permission into a durable control model.

Risk and Threat Considerations

The main risks are unlawful reuse, opaque third-party handling, and scope drift, where data is shared for one purpose but later consumed for another. Those failures can create regulatory exposure, privacy harm, and loss of trust even when the original access was technically authorised.

Failure mechanism: Poor role separation, weak data classification, or unclear reuse terms allow a recipient or intermediary to treat restricted data as broadly available, which breaks the governance model the Act depends on.

Impact: Organisations can lose lawful control over sensitive datasets, face compliance disputes, and expose protected public-sector information or regulated data to secondary use that was never intended.

Practitioner Guidance

Governance implication: Treat the Data Governance Act as a data-flow classification problem as much as a legal one. Assign ownership for deciding whether a sharing arrangement is intermediary activity, data altruism, or protected-data re-use, and make that decision visible in the operating process rather than buried in contracts.

What to watch for: Watch for shared datasets with no clear reuse boundary, repeated exceptions to the same access rule, or arrangements where the commercial and governed roles are performed by the same operating team. Those are usually the signs that policy and practice have drifted apart.

Practitioner takeaway: The safest programmes make lawful sharing measurable, documented, and reviewable, so the organisation can prove not just that data moved, but that it moved under the right governance model.

Related resources from NHI Mgmt Group

• How should security teams implement governance for AI agents that can read and act on payment data through MCP?
• Why do EU AI Act amendments make data governance central to AI compliance?
• Why do identity governance programmes need stronger controls when they intersect with EU data sovereignty and GDPR or AI Act compliance?
• How should teams implement governance for MCP servers that let agents act on sensitive data?