CSPM

What is CSPM (Cloud Security Posture Management)?

CSPM, or Cloud Security Posture Management, is a security discipline that continuously monitors cloud infrastructure configurations for misconfigurations, excessive permissions, network exposure, and compliance drift. It connects to cloud environments through provider APIs, reads the actual configuration state of resources across AWS, Azure, and GCP, and compares that state against security benchmarks and policy requirements. Deviations surface as findings. Remediation guidance follows.

CSPM emerged because cloud infrastructure misconfiguration became one of the most consistent sources of data exposure in modern enterprises. Not sophisticated exploitation. Configuration errors that left resources accessible to anyone on the internet, or with permissions far broader than any workload required.

So that's the problem it solves. The cloud estate is large, changes constantly, and is configured by many different people and automation pipelines. Keeping those configurations within the defined security boundary is a continuous problem, not a one-time task.

How CSPM works

CSPM connects to cloud environments through native APIs: AWS Config, Azure Resource Manager, Google Cloud Asset Inventory. It reads the configuration of every resource it can reach: storage buckets, virtual machines, databases, IAM roles, network security groups, logging configurations, encryption settings, and more.

Against each resource, it evaluates a set of rules. Some rules come from security benchmarks: CIS AWS Foundations Benchmark, CIS Azure, CIS GCP. Others come from regulatory frameworks: PCI DSS cloud controls, HIPAA technical safeguard mappings, SOC 2 configuration requirements. Others come from the organisation's own internal policies: no public S3 buckets, all databases must use encryption at rest, all cloud accounts must enforce MFA.

When a resource's actual configuration violates a rule, CSPM generates a finding. The finding identifies the specific resource, the specific rule it violated, the severity of the violation, and typically a remediation path: the API call or configuration change that would bring the resource back into compliance.

Critically, CSPM monitors continuously. A resource provisioned at 9am that was configured correctly can be misconfigured by an infrastructure-as-code change at 2pm. CSPM detects that change within minutes of it occurring. Not at the next monthly scan.

What CSPM detects

CSPM findings cluster into several categories that account for most cloud misconfiguration incidents.

Storage exposure. Publicly accessible cloud storage is consistently one of the most common misconfiguration findings. An S3 bucket configured with public read access, an Azure Blob container with anonymous access enabled, a GCS bucket with allUsers permission: each represents data potentially exposed to the open internet. CSPM detects these configurations the moment they're applied.

IAM over-permissioning. Cloud IAM policies that grant excessive permissions are a persistent problem. Wildcard permissions (* on *), roles that combine read and write access where read alone would suffice, cross-account trust relationships that are broader than required. CSPM evaluates IAM configurations against least-privilege benchmarks and surfaces where permissions exceed what workloads demonstrably need.

Network exposure. Security groups and firewall rules that allow inbound access from 0.0.0.0/0 on sensitive ports. Administrative interfaces exposed to the public internet. Database ports open to ranges that include untrusted networks. CSPM checks network configuration against the principle that production resources should be accessible only from defined, trusted sources.

Encryption gaps. Storage volumes without encryption at rest. Database instances without encryption enabled. Snapshots that inherit unencrypted configurations from their source. CSPM detects the gap between the policy that says "encrypt everything" and the resource configurations that don't.

Logging and monitoring disabled. CloudTrail not enabled in all regions. Azure Monitor diagnostic settings missing from key resources. GCP audit logging not configured for admin activity. CSPM checks that the observability layer required for incident investigation and audit evidence is actually in place, not just assumed to be.

CSPM vs DSPM

The real-world implication of this distinction is prioritisation. CSPM can find 500 misconfiguration findings in a typical enterprise cloud environment. Without knowing what data each misconfigured resource contains, all 500 look equally urgent. With DSPM classification, the 12 findings that involve sensitive personal data, unencrypted financial records, or regulated health information stand out immediately from the 488 that involve misconfigured resources containing only operational metadata.

That's not just an efficiency improvement. It's the difference between security teams spending their remediation effort where it actually reduces risk versus where it happens to appear in the finding list.

CSPM and DSPM answer different questions. Both questions matter. Teams using CSPM without DSPM know which doors are open. Teams using DSPM alongside CSPM know which open doors lead somewhere dangerous.

CSPM and compliance

Most CSPM tools include pre-built benchmark mappings that align infrastructure configuration checks to regulatory and framework requirements. CIS benchmarks for AWS, Azure, and GCP are the most common baseline. Framework-specific mappings include PCI DSS Requirement 6 (secure systems and software), HIPAA Security Rule technical safeguards, SOC 2 Common Criteria for availability and processing integrity, and ISO 27001 Annex A controls for cloud infrastructure.

These mappings let security and compliance teams answer the question: for each applicable framework, which infrastructure controls are currently in a failing state? That's the compliance posture question at the infrastructure configuration layer. It feeds the broader compliance evidence picture but doesn't cover the data-level compliance questions that frameworks like GDPR and DPDP require — those need DSPM.

Where CSPM fits in the cloud security stack

CSPM is one component in a multi-layer cloud security programme. Each layer addresses a different dimension of cloud risk.

CSPM addresses infrastructure configuration risk. CASB addresses SaaS access and data movement risk. DSPM addresses sensitive data posture risk inside cloud environments. CWPP (Cloud Workload Protection Platform) addresses runtime security of cloud compute workloads. CNAPP (Cloud-Native Application Protection Platform) is the emerging category that attempts to unify several of these layers, including CSPM, into a single platform.

The practical question for security architects is which layer covers which risk. A CSPM finding that a database has no encryption at rest is an infrastructure control gap. The same CSPM tool doesn't tell you whether that database contains 50 rows of test data or 20 million records of regulated personal data. That risk context requires DSPM. Both tools are doing their job correctly. They're measuring different things.