How should teams evaluate a data security platform that runs inside their cloud account?

They should ask whether the platform preserves identity context, reduces data movement, and avoids creating a second infrastructure layer that must be governed separately. In-place operation matters because it keeps classification tied to the same cloud identities and access paths that create the risk in the first place.

Why This Matters for Security Teams

A data security platform that runs inside the customer’s cloud account can reduce exposure, but it also changes the governance question. Security teams should not only ask what the platform inspects, but whether it preserves identity context, keeps classification aligned to the same cloud paths that create risk, and avoids copying sensitive data into a second environment that becomes another target. That distinction matters because cloud-native data risk is often driven by identity misuse, not just data location.

Practitioners evaluating these platforms should compare their design against controls in the NIST SP 800-53 Rev 5 Security and Privacy Controls and the CSA Cloud Controls Matrix, because deployment model affects auditability, access boundaries, and operational responsibility. NHIMG’s research on the State of Non-Human Identity Security shows why this matters: only 1.5 out of 10 organisations are highly confident in securing NHIs, which means any new control plane must be judged against identity-driven failure modes, not just feature lists.

In practice, many security teams discover the platform has become a second system of record only after access reviews, incident response, or data residency questions expose the gap.

How It Works in Practice

The strongest evaluation lens is whether the platform operates as an in-account control point rather than an external data pipeline. In-place tools can inspect, classify, and policy-enforce where data already lives, which helps preserve source identity, object lineage, and cloud-native audit logs. That makes it easier to map decisions back to the original IAM principal, workload identity, or service role that touched the data. For teams dealing with NHIs, this is especially important because over-privileged service accounts and API tokens often drive the actual exposure.

When reviewing architecture, ask how the platform handles read access, metadata access, key usage, and temporary credentials. A platform that must replicate data elsewhere may create new secrets, new egress paths, and a new privileged admin model. By contrast, an in-account design should ideally integrate with cloud-native controls, use existing logging, and minimize lateral data movement. This is consistent with the operational patterns described in The 2024 Non-Human Identity Security Report, which highlights that 59.8% of organisations see value in simplifying non-human access management with dynamic ephemeral credentials.

• Confirm where classification happens and whether raw data leaves the account.
• Verify whether the platform uses the customer’s identity provider, cloud roles, and audit trail.
• Check how it scopes access to buckets, warehouses, snapshots, and logs.
• Review whether secrets are short-lived and automatically revoked after each task.

Also validate how policy is enforced at runtime. Current guidance suggests that platforms evaluating sensitive cloud data should support context-aware decisions based on identity, asset sensitivity, and request purpose, rather than rely only on static allow lists. This aligns with cloud guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls and practical cloud control mapping in the CSA Cloud Controls Matrix. These controls tend to break down in heavily fragmented multi-account environments because cross-account trust, shadow roles, and duplicate logs make identity-to-data tracing inconsistent.

Common Variations and Edge Cases

Tighter in-account inspection often increases operational complexity, requiring organisations to balance lower data movement against deeper cloud permissions and more careful tenant design. That tradeoff becomes more visible in regulated environments, shared services models, and multi-cloud estates where one deployment pattern does not fit every account.

Some platforms run entirely within one cloud account but still create governance debt if they need broad read access, custom key grants, or persistent admin roles. Others preserve locality but lose completeness when they cannot inspect encrypted fields, nested archives, or cross-region replicas without extra configuration. Best practice is evolving here: there is no universal standard for whether “inside the cloud account” is enough on its own. Teams should treat it as a necessary design signal, not a sufficient trust guarantee.

NHIMG research on the Snowflake breach and the 230M AWS environment compromise shows why identity context and cloud-path control matter when access expands faster than governance. In those cases, the problem was not only data placement, but the combination of credential exposure, privilege, and insufficient visibility across cloud boundaries. Teams should therefore ask whether the platform reduces the blast radius of misuse or simply relocates it into a managed layer with its own standing access model.

Related resources from NHI Mgmt Group

• How should security teams evaluate identity controls inside a larger security platform?
• How should security teams evaluate whether a cloud platform is truly sovereign?
• How should security teams evaluate a data security platform against identity risk?
• How should security teams evaluate data discovery tools for cloud, endpoint, and AI coverage?