DSPM needs a data-centric model, not a CNAPP add-on

At a glance

What this is: Sentra says DSPM only works as intended when it starts from the data estate, because CNAPP and CSPM modules remain centred on infrastructure and miss shadow data, nuanced classification, and hybrid coverage.

Why it matters: For IAM, NHI, and data security teams, the issue is that data-risk governance cannot depend on infrastructure-only visibility when sensitive information moves across cloud, SaaS, on-prem, and unmanaged locations.

Context

Data security posture management is meant to answer a different question from cloud posture tools: where is the sensitive data, how risky is it, and what is happening to it across its lifecycle. The article argues that infrastructure-centric security can improve cloud hygiene while still leaving critical data blind spots untouched.

That distinction matters for identity and access governance because exposure is often created at the point of access and movement, not only at the point of infrastructure misconfiguration. When classification is shallow or coverage stops at known public cloud assets, lifecycle controls, access decisions, and privacy obligations can all be operating with an incomplete picture.

Key questions

Q: Why do CNAPP and CSPM modules fail to cover data risk fully?

A: They are built to find misconfigurations and attack paths in infrastructure, so their view of risk stops where monitored cloud resources stop. That means they can improve posture while still missing shadow data, copied records, nuanced sensitivity, and assets outside public cloud coverage. Data risk needs data-centric discovery, not just infrastructure triage.

Q: When should organisations prioritise standalone DSPM over a CNAPP add-on?

A: Prioritise standalone DSPM when sensitive data moves across public cloud, private cloud, SaaS, and on-premises systems, or when privacy and residency obligations depend on knowing where data actually lives. If the environment includes shadow data, local copies, or mixed sensitivity, a module inside CNAPP is usually too constrained to govern the estate properly.

Q: What do security teams get wrong about data discovery programs?

A: They often assume discovery alone reduces risk. In practice, finding sensitive data without shrinking access paths creates a backlog of known exposure. Teams need ownership, enforcement, and entitlement change, otherwise DSPM becomes a map of the problem rather than a control for it.

Q: How should teams balance DSPM with CNAPP and CSPM in a modern security programme?

A: Use CNAPP and CSPM to manage cloud posture, then use DSPM to govern the data itself across all environments. The two controls are complementary, but they answer different questions. A mature programme separates attack-path reduction from data-centric discovery, classification, and monitoring.

Technical breakdown

Why infrastructure-centric discovery misses the data estate

CNAPP and CSPM are designed to find misconfigurations, exposed services, and attack paths in cloud infrastructure. That makes them useful for perimeter and workload risk, but not for understanding where sensitive data actually lives or how it is used. A data-centric model starts with the asset itself, then adds context such as business purpose, sensitivity, residency, and movement patterns. That difference changes the unit of control from the cloud resource to the data object, which is why add-on modules usually inherit the limits of the base platform rather than redefining the security model.

Practical implication: Use infrastructure tools for posture and path risk, but do not treat them as a substitute for full data discovery and classification.

Why basic classification misses shadow data and toxic combinations

The article points to a common failure mode: pattern matching can find obvious values like card numbers or government identifiers, but it misses nuanced personal data and risky combinations of otherwise ordinary fields. That is a classification problem, not just a detection problem. If a system only recognises isolated indicators, it cannot reliably identify abandoned copies, local exports, or sensitive records assembled from multiple low-risk attributes. This is where shallow labels create false confidence, because the data is present but the control plane does not understand its context.

Practical implication: Validate whether classification logic can recognise context-rich records, copied datasets, and composite sensitivity rather than only obvious regex matches.

How hybrid coverage changes the governance model

A standalone DSPM platform is framed here as a control that follows data across public cloud, private cloud, SaaS, and on-premises environments. That matters because the security question is not only where the data started, but where it was copied, transformed, or abandoned. In governance terms, this creates a broader control boundary than CNAPP or CSPM can normally provide. It also ties DSPM to privacy obligations and data protection workflows, where residency, retention, and access context all influence the risk decision.

Practical implication: Anchor policy enforcement to the full data estate, not just monitored cloud accounts and known attack paths.

NHI Mgmt Group analysis

Data-centric security is a control model, not a module. Treating DSPM as an add-on to CNAPP or CSPM preserves the wrong mental model because the platform still reasons from infrastructure outward. That works for attack-path reduction, but it does not solve data discovery, data movement, or privacy exposure across a mixed estate. The practitioner lesson is to align tooling to the asset being governed, not to the deployment surface.

Shallow classification creates governance debt. When a platform can only recognise obvious patterns, it pushes the hard work of context back onto analysts and policy teams. That creates operational drag and a higher false-positive burden, especially where data sensitivity depends on combinations, business meaning, or location. The result is not just weaker detection, but weaker accountability for what data exists and why it matters.

Hybrid data visibility now belongs in the same conversation as access governance. Data that moves from protected environments into lower-trust stores, local machines, or unmonitored clouds becomes a governance problem as much as a security one. That is where identity and access decisions intersect with DSPM, because who can reach the data is only one part of the control story. The practitioner conclusion is to govern data posture wherever the data travels.

Shadow data is the named concept that matters here. This is the data that is unknown, unmanaged, copied, or abandoned outside the security team’s direct view. Once data becomes shadow data, infrastructure-centric controls no longer describe the full risk surface, and policy enforcement becomes partial by design. Practitioners should treat shadow data discovery as a first-class governance requirement, not an auxiliary reporting feature.

From our research library:

• 82% of breaches involved data stored in the cloud, according to IBM (2024).
• Read next: Identity Security Posture Management (ISPM) Guide

What this signals

Data-centric security has to be measured against the estate, not the cloud account. If visibility stops at public cloud, the programme can still be blind to copied records, abandoned exports, and sensitive data living in lower-trust locations. That is why DSPM must be assessed as a governance layer over the data estate, not as a feature inside infrastructure tooling.

Shadow data is the control gap that changes the buying decision. Once teams accept that unknown data can exist outside monitored cloud paths, the question becomes whether a tool can find and classify it before policy enforcement is attempted. That is the operational dividing line between posture management and data security.

Hybrid coverage is now a practical requirement for privacy and risk teams. For organisations with mixed cloud and on-premises estates, the programme should expect one control set to manage infrastructure risk and another to manage data exposure, movement, and context. Anything less leaves the security model incomplete.

For practitioners

• Map the full data estate before evaluating DSPM Inventory data across public cloud, private cloud, SaaS, and on-premises systems so tool choice reflects the actual distribution of sensitive assets.
• Test for contextual classification, not just pattern matching Use records containing mixed identifiers, composite attributes, and business-specific fields to see whether the platform can classify sensitivity beyond obvious strings.
• Validate shadow data discovery across unmanaged locations Check whether copied datasets, local stores, and abandoned exports are discovered when they sit outside the CNAPP or CSPM coverage boundary.
• Separate posture triage from data governance decisions Use infrastructure tooling to prioritise cloud misconfigurations, but require DSPM evidence before making privacy, residency, or data-risk decisions.

Key takeaways

• CNAPP and CSPM can improve cloud posture, but they do not replace a data-centric control model for sensitive information.
• The article’s central gap is shadow data and context-aware classification, which infrastructure-centric modules often miss.
• Practitioners should separate infrastructure triage from data governance and choose tooling that follows data across the full estate.

Key terms

• Data Security Posture Management: Data Security Posture Management, or DSPM, is the continuous discovery and monitoring of where sensitive data lives, how it is exposed, and where policy gaps exist. Its value rises when it feeds remediation rather than generating findings alone, especially in environments where AI expands the number of data paths.
• Shadow Data: Shadow data is sensitive information that exists outside the places security teams expect to find it. It often appears in testing copies, ad hoc exports, SaaS tools, or AI workflows, which makes it hard to govern with inventory-based controls alone.
• Data Centric Security: Data Centric Security protects information itself, rather than relying only on the security of systems that store or move it. It uses controls such as classification, encryption, tokenization, access policies, and usage restrictions so data remains protected wherever it travels, is copied, or is processed across cloud, endpoint, and application environments.
• Toxic Risk Combinations: Toxic risk combinations are unsafe interactions between datasets, access permissions, and AI workflows that only become problematic when combined. Individually they may appear harmless, but together they can expose sensitive information, enable re-identification, or create unintended inferences that traditional controls may miss.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the wider identity security context. It helps practitioners connect identity controls to the programmes that depend on them.