- In a SANS survey of 400 professionals, misconfiguration caused 45% of critical cloud incidents, and 49% of respondents need over 24 hours to close a known critical gap.
- SANS instructor Serge Borso argues that unclear ownership across many consoles keeps gaps open. That is his interpretation, not a survey measurement.
- Leaders should measure the time from critical finding to fix, name an owner for every cloud account, and block risky settings before deployment.
Misconfiguration leads, and fixes are slow
Misconfiguration was the leading cause of critical cloud incidents in the 2026 SANS Cloud Security Survey, at 45%. Credential theft came next at 22%. The survey covered 400 IT and security professionals.
A second measure looks at speed. About half of respondents (49%) say it takes them longer than a day to close a critical gap once they know about it. The two figures are separate measurements. The survey does not say the incidents came from gaps that teams had already found.
SANS Principal Instructor Serge Borso links the two ideas. His view is that the flaw is ordinary and the delay is the real problem. That is his interpretation. It is worth testing inside your own company.
What the survey found
Cloud is now routine. Infosecurity Magazine reports that 93% of organizations in the survey run live systems there, and 65% use more than one provider. And 51% operate very large environments, with more than 2,500 workloads, containers or instances.
These teams are not thinly staffed. SANS found that 73% have a dedicated cloud security team or role. Yet only 40% call their strategy advanced or optimized. And 45% call it "intermediate", meaning a defined plan is only partly in place.
SANS says that partial rollout leads to security incidents. It also reads the numbers as a maturity gap that persists even in well-resourced organizations.
Borso's view: the weak point is the distance between finding and fixing
A misconfiguration is a cloud setting that is wrong or too open. It is a mistake inside an account the company already owns. Borso calls it "not an exotic attack class".
He says the gap lasts because of the delay between spotting it and fixing it. Many consoles are involved, and nobody clearly owns the outcome. The survey's tool data is consistent with that picture.
Several tool types each watch one layer. Cloud Security Posture Management (CSPM) checks settings. Cloud Workload Protection Platforms (CWPP) watch running workloads. Cloud Infrastructure Entitlement Management (CIEM) tracks who can do what. A Cloud-Native Application Protection Platform (CNAPP) combines all three.
Only 21% of respondents run a single CNAPP. Meanwhile, 31% still keep separate tools for CSPM, CWPP and CIEM. About 23% are weighing a move to consolidate.
Rising budgets have not settled it
Money is not the obvious obstacle. Most surveyed firms are spending more: 70% report higher cloud security spending than a year ago. That breaks down as 28% of respondents reporting major investment to modernize or adopt new technology such as AI or CNAPP, and another 42% reporting modest growth. Only 7% reported budget cuts.
This should make leaders pause before approving another detection product. More tools can mean more places where findings wait. Borso's advice for now is to bring tools together and enforce settings first. In his words, that matters more than "yet another detection tool".
That is his opinion, not a survey result. It does fit the pattern, though: staffed teams, growing budgets, and a day or more to fix known critical gaps.
Two limits apply. The survey is self-reported. The SANS page WebPulse reviewed lists no findings, so the figures here come from Infosecurity Magazine's coverage of the report. That same SANS page also promotes the organization's training courses.
Questions to put to your cloud team
SANS data points to three priorities. One is automatic checks in the code that builds cloud systems, so a risky setting is stopped before launch. Another is merging posture, workload and identity tools into fewer platforms. The third is zero trust that limits what users and workloads can reach after they log in.
Turn those into questions for this week. How many hours pass between a critical finding and its fix? Is that time measured? Does every cloud account have a named owner? How many consoles does a finding cross before someone acts? Can the build process reject a bad setting before it goes live?
Spending shows intent. The time to fix a known gap shows whether anyone owns the result.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: SANS Institute.
