CSPM Alert Prioritization: From 500 Daily Findings to 20 You Should Actually Fix
Every team that buys a CSPM tool hits the same wall within 30 days: hundreds of findings, no clear priority, and a security team that cannot process them fast enough to keep up. The answer is not to buy a second tool or hire more people -- it is to build a scoring model that identifies your actual material risk and separates it from the background noise. This guide walks the scoring model, the suppression workflow, the 90-day baseline approach, and how to measure progress.
The Three-Dimension Scoring Model
CSPM severity ratings tell you how bad a finding could be in the worst case. Your actual risk depends on three factors working together:
Dimension 1: CSPM Severity (the tool's rating)
- Critical, High, Medium, Low
- Use as-is; do not override the tool's technical severity assessment
Dimension 2: Asset Criticality (your classification) Tag every cloud resource with a criticality tier during your first week:
Critical: Production workloads handling customer data, financial transactions, or authentication
High: Production supporting services (logging, monitoring, CI/CD)
Medium: Staging/pre-production environments with production-equivalent data
Low: Development, test, sandbox environments with synthetic data
In AWS, apply as a resource tag: Criticality: critical|high|medium|low
In Azure, use resource tags: criticality: critical|high|medium|low
In GCP, use labels: criticality: critical|high|medium|low
Dimension 3: Exploitability (network reachability)
- Directly internet-exposed: the resource has a public IP or is reachable via load balancer from 0.0.0.0/0
- Indirectly exposed: reachable from the internet via multiple hops (e.g., behind a private subnet but accessible from a publicly exposed host)
- Internal only: no internet path exists
Wiz and Orca calculate attack paths automatically. In Prisma Cloud, use Network Analyzer. For manual assessment, check: security groups with 0.0.0.0/0 inbound, public load balancer targets, S3 buckets with public ACLs.
Priority matrix:
| CSPM Severity | Asset Criticality | Exploitability | Priority | SLA |
|---|---|---|---|---|
| Critical | Critical | Internet-exposed | P0 | Fix within 24 hours |
| Critical | Critical | Internal | P1 | Fix within 7 days |
| Critical | High | Internet-exposed | P1 | Fix within 7 days |
| High | Critical | Internet-exposed | P1 | Fix within 7 days |
| Critical | Medium/Low | Any | P2 | Fix within 30 days |
| High | High/Medium | Internal | P2 | Fix within 30 days |
| Medium | Critical | Internet-exposed | P2 | Fix within 30 days |
| Everything else | - | - | P3 | Quarterly review |
Day 1-30: Building Your Working Baseline
Do not try to fix 500 findings. Do this instead:
Week 1: Asset tagging sprint Tag every cloud resource with criticality before looking at findings. Without asset criticality context, you cannot score anything. Assign engineering leads for each account/workload; they know which resources matter.
# AWS: bulk tag resources in an account
aws resourcegroupstaggingapi tag-resources \
--resource-arn-list arn:aws:s3:::my-prod-bucket \
--tags Criticality=critical,Environment=production
# Tag all EC2 instances in a region
aws ec2 describe-instances --query 'Reservations[].Instances[].InstanceId' --output text | \
xargs -I {} aws ec2 create-tags \
--resources {} \
--tags Key=Criticality,Value=high Key=Environment,Value=production
Week 2: Apply the P0 filter -- find your actual fire Filter your CSPM to show only: Critical severity + Critical assets + Internet-exposed. This is your P0 list. It should be 5-20 findings, not 500.
In Wiz: Filters: Severity = Critical, Has Internet Exposure = Yes, Asset Tag Criticality = critical In Prisma Cloud: Asset Explorer > Filters: Risk Rating = Critical, Internet Exposed = true, Tag: Criticality = critical In Orca: Risks > Filter: Severity = Critical, Attack Surface = Internet Facing, Tags: criticality = critical
Fix your P0 list before anything else. These are the findings that could result in a breach this week.
Week 3-4: P1 and suppression setup After P0 is clear, move to P1 (Critical + Critical asset + internal, or Critical + High asset + internet-exposed).
In parallel, begin suppressing clear false positives:
- Public CDN S3 buckets flagged as 'public access enabled' (intentional)
- Dev/test accounts flagged for missing encryption (accepted risk with documented exception)
- Findings on decommissioned resources that appear in inventory but have no actual workload
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Suppression Workflow: What to Suppress and How to Document It
Every suppression is a risk decision. Document it or you've created an invisible blind spot.
Categories safe to suppress (with documentation):
| Finding type | Suppression reason | Required documentation |
|---|---|---|
| Public S3 bucket (intentional CDN) | Business necessity | Which bucket, what content, who reviewed |
| Unencrypted dev database | Data classification: no sensitive data | Data owner sign-off, quarterly review |
| Missing MFA on break-glass account | Security architecture decision | CISO sign-off, monitoring alert as compensating control |
| Logging gap in sandbox account | Accepted risk for non-production | Engineering lead sign-off, criticality: low tag |
Never suppress without a ticket. Every suppression in the CSPM tool should have a corresponding ticket number in your tracking system (Jira, ServiceNow, etc.).
Suppression template:
Finding ID: [CSPM finding ID]
Resource: [ARN / resource identifier]
Suppression reason: [false positive / accepted risk / compensating control]
Business justification: [1-2 sentences]
Compensating controls (if any): [what else reduces this risk]
Approved by: [name + title]
Review date: [90 days from today]
Ticket: [JIRA-1234]
Set calendar reminders for every suppression review date. A suppression that was valid when created may not be valid 90 days later -- the CDN bucket may have been repurposed for sensitive data, the dev account may now have prod data in it.
The 90-Day Baseline: What 'Under Control' Looks Like
After 90 days of consistent work, a functioning CSPM program produces:
Volume targets:
- P0 findings (Critical + Critical asset + internet-exposed): 0 open >24 hours
- P1 findings open >7 days: <5
- P2 findings open >30 days: declining month-over-month
- New Critical findings introduced per week: tracked and reviewed within 48 hours
Process markers:
- Every open finding in P0/P1/P2 has an owner and a target remediation date
- Every suppression has a ticket and a review date
- Weekly or bi-weekly sync with engineering leads to review P1 findings
- Monthly metric reported to security leadership: P0/P1 closure rate
What your weekly CSPM review looks like at 90 days:
- Check new findings from the last 7 days: any new P0s? (target: zero, escalate immediately if not)
- Check P1 findings approaching SLA: need engineering escalation?
- Check suppression review dates expiring this week: renew or lift
- Update the monthly trend chart (10 minutes)
If your weekly review takes more than 30 minutes, your P0/P1/P2 filters are not scoped tightly enough.
Tracking Progress Without Drowning in Dashboards
Track four numbers. Report them monthly to security leadership and quarterly to the board.
| Metric | Definition | How to pull |
|---|---|---|
| P0 open duration | Average time P0 findings are open before remediation | CSPM + ticketing system |
| P1 SLA compliance | % of P1 findings closed within 7-day SLA | CSPM + ticketing system |
| New Critical findings (weekly) | Count of new Critical findings per week, trend | CSPM weekly digest |
| Suppression review compliance | % of suppressions reviewed before expiry | Suppression ticket log |
Simple trend chart -- paste into your monthly security report:
Month | P0 open | P1 SLA% | New Crit/wk | Supp reviewed
Jan 2026 | 14 | 42% | 23 | 60%
Feb 2026 | 6 | 67% | 18 | 78%
Mar 2026 | 1 | 81% | 12 | 91%
Apr 2026 | 0 | 88% | 8 | 95%
This trend tells a clear story: P0 exposure time is collapsing, SLA compliance is improving, new finding introduction rate is declining (your developers are fixing root causes), and suppression governance is tightening. That story is your evidence that the program is working.
Connecting CSPM to Engineering: The Handoff That Most Teams Get Wrong
CSPM findings are remediated by engineers, not security teams. If security identifies, tracks, AND remediates, you have a scaling problem. The handoff must be clean.
What the security team owns:
- Running the CSPM tool
- Applying the scoring model and identifying P0/P1/P2
- Creating tickets with finding details, remediation steps, and SLA
- Tracking SLA compliance and escalating overdue items
- Making suppression decisions and documenting them
What engineering teams own:
- Fixing the finding within SLA
- Tagging resources with criticality (they know which workloads matter)
- Flagging findings they believe are false positives back to security for suppression review
- Asking for security review before launching new workloads (shift-left)
Ticket format that engineers will actually act on:
Title: [CSPM] CRITICAL: S3 bucket prod-customer-data publicly readable
Severity: P1 (Critical finding on production asset)
SLA: Fix by [DATE - 7 days from today]
Finding: The S3 bucket 'prod-customer-data' has ACL set to public-read.
This bucket contains customer PII (per data classification tag).
Risk: Any unauthenticated user can read all objects in this bucket.
The bucket contains approximately 2.4M customer records.
Fix (2 commands):
aws s3api put-bucket-acl --bucket prod-customer-data --acl private
aws s3api put-public-access-block --bucket prod-customer-data \
--public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true
Verification: Run aws s3api get-public-access-block --bucket prod-customer-data
and confirm all four values are 'true'.
If this is intentional (public CDN bucket), reply on this ticket with the
business justification and tag @security-team for suppression review.
Tickets with exact fix commands get remediated. Tickets that say 'review S3 bucket security configuration' do not.
The bottom line
CSPM tools generate hundreds of findings because they are designed to be comprehensive, not prioritized. Your job is to add the context the tool lacks: which assets are critical, which findings are internet-reachable, which risks are accepted. Apply the three-dimension scoring model, fix P0 in 24 hours, clear P1 within 7 days, and track four metrics monthly. At 90 days you will have a baseline; at 6 months you will have a trend; at 12 months you will have a program.
Frequently asked questions
Why does my CSPM show hundreds of critical findings when nothing bad has happened?
CSPM tools flag deviations from security best practices, not confirmed attacks. A 'Critical' finding like 'S3 bucket is publicly accessible' is critical because of its potential impact if it contained sensitive data -- not because an attack is in progress. Many critical findings are on non-production assets, empty buckets, or workloads behind additional compensating controls. The tool cannot know which findings are actually material to your business without context you provide through asset tagging, suppression rules, and risk acceptance.
What is the difference between suppressing a finding and accepting a risk?
Suppression removes a finding from the active queue because it is a false positive -- the finding does not accurately represent a risk (e.g., an S3 bucket flagged as public that is an intentional public CDN). Risk acceptance acknowledges that the finding is a real risk but documents a business decision not to remediate it within the standard SLA (e.g., an unencrypted legacy database that cannot be encrypted without a multi-month migration project). Both require documentation; risk acceptance requires sign-off at an appropriate authority level.
How do I prioritize CSPM findings across multiple cloud accounts?
Score each finding on three dimensions: CSPM severity (the tool's own rating), asset criticality (your classification of how important the affected resource is to the business), and exploitability (is the finding directly reachable from the internet, or is it behind multiple layers?). A Critical finding on a development account's non-public resource may be lower priority than a Medium finding on a production database with internet-facing network path. Most CSPMs support custom scoring; use it.
Should I try to get to zero findings?
No. Zero findings is not a realistic or meaningful target. The realistic targets are: zero findings in the 'Critical severity + internet-reachable + production asset' intersection (your actual material risk), no new Critical findings introduced in the last 30 days without a documented acceptance or remediation plan, and a declining trend in the total count of findings in your defined priority buckets. Chasing total finding count to zero drives teams to suppress aggressively, which hides real risk.
What CSPM findings can I safely accept as low priority without detailed review?
As a starting point, findings that are lower priority for most organizations: logging and monitoring gaps on non-production accounts (fix in prod first), tagging/naming convention violations (compliance hygiene, not security risk), unused IAM access keys for service accounts on air-gapped development environments, and encryption recommendations for data classified as non-sensitive. Never auto-accept findings involving internet exposure, admin/root access, or production data stores -- those require individual review.
How do I set up CSPM finding SLAs without overwhelming the team?
Define SLAs only for the findings in your active working queue, not for all findings. Example: Critical + production + internet-exposed = 24 hours. High + production = 7 days. Medium + production = 30 days. Everything else = quarterly review. The SLA conversation should be with the asset owner (the engineering team responsible for the workload), not just the security team. Security identifies and tracks; engineering remediates. Define that handoff clearly or findings will sit unworked.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.