Every year, organizations buy CSPM tools — Wiz, Orca, Prisma Cloud, ScoutSuite — and declare their cloud risk posture "managed." Then six months later they're drowning in alerts they don't understand, with findings that have been open for ninety days, and no clear answer to the question: are we actually more secure?
CSPM tools are necessary. They're not sufficient. Here's what the gap looks like and how to close it.
What the tool gives you
Modern CSPM tools are genuinely impressive. Wiz, in particular, builds a cloud security graph that maps relationships between resources — so instead of seeing "this S3 bucket is public," you see "this public S3 bucket is accessible to this IAM role that is also attached to this EC2 instance that has this network path." That context changes the risk conversation significantly.
What the tool gives you: visibility, prioritization signals, and a compliance mapping scaffold. It identifies misconfigurations against CIS benchmarks, SOC 2, ISO 27001, and other frameworks. It alerts on drift. It produces reports.
What the tool doesn't give you
The tool cannot tell you what your risk appetite is. It cannot decide which findings are acceptable given your architecture choices. It cannot escalate intelligently to the right owner. It cannot close tickets. It cannot explain to your auditor why you chose to accept a specific risk.
These are all governance problems. And they require governance solutions.
A CSPM tool without a response process is just an expensive way to feel anxious about your cloud environment.
Building the practice around the tool
The operational model that works:
1. Define your finding taxonomy before you deploy
Critical, High, Medium, Low — these are just labels until you attach SLAs and owners to them. Before you go live with CSPM, define: what does "Critical" mean in our environment, who owns remediation, and what's the response SLA? Document this as a policy, not just a verbal agreement.
2. Suppress noise deliberately
Every CSPM tool ships with default rulesets that will generate hundreds of findings in any reasonably complex environment. Some of those findings are irrelevant to your architecture. Some are mitigated by compensating controls. Some represent accepted risks.
Build a suppression policy. Every suppressed finding needs a documented rationale and a review date. Your suppression list is evidence — treat it that way.
3. Map findings to control owners, not teams
Assigning CSPM findings to "the cloud team" or "DevOps" is a path to nothing getting remediated. Map findings to specific control owners who have the accountability and access to act. This requires working with engineering to understand who actually owns what.
4. Close the loop with your GRC tool
CSPM findings that map to compliance controls should create tickets in your GRC platform (Drata, Vanta, Jira, whatever you use). This is where the compliance evidence trail gets built. A finding that was opened, remediated, and closed — with timestamps — is meaningful evidence. A screenshot from Wiz is not.
The ScoutSuite use case
ScoutSuite is open source and worth having in your toolkit alongside commercial tooling. It's excellent for point-in-time assessments — particularly useful for third-party risk assessments where you need a read-only snapshot of a vendor's AWS environment without giving them access to your CSPM tenant.
The output is a structured HTML report with findings organized by service. Not as polished as Wiz, but the data is solid and the no-cost factor matters when you're doing TPRM at scale.
The honest metric
The metric that tells you whether your CSPM practice is working: mean time to remediation for Critical and High findings, trended over time. If that number is going down, you have a functioning program. If it's flat or rising despite the tool being deployed, you have a tool problem that a governance solution needs to fix.
Buy the tool. Build the practice. That's the order that works.