Join our Newsletter — 33% off our NHI Course

Who is accountable when data crosses organisational boundaries without clear governance?

Accountability depends on the layer. Legal, privacy, and compliance teams own the data sharing agreement because it governs lawful use, security obligations, and liability between parties. The data producer or data product owner owns the data contract because they are responsible for the technical promise delivered to consumers. Both are needed for controlled sharing.

Why This Matters for Security Teams

When data crosses organisational boundaries without clear governance, accountability usually fails at the seam between legal intent and operational execution. Security teams often assume the handoff is “covered” once a sharing agreement is signed, but the technical controls, access review cadence, retention rules, and incident obligations still need an owner on both sides. That gap is where misuse, overexposure, and audit failure begin.

NHIMG research shows how quickly identity and governance gaps become risk multipliers: in The State of Non-Human Identity Security, Astrix Security & CSA found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. That is a boundary problem as much as an identity problem, because no one can govern what they cannot see. The broader governance lesson is consistent with NIST Cybersecurity Framework 2.0: accountability must be explicit, not inferred from process diagrams or shared assumptions.

In practice, many security teams discover the missing owner only after a partner integration has already moved sensitive data into an uncontrolled workflow.

How It Works in Practice

Accountability needs to be split by function, not blurred into a single shared responsibility statement. Legal, privacy, and compliance teams own the data sharing agreement because it defines lawful purpose, jurisdiction, permitted uses, breach notice terms, and liability. The data producer or data product owner owns the data contract because it describes the technical promise: schema, freshness, quality, authentication requirements, logging, and revocation conditions. Both layers matter because a lawful agreement without enforceable technical controls is weak, and a strong technical contract without legal approval can still create compliance exposure.

In mature programs, the governance model typically includes:

  • Named business, legal, and technical owners on both sides of the boundary
  • A data classification decision that determines whether sharing is allowed at all
  • Documented purpose limitation and retention rules
  • Access control, monitoring, and revocation terms mapped to the technical interface
  • Periodic review of the agreement and the contract against actual data flows

This approach aligns with the control intent in NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially where least privilege, accountability, and audit logging intersect with third-party exchange. It also matches NHIMG guidance in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, because cross-boundary sharing often depends on identities, tokens, and service accounts that outlive the original business approval if not actively governed.

Where this guidance breaks down is in fast-moving partner ecosystems with informal data sharing, because shadow integrations make it impossible to keep the legal agreement, data contract, and actual runtime access in sync.

Common Variations and Edge Cases

Tighter boundary governance often increases coordination overhead, requiring organisations to balance speed of sharing against legal, operational, and audit risk. That tradeoff becomes most visible when the recipient is a vendor, a subsidiary, or an analytics team that reuses the same data for multiple purposes. Best practice is evolving, but current guidance suggests that shared responsibility should never mean shared ambiguity.

Some edge cases need special handling. In a controller-to-controller relationship, both parties may retain independent accountability for their own lawful basis and downstream obligations. In a controller-to-processor setup, the processor must follow instructions, but the controller still owns the decision to share. In consortiums, joint governance committees can help, but they do not replace a named data steward or contract owner. For high-risk data flows, NHIMG recommends treating the data boundary like an access boundary: define who approves it, who operates it, and who can revoke it. The Top 10 NHI Issues page is useful here because identity sprawl and weak lifecycle control often expose the same accountability failures that appear in cross-organisation data sharing.

Where the model fails most often is in outsourced environments with unclear data residency and no effective contract owner, because responsibility gets distributed faster than control.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 GV.RM-06 Boundary governance needs clear risk ownership and decision authority.
NIST SP 800-53 Rev 5 AC-3 Data sharing depends on enforcing approved access and use limitations.
NIST AI RMF GOVERN Accountability requires governance roles, oversight, and traceability across organisations.
OWASP Non-Human Identity Top 10 NHI-07 Shared systems often rely on unmanaged identities and tokens across organisational boundaries.
CSA MAESTRO GOV-1 Agentic and data-sharing workflows need explicit governance and accountability assignment.

Assign named owners for cross-boundary data risk and review their decisions on a fixed cadence.