Who should own accountability in cross-sector smart data programmes?

Accountability should sit with the organisation that can actually enforce the control, not only the one that defines the policy. In cross-sector programmes, that usually means the platform operator, scheme owner, or data recipient must be able to prove how consent, access, and revocation are enforced across the lifecycle.

Why This Matters for Security Teams

Cross-sector smart data programmes fail when accountability is assigned to the policy designer but not to the organisation that can enforce consent, access, and revocation in real time. That gap is especially risky when NHIs are the actors actually moving data between systems, because the control surface is operational, not theoretical. NHI Management Group’s Ultimate Guide to NHIs — Key Research and Survey Results notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which shows how often lifecycle control is assumed rather than proven.

For security teams, the practical question is not who wrote the memorandum of understanding, but who can stop a bad token, disable an integration, or prove a revocation actually propagated. That is why accountability must map to operational authority, not just governance intent. The NIST Cybersecurity Framework 2.0 is useful here because it ties governance to outcomes that can be measured, monitored, and defended across the lifecycle. In practice, many security teams encounter accountability failures only after a data-sharing exception, stale secret, or third-party access path has already been abused rather than through intentional assurance testing.

How It Works in Practice

In a mature smart data programme, accountability should be assigned to the party that operates the control plane and can demonstrate continuous enforcement. That usually means the platform operator for shared infrastructure, the scheme owner for policy governance, or the data recipient for downstream handling. The key is to separate policy authorship from enforcement ownership. A ministry, regulator, or consortium may define rules, but it is the operator that must log access decisions, enforce revocation, and retain evidence.

This is where NHI governance becomes central. If APIs, service accounts, certificates, and automation tokens are the mechanisms of data movement, then accountability must include identity lifecycle controls, not just legal terms. Current guidance suggests using verifiable workload identity, short-lived secrets, and auditable access policies so that each transaction can be linked to an accountable operator. NHI Mgmt Group’s research shows both the scale of the problem and the reason governance without execution fails: NHIs outnumber human identities by 25x to 50x, and only 5.7% of organisations have full visibility into their service accounts.

• Define one accountable control owner for each enforcement domain: consent, access, revocation, logging, and exception handling.
• Require evidence that the accountable party can rotate or revoke credentials without waiting on another sector partner.
• Use contract language to bind operational evidence to policy claims, including retention of access logs and revocation records.
• Make escalation paths explicit when data flows cross multiple legal or organisational boundaries.

The NIST Cybersecurity Framework 2.0 supports this model by linking governance, identification, protection, detection, response, and recovery to accountable outcomes. These controls tend to break down when the programme spans multiple operators with no single party able to enforce credential lifecycle actions end to end.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance faster data sharing against stronger proof of control. That tradeoff is real in federated health, transport, and financial data schemes, where no single participant owns the full stack. Current guidance suggests treating accountability as layered rather than shared in the abstract: one party may own policy, another may own platform operations, and a third may own local data handling.

The edge case is when a public-sector sponsor sets the rules but a private operator runs the service. In that model, accountability should follow the operator for technical enforcement and the sponsor for policy legitimacy, with clear handoffs for incident response and audit. Best practice is evolving on how to assign accountability where AI agents or automated workflows initiate access on behalf of multiple parties, but the principle remains the same: whoever can enforce the control must be able to prove it. When that proof cannot be produced, the programme should be treated as operationally unaccountable until the gap is closed.

Related resources from NHI Mgmt Group

• Who should own AI identity and data governance in Microsoft environments?
• Why is it important to integrate identity and data governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Where does cross-environment agent discovery fit in an IAM programme?