A buyer’s guide · Operating since 2002
Moving to cloud transfers a great deal of security work to the provider. It transfers less than most organisations assume, and the part that stays behind — configuration, identity, entitlements, data and monitoring — is where the overwhelming majority of real incidents begin.
This page sets out where the line sits across each service model, what the CSPM, CWPP, CIEM and CNAPP categories each genuinely cover, and what an assessment should look at. Written for enterprises running AWS, Azure and Google Cloud, usually more than one at once.
The model
Where the responsibility line actually sits
Each service model moves the line. Three rows never move at all, and those three are where the incidents are.
The three rows that never change
Your data, your accounts and access, and your identity directory remain yours whether you buy raw compute or finished software. Adopting SaaS hands over the servers and the application. It does not hand over who may log in, or what they can reach once they are in.
This is why identity work outperforms almost everything else in cloud security, and why entitlement analysis is simultaneously the least-bought category and the one most closely tied to how attacks actually progress.
Multi-cloud multiplies the model
Each provider draws the line in a slightly different place, names things differently, and ships different defaults. Competence in one cloud does not transfer cleanly to another.
The gaps we find most often sit exactly where a team carried an assumption from their first provider into their second — a logging default, a public-by-default resource, a role that grants more than its name suggests.
The acronyms
CSPM, CWPP, CIEM, CNAPP and CASB, honestly compared
Five categories that get used interchangeably by people selling them. They answer genuinely different questions, and buying one does not cover the others.
Scroll the table sideways →
| Category | What it does | What it catches | The honest limitation |
|---|---|---|---|
| CSPMposture management | Continuously checks cloud configuration against a baseline. | Public buckets, permissive security groups, unencrypted volumes, missing logging. | Finds misconfiguration, not intrusion. It will tell you the door is unlocked, never that somebody walked through it. |
| CWPPworkload protection | Protects the running workload: VMs, containers, serverless. | Vulnerabilities in images, runtime anomalies, drift from the deployed baseline. | Agent or sidecar coverage decides what it sees. Anything deployed outside your pipeline is invisible to it. |
| CIEMentitlement management | Analyses who and what can do what across cloud identities. | Over-permissive roles, unused entitlements, privilege escalation paths. | The most under-bought category, and the one most closely tied to how real cloud breaches unfold. |
| CNAPPthe bundle | A platform combining the three above, plus code scanning. | Whatever its constituent parts cover, correlated into one view. | The correlation is the value and also the marketing. Ask which underlying capability is genuinely mature rather than acquired last year. |
| CASBaccess broker | Sits between users and SaaS applications. | Shadow IT, risky sharing, data movement into and out of SaaS. | Concerns SaaS usage, not your own cloud infrastructure. Frequently confused with the categories above. |
| SIEM and a SOC | Collects cloud audit logs and has people read them. | Actual attacker behaviour: unusual API calls, new principals, key exfiltration. | Only as good as the logs enabled and retained. Cloud audit logging is off or short-retention by default in more places than people expect. |
The distinction worth holding on to is between posture and activity. Posture tools describe settings at a moment in time. Only logs read by people describe what somebody actually did, which is why the last row exists and why a high posture score and an active intruder are entirely compatible.
Straight answers
What buyers get wrong about cloud security
The provider is almost never the one who failed
Cloud breaches overwhelmingly originate in the customer’s half of the shared responsibility model: a misconfigured storage permission, an over-permissive role, a long-lived access key in a repository, logging that was never enabled. The platform did what it was configured to do. That is uncomfortable but useful, because it means the fixes are within your control.
Three responsibilities never transfer
Whatever you buy — IaaS, PaaS or SaaS — your data, your accounts and access, and your identity directory remain yours. Moving to SaaS hands over the servers and the application; it does not hand over who is allowed to log in or what they may reach once inside.
“We have a posture score of 94%”
A posture score measures settings against a benchmark at a point in time. It is a useful hygiene metric and it is not a statement about whether anyone is currently in your environment. Two different questions, frequently answered with one number.
Cloud audit logging is not on by default everywhere
Several important log categories across the major providers are either disabled or retained briefly unless deliberately configured. Organisations discover this during an incident, at the exact moment the missing history mattered. It is a cheap thing to check and an expensive thing to discover late.
“Is identity in scope, or just configuration?”
Entitlement analysis is the least-bought and most closely correlated with how cloud attacks actually progress. An assessment that reviews security groups but never asks which roles can escalate to administrator has examined the fence and ignored the gate.
Multi-cloud multiplies the model, not the effort you planned for
Each provider names things differently, sets different defaults, and draws the responsibility line in a slightly different place. Teams competent in one cloud routinely carry incorrect assumptions into the second, and the gap sits precisely where the defaults differ.
Before you sign
Ten questions for a cloud security assessment
Use these on us and on everyone else you shortlist. Question two is the one most assessments quietly fail.
Which accounts, subscriptions and projects are actually in scope?
Shadow accounts opened with a corporate card are routine and are exactly where unmanaged exposure accumulates. Ask how the inventory is established rather than accepting the list you already have.
Do you assess entitlements, or only configuration?
Posture tools check settings. Most real cloud incidents run through identity — an over-permissioned role, a long-lived key, a service principal nobody owns. Configuration-only assessment misses the actual path.
Which audit logs are enabled, and how long are they retained?
CloudTrail, Azure Activity and GCP Audit are the record of what happened. Default retention is short and some categories are off unless switched on. Under CERT-In Direction 20(3) of 2022, logs must be retained for 180 days and held within India, which is a configuration decision in every cloud.
Where does the data and the telemetry physically sit?
Region selection is a deliberate choice, not a default, and it interacts with both CERT-In retention duties and any sectoral requirement your regulator imposes.
Is anything watching at runtime, or only at configuration time?
A clean posture score is a statement about settings at a moment. It says nothing about the credential being used right now.
How are findings prioritised?
A CSPM pointed at a large estate produces thousands of findings on day one. Ask what the triage process is and who does it, or the report becomes a backlog nobody opens.
What happens when someone changes a setting after the assessment?
Point-in-time assessment plus no continuous checking equals a report that expires the first time somebody deploys. Ask how drift is detected.
Are container and Kubernetes configurations in scope?
Cluster RBAC, admission control and image provenance are a separate discipline from cloud account configuration, and are often quietly excluded.
Who acts when something is found at 3 a.m.?
Assessment finds problems. Ask whether the same provider can respond, and what they are permitted to do without waking you — see managed SOC services.
Do we keep the findings, the baselines and the tooling configuration?
Work done inside a provider’s platform leaves with the provider. Agree what transfers before you start.
Working with us
How we run this
We have secured enterprise infrastructure since 2002 and we run the operations centre that watches it afterwards. Cloud is not a separate practice here; it is part of the same estate.
Identity first
Entitlement analysis is part of the assessment rather than an upsell, because that is the path real attacks take.
Logging you can rely on
We check what is enabled, what is retained and where it lives — including the 180-day India-resident retention CERT-In Direction 20(3)/2022 requires.
Prioritised, not exported
Findings ranked by real exploitability in your estate, not a raw tool export with a cover page.
Watched afterwards
Cloud audit logs feed the same 24×7 operations centre as the rest of your estate — see managed SOC and threat hunting.
Read-only to start
Assessment needs a read-only role you create and can revoke. Anything needing write access is scoped and agreed separately.
Certified operations
ISO/IEC 27001:2022 certified, with our security operations centre inside the certified scope and the scope statement available on request.
Questions we get asked
Cloud security, answered
What is cloud security?
Cloud security is the practice of protecting the part of a cloud environment that remains your responsibility — which is more than most organisations assume. The provider secures the physical infrastructure, the hypervisor and, depending on the service model, the operating system and application. Configuration, identity, entitlements, data and monitoring stay with you in every model, and that is where the overwhelming majority of incidents begin.
What is the shared responsibility model?
It is the division of security duties between a cloud provider and its customer. As you move from IaaS towards SaaS the provider absorbs more of the stack — servers, virtualisation, operating system, eventually the application itself. What never transfers is your data, your accounts and access, and your identity directory. The diagram above shows those three rows keeping the same colour across every column, and they are where breaches concentrate.
What is CSPM?
Cloud Security Posture Management continuously compares your cloud configuration against a baseline and reports where it deviates: public storage, permissive network rules, unencrypted volumes, disabled logging. It is genuinely valuable hygiene. Its limitation is that it describes settings, not activity — it will tell you a door is unlocked and can never tell you that someone walked through it.
What is the difference between CSPM, CWPP, CIEM and CNAPP?
CSPM checks configuration. CWPP protects running workloads — virtual machines, containers, serverless functions. CIEM analyses identities and entitlements, asking who and what can do what. CNAPP is a platform bundling those together, usually with code scanning as well. The comparison table above sets out what each catches and what each misses; the short version is that they answer different questions and buying one does not cover the others.
What is a cloud security assessment?
A scoped review of your cloud estate covering account and subscription inventory, configuration against a recognised baseline, identity and entitlement analysis, logging and retention, network exposure, and data protection. The output is a prioritised, exploitable-first list rather than a raw export — the difference matters, because a posture tool pointed at a large estate produces thousands of findings on day one and most of them are noise.
Why do most cloud breaches happen?
Misconfiguration and credential abuse, in that order, and both sit squarely in the customer’s half of the responsibility model. Publicly exposed storage, over-permissive roles, long-lived access keys committed to repositories, and multi-factor authentication missing on an administrative account account for a very large share of real incidents. Almost none involve a failure of the provider’s own infrastructure.
What are the CERT-In requirements for cloud logs?
CERT-In Direction 20(3)/2022 requires organisations to maintain logs of ICT systems for a rolling period of 180 days and to keep them within India. In cloud terms that is a configuration decision: audit log retention defaults are frequently shorter than 180 days, and region selection determines where those logs are stored. Both need setting deliberately, and both are checked in our assessment.
Do you work across AWS, Azure and GCP?
Yes, and multi-cloud is the common case rather than the exception. It is worth saying that the providers name things differently, set different defaults and draw the responsibility line in slightly different places, so competence in one does not transfer cleanly to another. The gaps we find most often sit exactly where a team’s assumptions from their first cloud were carried into their second.
Are containers and Kubernetes included?
They can be, and they should be scoped explicitly because they are a separate discipline from cloud account configuration. Cluster role-based access control, admission control, image provenance and runtime behaviour are their own body of work, and are frequently excluded from assessments by default without anyone noticing.
Is this continuous or point in time?
Both are available and they answer different questions. A point-in-time assessment establishes where you stand and what to fix. Continuous posture monitoring catches the drift that begins the moment someone deploys after the report was written. An assessment with no continuous follow-up is accurate on the day it is delivered and decays from there.
How does this connect to your SOC?
Cloud audit logs feed the same operations centre that watches the rest of your estate, so an unusual API call or a new administrative principal is investigated by people rather than added to a dashboard. Posture tells you the door was unlocked; the SOC tells you somebody used it.
Do you need administrative access to our cloud?
Read-only access is sufficient for assessment, granted through a role you create and can revoke. Anything requiring write access — remediation, deploying monitoring — is agreed separately and scoped to exactly what it needs.
What does the report contain?
An inventory of what actually exists, findings prioritised by real exploitability rather than by raw severity, the identity and entitlement paths that matter most, logging and retention gaps against your obligations, and remediation guidance specific enough for your team to act on. Plus a short summary for whoever has to fund the work.
How is this priced?
By the number of accounts or subscriptions, the service models in use, whether identity and container scope are included, and whether you want a one-off assessment or continuous monitoring afterwards. We will scope it against your actual estate rather than a headcount.
Next step
Start with an inventory, not a tool
Tell us which providers you use and roughly how many accounts or subscriptions exist. The first useful output is almost always a complete list of what is actually running, because it is rarely the list anyone expected. From there we scope the assessment properly.