Who is accountable when data sharing under the EU Data Act fails to meet fairness, transparency, or portability requirements?

Why This Matters for Security Teams

The accountability question under the EU Data Act is not just a legal one. It affects how organisations prove that data sharing is fair, transparent, and operationally reliable when customers, partners, or regulators ask for evidence. Security teams often discover that the real weakness is not the sharing mechanism itself, but the absence of ownership, logging, retention, and review around it. That becomes especially important when personal data, sensitive business data, or connected-product telemetry is involved.

For practitioners, the key issue is whether the organisation can demonstrate control over the full data sharing path, including request handling, approval logic, disclosure terms, and exception management. NIST’s control catalogue in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it shows how governance, auditability, and access control translate into evidence. The EU Data Act expects more than a policy statement. It expects operational proof that decisions are repeatable, traceable, and reviewable.

In practice, many security teams encounter data-sharing failures only after a partner complaint or regulatory inquiry has already exposed weak ownership and missing evidence trails, rather than through intentional compliance testing.

How It Works in Practice

In operational terms, accountability usually sits with the organisation that controls the data lifecycle and the conditions of sharing. That may be the product owner, the data controller, a platform operator, or another designated business function, but the obligation is shared across legal, privacy, security, and engineering teams. The important point is that no single team can treat compliance as someone else’s job.

Best practice is to define who approves sharing, who checks fairness and contractual terms, who validates transparency notices, and who maintains evidence of portability support. Organisations should also decide how exceptions are escalated, because portability failures often come from fragmented implementation rather than an intentional refusal to comply. Relevant control themes from CISA Zero Trust Maturity Model can support this by reinforcing identity-aware access, policy enforcement, and traceable decision paths.

• Assign a named owner for each data-sharing workflow, not just for the overall policy.
• Maintain logs showing what data was shared, with whom, under what basis, and when.
• Document how portability requests are validated, fulfilled, and closed.
• Review sharing terms for transparency and fairness before release, not after escalation.
• Retain evidence that legal and security checks were completed consistently.

Where identity controls matter, the process should also verify who is requesting data, whether the requester is authorised, and whether delegated access is properly governed. That intersection becomes more important when shared services, APIs, or automated workflows are used to satisfy access and portability obligations. These controls tend to break down when data is spread across multiple business units with inconsistent ownership because no single team can reconstruct the full sharing history quickly enough.

Common Variations and Edge Cases

Tighter data-sharing governance often increases operational overhead, requiring organisations to balance faster business enablement against stronger evidence, review, and exception handling. That tradeoff is especially visible when product teams want self-service sharing while legal teams require formal approval and traceability.

There is no universal standard for every implementation detail under the EU Data Act yet, so current guidance suggests using conservative governance where the data environment is complex or cross-border. For example, a consumer portal, industrial platform, and B2B API may all share data differently, even though the accountability principle remains the same. In some cases, the accountable party may be a controller-like entity, while in others the issue is divided across service operators and downstream recipients. The practical answer is to make the accountable party explicit in policy, contracts, and technical workflows.

For organisations handling regulated or identity-linked data, transparency and portability controls should be aligned with privacy and access governance rather than treated as a standalone legal exercise. The GDPR enforcement guidance from CNIL is not a substitute for the Data Act, but it reinforces the same operational lesson: if evidence is missing, accountability is weak. Where automated systems trigger sharing, teams should also consider whether an agent or workflow has been given authority to act without enough human review. That is where governance gaps often surface first.

Related resources from NHI Mgmt Group

• Who is accountable when a device or software product fails to meet EU Cyber Resilience Act requirements?
• Who is accountable when an AI system misses EU AI Act requirements?
• Who is accountable when a customer-facing AI system fails Article 50 transparency requirements?
• How should organisations implement data discovery and classification to meet New York SHIELD Act requirements across SaaS, cloud, and endpoint environments?