Why do organisations struggle to reduce cloud data risk even when they already have data security tools in place?

Why This Matters for Security Teams

Data risk in cloud environments is not just a discovery problem. It is a control drift problem. Security teams may have scanners, DLP, and posture tools in place, but those capabilities often protect what is already known while missing newly created stores, transient shares, and cross-account exposures. The result is a mismatch between coverage and reality, especially when permissions change faster than review cycles. NIST guidance in the NIST Cybersecurity Framework 2.0 and the CSA Cloud Controls Matrix both point toward continuous governance rather than one-time audits.

NHIMG research shows how wide that gap can be: in the Ultimate Guide to NHIs , only 19.6% of security professionals expressed strong confidence in securely managing non-human workload identities, a useful proxy for how fragile cloud access governance often is when systems scale across services and teams. In practice, many security teams encounter excessive data exposure only after a storage bucket, collaboration workspace, or SaaS tenant has already been indexed or shared externally, rather than through intentional prevention.

How It Works in Practice

Reducing cloud data risk requires an operating model that ties discovery, classification, access control, and review into one loop. The core issue is that cloud data is highly dynamic: copies are created automatically, permissions are delegated through roles and service accounts, and sensitive content can move into shadow repositories outside the original security boundary. Point-in-time tooling can identify a repository, but it cannot by itself keep pace with configuration changes or inherited access paths.

Practitioners usually need four linked capabilities:

• continuous discovery across object stores, data warehouses, SaaS platforms, and collaboration tools;
• classification that distinguishes regulated data from operational noise;
• policy enforcement that follows the data, not just the platform;
• access review that validates who can reach data through direct, delegated, or indirect permissions.

This is where controls such as NIST SP 800-53 Rev. 5 Security and Privacy Controls help translate governance into measurable requirements. It also explains why NHIMG continues to emphasise lifecycle thinking in materials such as the Top 10 NHI Issues: the same environment that creates workload identities, tokens, and automation also creates unexpected data pathways. A mature programme treats exposure as a continuously changing state, not a fixed asset inventory.

Effective teams also correlate posture findings with identity and permission telemetry, because many cloud data incidents begin with over-privileged machine access rather than a classic human mistake. These controls tend to break down when organisations operate multiple cloud tenants with separate ownership models, because policy ownership and remediation authority are split across teams.

Common Variations and Edge Cases

Tighter cloud data control often increases operational overhead, requiring organisations to balance faster remediation against developer autonomy and platform complexity. That tradeoff becomes more visible in environments with ephemeral workloads, distributed analytics pipelines, and heavy SaaS integration, where data can be created and shared faster than central teams can review it.

There is no universal standard for exactly how much automation is enough. Current guidance suggests that organisations should prioritise the highest-risk data paths first, especially places where secrets, tokens, or service credentials can indirectly expose sensitive datasets. The most common blind spots are third-party connectors, copied datasets in analytics sandboxes, and access inherited from broad admin roles. NHIMG’s 230 Million AWS environment compromise and Codefinger AWS S3 ransomware attack illustrate how quickly a cloud exposure becomes a business event when data paths are left open.

Best practice is evolving toward policy-as-code, continuous posture scoring, and tighter linkage between identity, configuration, and data lineage. That said, these approaches still need human ownership for exception handling and remediation triage. When cloud estates span multiple providers and business units, data risk programs often stall because no single control plane sees all copies, all permissions, and all exceptions at once.

Related resources from NHI Mgmt Group

• Why does data sprawl increase risk even when security tools are already in place?
• Why do organisations struggle to operationalise IAM and IGA even when they already have identity tools in place?
• Why do small security teams struggle with cloud detections even when they have modern tools?
• How should organisations reduce the security risk of ROT data in cloud and SaaS environments?