Who should be accountable for deciding whether data can be used in a business process?

Why the Accountability Decision Has to Be Assigned, Not Shared by Default

Accountability for data use decisions matters because a business process only stays trustworthy when someone can answer three questions: who approved the use, on what basis, and under which constraints. If that ownership is vague, teams tend to improvise exceptions, over-collect sensitive data, or allow reuse beyond the original purpose. For a practical control reference, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it ties authorisation, governance, and privacy expectations to explicit control ownership rather than informal consensus.

In practice, many security teams encounter inconsistent data-use approvals only after a sensitive workflow has already expanded beyond its original purpose.

How the Decision Should Work Inside a Business Process

The right accountability model is usually a decision chain, not a committee free-for-all. The data owner should be responsible for deciding whether the data may be used in the process, because that role is closest to the meaning, sensitivity, and permissible purpose of the data. Governance, privacy, and security teams then shape the conditions for use: retention limits, access scope, auditability, jurisdictional constraints, and whether the intended use fits policy.

That structure matters because different stakeholders answer different questions. Business stakeholders can explain why the process needs the data. Privacy teams can judge whether the use is compatible with notice, consent, or lawful basis requirements where relevant. Security teams can assess exposure, access paths, and whether the process creates unnecessary replication or broader privilege. The data owner then makes the final business-use decision within those guardrails, which keeps accountability clear while still allowing specialist review.

A good decision model also records the rationale. That means the approval should capture the business purpose, the data class, any restrictions, the approving owner, and any exceptions accepted. Without that record, future teams cannot tell whether a use was intentionally approved or simply inherited from a past workaround. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because it reinforces the need to formalise control responsibility and document authorisation rather than relying on informal practice.

• Data owner: decides whether the use is acceptable for the process.
• Governance or policy team: defines the rules for sensitive or regulated data.
• Privacy team: checks lawful basis, notice, and purpose limitation where applicable.
• Security team: verifies access, logging, and containment requirements.

Where this breaks down is when ownership is assigned by title but not by actual authority, because then approvals become symbolic and the process still runs on informal exceptions.

Where This Model Gets Blurry in Regulated or Cross-Functional Cases

Tighter data-use control often increases coordination overhead, requiring organisations to balance decision speed against legal, security, and business risk.

There is a real trade-off here: the more sensitive the data or the more regulated the process, the less sensible it is to let operational teams self-approve reuse. In lower-risk internal workflows, a standing policy may allow routine use without case-by-case escalation. In highly regulated or sensitive contexts, that same shortcut can create compliance and accountability gaps. Guidance versus consensus also matters here: many organisations talk about “shared accountability,” but in practice the final decision still needs a single accountable owner so the result is auditable.

Edge cases appear when the data is jointly owned, sourced from third parties, or used across regions. In those situations, the accountable owner is usually the one with authority over the dataset’s permitted use, while legal or policy teams may impose non-negotiable constraints. The business process owner may still be responsible for the operational need, but that is not the same as accountability for whether the data may be used. The distinction becomes especially important when a process is trying to expand from its original use case into analytics, automation, or cross-team reuse.

The most reliable pattern is to treat “can we use this data?” as a controlled business decision with documented ownership, not as an informal technical approval. That reduces ad hoc exceptions, but it only works if the owner is empowered to say no as well as yes.

Practitioner Guidance

What to prioritise: define one accountable data owner per dataset or governed data domain, then make every business-use approval trace back to that role. If no one can clearly decline the request, the ownership model is not real enough for governance.

What to verify: confirm that the approver has authority over purpose, sensitivity, and permitted reuse, not just operational familiarity with the process. If security or privacy are being asked to “sign off” in place of ownership, the organisation is probably substituting review for accountability.

Practitioner takeaway: the strongest model is a single accountable owner with specialist review around them, because shared review without clear ownership usually produces approvals that are easy to grant and hard to defend later.

Related resources from NHI Mgmt Group

• Who should be accountable for deciding whether data can be used in a governed environment?
• Who is accountable for deciding whether a data incident is material and must be escalated?
• Why is it important to integrate identity and data governance?
• How should security teams make NHI best practices usable across the business?