First, we had CSPM (Cloud Security Posture Management). Then DSPM (Data Security Posture Management). Somewhere in there, SSPM (Software-as-a-Service Security Posture Management). Now the label printer has reached the letters “AI,” and AI-SPM (can you guess what it stands for?) is being stapled onto everything from cloud scanners to data governance suites to LLM firewalls. All of them are popular buzzwords of their moment, with the shared suffix doing all the heavy lifting.
At KuppingerCole Analysts, our motto for more than two decades has been simple: stop looking at labels, look for substance and for the ability to address real challenges. Security Posture Management is a useful test of that principle, because the SPM family has become one of the clearest examples of a label outliving its meaning. A buzzword loses its definition the moment enough vendors decide they sell it, and SPM passed that point some time ago.
One capability, four names
Strip away the prefix and every SPM product follows roughly the same pattern. It connects to an environment, assesses configuration and state against a set of policies, and produces a list of things that are wrong. Continuous assessment of posture against policy is a genuine and valuable capability. It is however not a new market every time someone points it at a different asset class.
That is the part the suffix conveniently hides. CSPM, DSPM, SSPM, and AI-SPM are not four fundamentally different ideas. They are one capability aimed at different targets.
The targets matter, of course. Cloud infrastructure, SaaS applications, sensitive data, and AI systems all have different architectures, risks, owners, and remediation paths. But that is exactly the point. The value is not in the shared suffix. The value is in how well the product understands the asset class, the risk model, and the operational workflow behind it.
CSPM: not dead, just absorbed
The capabilities behind CSPM remain useful. They also stopped being a standalone product. Misconfiguration detection, compliance mapping, and cloud risk assessment were quickly folded into broader cloud-native application protection platforms (CNAPP), where they belong, sitting next to workload protection, entitlement management, runtime controls, and remediation workflows. No one needs a separate posture tool whose main deliverable is glorified vulnerability scanning with cloud credentials and a talent for generating five thousand tickets.
A finding you cannot act on is not a security outcome. It is homework. That does not make CSPM useless. It makes CSPM a capability inside something larger. This is a perfectly respectable fate for a security category. It is also one that tends to annoy vendors who built a marketing strategy around the assumption that the suffix would remain billable forever.
DSPM: the same journey, with a detour
DSPM followed a similar path, except it took a more scenic route through inflated expectations. Its core scope is real and foundational: discover sensitive data, classify it, identify exposure, and surface the misconfigurations and access risks around it. Treated as the first layer of a data security program, that work is essential. For a while, though, DSPM was sold as the answer to data security, full stop.
A DSPM tool that only assesses posture cannot deliver the outcome customers were promised, because finding exposure is not the same as fixing it. Posture visibility tells you the house is on fire. It does not hold a hose. And the moment a vendor adds real remediation, protection, workflow integration, and enforcement, the tool has moved beyond posture management. It has become part of a data security platform.
Keeping the DSPM label on it at that point does not describe the product. It keeps the trendier acronym alive a little longer. DSPM is necessary but not sufficient. And when it finally becomes sufficient, it is no longer just DSPM.
SSPM: real, but already outgrowing its name
SSPM points the same machinery at SaaS applications. It connects to Microsoft 365, Salesforce, GitHub, and the dozens of other tenants a modern company runs, then checks them for misconfiguration, over-privileged accounts, dormant admin rights, and risky third-party access. This is genuinely useful work. SaaS sprawl is real, almost nobody configures these applications securely by default, and the blast radius of a single over-scoped integration token is larger than most people realize.
But notice what actually creates the value, and it is not the suffix. It is coverage and depth: how many applications the tool understands, and how well it understands each one. A product that inspects five SaaS apps shallowly is not a category. And the capability follows the same gravitational pull as CSPM, being absorbed into identity security, SaaS management, and SSE platforms, where posture findings sit next to the access and configuration controls that can actually fix them.
AI-SPM: a label in search of a market
AI-SPM is the newest entry in the family, and the cleanest illustration of the problem, because the term is still fresh enough that almost everyone can claim it and almost no one has to define it. Naturally, this has not slowed anyone down.
The label is currently being applied to several different architectures: cloud platforms extended to inventory AI services, data security tools extended to cover training and inference data, purpose-built AI asset discovery and governance platforms, and AI runtime protection products with a posture dashboard bolted on. These are different products, aimed at different problems, often sold to different buyers. They share a hashtag, not a category.
Category boundaries matter because they shape budgets, shortlists, evaluation criteria, and expectations. If AI-SPM means “cloud posture management, but now we also detect Bedrock,” that is one thing. If it means governing AI models, datasets, prompts, agents, tools, permissions, runtime behavior, and regulatory obligations, that is something very different. Pretending both are the same market helps no one except the people printing booth banners.
None of this means the underlying problems are imaginary. Shadow AI is real. Agent permissions are real. AI data leakage is real. The EU AI Act, with penalties reaching €35 million or 7% of global annual turnover, whichever is higher, is extremely real.
The question is not whether AI introduces new security and governance challenges. It is whether putting “SPM” into product names does anything to address them. Spoiler alert: it does not.
What to do when the next prefix arrives
So how should buyers respond the next time a new letter or two shows up in front of SPM?
First, ignore the suffix and write down the capabilities you really need: discovery, classification, posture assessment, policy evaluation, prioritization, enforcement, remediation, and reporting. Map products to that list, not to the acronym on the data sheet.
Second, ask what the tool fixes, not only what it finds. A posture product that cannot remediate, or at least trigger remediation through something that can, is just another input for real security tools. It is not a control.
Third, check whether the capability already exists in a platform you own. CSPM is the cautionary tale here. Plenty of organizations bought it once as a point tool and again inside CNAPP, which is a very expensive way of discovering that suffixes can be recycled.
Fourth, for AI, define the scope before shopping for the label. The defensible boundary is the governance and security layer specific to AI systems as a distinct class of asset, drawn deliberately to avoid overlap with the cloud, data, network, application, and identity controls you already have.
A useful label gives buyers a shortcut to a real set of capabilities, problems, and outcomes. But once everyone claims the label, it stops being a shortcut and becomes noise. Look for capabilities, workflows, outcomes. The acronym will have changed by next quarter anyway.
