Who is accountable for securing sensitive data when access sprawl spans multiple platforms?

Accountability sits with the organisation that owns the data and the access model around it. Security, infrastructure, and application teams all contribute, but they need shared controls for discovery, permission review, and remediation. Without clear ownership, sensitive data exposure persists across platforms and least privilege becomes inconsistent.

Why This Matters for Security Teams

When sensitive data is spread across SaaS platforms, cloud services, CI/CD systems, and internal tooling, accountability often becomes diffuse even though the risk remains concrete. The organisation that owns the data and decides how access is granted is still responsible for protecting it, but in practice security teams inherit the fallout when permissions drift, service accounts linger, or secrets are copied into new tools. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which makes access sprawl more than an inventory problem; it is a control failure. See Ultimate Guide to NHIs — Key Challenges and Risks and OWASP Non-Human Identity Top 10 for how over-permissioned identities and weak governance compound exposure across systems.

The practical issue is not whether one team owns every platform, but whether one accountable function can define the data classification, approve access paths, and force remediation across them. Without that, least privilege becomes a policy statement instead of an operating model. In practice, many security teams encounter data exposure only after a platform migration, a shadow integration, or a forgotten API key has already widened access.

How It Works in Practice

Accountability needs to follow the data lifecycle, not the tool boundary. The data-owning business function should define sensitivity, retention, and approved use cases, while security sets the baseline controls for discovery, entitlement review, secret handling, and logging. Platform owners then implement those controls in their respective systems. That division of labour is clearer when mapped to formal controls such as NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially access control, auditability, and configuration management expectations.

For NHI-heavy environments, the accountable team should treat every machine identity, token, and key as part of the access model. The NHIMG Ultimate Guide to NHIs shows why this matters: only 5.7% of organisations have full visibility into their service accounts, while 96% store secrets outside dedicated secrets managers in risky locations. That means ownership must include discovery and remediation, not just approval. A workable pattern is:

• Maintain a system-wide inventory of sensitive data locations and the identities that can reach them.
• Assign one accountable owner for each data domain, with security as the control-set owner and platform teams as implementers.
• Review permissions on a recurring basis, including human, service, and application identities.
• Use short-lived credentials, rotation, and revocation to reduce the damage from stale access.
• Measure remediation time for exposed secrets and excessive entitlements, not just policy completion.

This approach aligns with the reality that access sprawl crosses clouds, ticketing systems, repositories, and collaboration tools. These controls tend to break down when ownership is split across mergers, outsourced operations, or legacy platforms because no single team can see and revoke access end to end.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, so organisations have to balance speed against assurance. That tradeoff becomes sharper when multiple business units use the same dataset for different purposes, or when third parties and automation accounts require delegated access. There is no universal standard for this yet, but current guidance suggests the accountable owner should approve the access policy while technical custodians enforce it in each platform.

Two edge cases matter most. First, in federated environments, ownership may be split by jurisdiction or subsidiary, but the parent organisation still needs a single control framework for discovery and remediation. Second, in agentic and automated workflows, access may be granted transiently to software identities that are not visible in ordinary IAM reviews. For those cases, the governance model must include workload identity, JIT provisioning, and a revocation path that works across platforms. The issue is not only who can grant access, but who can prove it was removed.

If the organisation cannot trace which identity accessed which dataset, then accountability is effectively missing even if policy documents exist. That is why NHI Mgmt Group’s research on breaches and misconfigured vaults is relevant to this question: access sprawl usually becomes visible only after exposure has already happened, not during routine review.

Related resources from NHI Mgmt Group

• Who is accountable for securing AI workflows when access spans multiple teams and platforms?
• Why do data risk assessments matter when sensitive data spans multiple platforms and AI tools?
• Who should be accountable for risky non-human identity access when automation spans multiple platforms?
• Who is accountable for securing non-human identities when access spans infrastructure, applications, and SaaS platforms?