Who is accountable for making Data Act response workflows defensible across legal, privacy, and operational teams?

Why This Matters for Security Teams

Data Act response workflows are defensible only when accountability is shared across the teams that control legal interpretation, privacy safeguards, technical evidence, and operational execution. That matters because a request is rarely a single-track legal matter. It is an evidence handling process, an access control decision, and often a customer-facing commitment that must stand up to audit or dispute.

Security teams often underestimate how quickly these workflows fail when ownership is vague. If legal approves the response language but security cannot prove the data lineage, or if operations can execute the export but privacy has not validated the minimisation steps, the organisation ends up with an answer that is internally convenient and externally brittle. Current guidance suggests that controls should be mapped to documented decision rights and retained evidence, not informal handoffs. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls provides the kind of control language needed to make this defensible.

This is also consistent with NHIMG research showing that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in the Ultimate Guide to NHIs - Key Research and Survey Results, which is relevant because many Data Act workflows depend on machine accounts, data pipelines, and automated retrieval paths. In practice, many security teams encounter accountability gaps only after a request has already been escalated, rather than through intentional workflow design.

How It Works in Practice

The defensible model is a cross-functional operating pattern with explicit decision rights, not a committee that meets after the fact. Legal should own interpretation of request scope and response obligations. Privacy should own minimisation, disclosure boundaries, and any personal data redaction. Security should own access restrictions, auditability, and proof that the workflow used approved identities and controls. Data governance should ensure the dataset definition, provenance, and retention rules are accurate. Product or cloud operations should execute the actual retrieval, packaging, and delivery steps.

In practice, that means the organisation needs a documented intake path, a triage checklist, a response playbook, and an evidence trail that captures who approved what and when. The workflow should specify:

• who validates that the request is in scope,
• who confirms the relevant dataset and system of record,
• who approves disclosure or redaction,
• who runs the export or shares the data, and
• who signs off on final delivery and retention of records.

For systems that rely on automation, the workflow should also define the identity used to query or assemble the data. If service accounts, API keys, or agentic tools are involved, the organisation should treat them as governed NHIs, not incidental technical detail. NHIMG’s GitHub Action tj-actions Supply Chain Attack is a useful reminder that machine-driven workflows can leak secrets or alter outputs if their controls are weak. The GDPR’s EU General Data Protection Regulation (GDPR) also reinforces the need for lawful processing, purpose limitation, and accountability documentation, which translate directly into response governance.

These controls tend to break down when teams rely on inbox-based approvals and ad hoc exports because the organisation cannot later prove which data was included, which identity accessed it, or which review step was skipped.

Common Variations and Edge Cases

Tighter approval chains often increase response time, so organisations have to balance defensibility against operational speed. That tradeoff becomes sharper when requests are time-sensitive, span multiple subsidiaries, or depend on datasets held across cloud platforms and internal tools.

There is no universal standard for this yet, so current guidance suggests tailoring the model to the request class. High-risk requests should require deeper legal and privacy review, while routine requests can follow pre-approved templates and automated evidence capture. The important point is that the same workflow should not change depending on who happens to be on call.

Edge cases usually appear where ownership overlaps: outsourced operations, shared service centres, multi-region data stores, or agent-assisted retrieval workflows. In those environments, the question is not only who approves the response, but who can prove that the approving team had the right context. Organisations that already manage NHIs well usually have a better foundation here, because the same discipline used for access reviews, rotation, and offboarding can be applied to response tooling and service accounts. The Ultimate Guide to NHIs - Key Research and Survey Results is especially relevant when evidence collection depends on non-human access paths.

Related resources from NHI Mgmt Group

• Who is accountable when sensitive data is detected but privacy response is delayed?
• How should teams govern access to regulated data across privacy and IAM workflows?
• How should security teams automate response to risky sensitive data movement across SaaS, endpoint, and AI workflows?
• How should security teams integrate identity data into SOC workflows?