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

Why This Matters for Security Teams

Deciding whether data can be used in a business process is not just a data stewardship question. It is a control decision that affects privacy, security, contractual limits, and downstream automation. When accountability is unclear, teams default to informal approvals, inherited access, or “temporary” exceptions that become permanent. That is where misuse, overexposure, and audit failure start. NIST’s control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that access and information handling need defined responsibility, not shared assumptions. For NHIs and agentic workflows, the risk is sharper because a business process may be executed by software accounts, service identities, or AI agents rather than a person. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 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. That makes accountability for data-use decisions a governance issue with direct operational impact. In practice, many security teams encounter bad data-use decisions only after a workflow has already processed restricted data, rather than through intentional review.

How It Works in Practice

The accountable party is usually the data owner, but the decision should not be made in isolation. The owner decides whether the data is appropriate for the business process, while privacy, security, legal, and process owners define the guardrails. For sensitive or regulated data, the decision often depends on context: purpose limitation, retention, geographic restrictions, and whether the process is human-driven or automated. The goal is not to create more approvals, but to make each approval traceable to a clear policy basis.

For NHI-enabled processes, the accountability model should also cover the identity that is doing the processing. That means the business owner must know whether a service account, API key, or agent is allowed to use the data at all, and under what conditions. Lifecycle control matters here. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows why data-use decisions should be tied to onboarding, rotation, review, and offboarding, not handled as one-time exceptions.

Practically, mature organisations use a policy workflow with three layers:

• Business ownership: confirms why the data is needed for the process and whether the use is legitimate.
• Governance and privacy: determine if the use is permitted under policy, contract, or regulation.
• Security and IAM: enforce who or what can access the data, with logging and periodic review.

That decision can be supported by standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls and mapped to data classification, approval thresholds, and exceptions management. Where process execution is automated, the approval should be machine-readable and enforceable, not buried in email or ticket comments. These controls tend to break down when data ownership is unclear across shared platforms, because no single team has enough context to approve or deny use confidently.

Common Variations and Edge Cases

Tighter approval controls often increase latency, so organisations have to balance stronger assurance against operational throughput. That tradeoff becomes visible when a process needs low-friction access to high-value data, especially in analytics, customer support, or AI-assisted workflows. Current guidance suggests that the best answer is not universal; it depends on sensitivity, regulation, and business criticality.

There are a few common edge cases. In shared datasets, accountability may sit with a designated data custodian or domain owner rather than a single application team. In regulated environments, privacy or legal may have veto authority even when the business owner approves. In autonomous systems, a data-use decision may need to be re-evaluated at runtime if the agent changes task scope or crosses into a new purpose. That is why decision records should capture purpose, approved scope, expiry, and review cadence.

For broader governance alignment, NIST’s AI Risk Management Framework is useful when the business process involves AI, because it reinforces accountability, transparency, and human oversight. The practical rule is simple: the more sensitive the data and the more automated the process, the more explicit the accountable owner and approval trail need to be. Where organisations skip that discipline, approvals tend to drift into exception handling, and exceptions are where control usually fails.

Related resources from NHI Mgmt Group

• Who is accountable for deciding whether a data incident is material and must be escalated?
• Who is accountable for deciding whether vaults should log users out instead of only locking them?
• Who is accountable when contract data used for governance is incomplete or wrong?
• Who should be accountable for deciding whether award-driven momentum should influence vendor selection?