How to prioritise 4,000 cloud findings in one afternoon

The goal for the afternoon is not to fix four thousand findings. It is to produce a short list, with owners, that you can defend when someone asks why those and not the others. Here is the order that gets there.

Step 1: check what the list covers (20 minutes)

Before ranking anything, find out what is missing. A findings list describes only the accounts that scanned successfully, and an empty section is not a clean one. Check three things.

• Every account is present. Compare the accounts in the export with the accounts you own. A forgotten sandbox and an acquired company's account are the usual gaps.
• Every scan finished. Look for failed or still-running scans. A failed collection produces fewer findings, which looks like good news.
• The data is current. Note the age of the last scan for each account. A list from last month ranks last month's risk.

Write down what you cannot see. It goes at the top of whatever you hand to anyone else.

Step 2: collapse the list by cause (40 minutes)

A long export is usually the same decision repeated. One rule fires on three hundred buckets. One base image is under two hundred containers. Group by rule first, then by resource owner or tag, and the count of distinct decisions falls well below the count of rows. You are not removing findings, only recognising that a single change fixes many.

For each large group, ask whether there is a shared cause: a Terraform module, a default in a template, a base image, a policy attached to a group. Fix the cause once and the whole group closes. Note these as single work items.

Step 3: separate what faces the internet (30 minutes)

Filter to resources an outsider can reach. For each finding, ask one question: can someone on the internet get to this? Public load balancers, open security groups, public buckets, functions with public URLs and exposed management ports all count. Everything else drops a tier.

This is the cheapest meaningful cut, because it needs only network data. It is also where a scanner's severity and your actual exposure diverge most. A high-severity finding with no route to it can wait. A medium on a public service moves up. This is the logic behind attack path analysis, done by hand.

Step 4: look at identity (40 minutes)

Next, find the identities that can do too much. List roles and users with administrative permissions, roles that can assume other roles, and trust policies that admit external accounts or whole organisations. Identity findings often rank low in a scanner because they have no CVE, yet they are what turns one stolen credential into an incident.

For each risky identity, note what it can reach and what could become it. A high-privilege role that only a human with multi-factor authentication can assume is a different matter from one that a public service runs as. See CIEM explained for how to read this.

Step 5: use exploit signals to break ties (20 minutes)

Now the vulnerabilities, with the filters already applied. Among the internet-facing and identity-adjacent findings, use two signals to order them. The CISA Known Exploited Vulnerabilities catalogue lists flaws known to have been used in attacks. EPSS estimates the likelihood that a flaw will be exploited in the near term. A flaw on KEV that is also on a public host goes to the top. A high CVSS with neither signal, on an unreachable host, goes to the bottom.

Do not skip this step, and do not do it first. Exploit signals are strong only once you know whether the host is reachable. CVSS, EPSS and KEV explains what each one actually measures.

Step 6: pick the work and name an owner (30 minutes)

You now have a handful of tiers. Take a short list from the top and make each item specific enough to hand over:

1. Internet-facing resources with a known-exploited flaw.
2. Identities that can reach production data and can be reached from outside.
3. Shared causes that close many findings at once.
4. Everything else, scheduled by severity.

Each item needs a named owner, a clear change, and a way to verify it. The last part is the one that is skipped. A finding marked done is not fixed until a fresh scan shows it no longer reproduces, which is why detection and triage should be separate states.

What not to do

• Do not sort by CVSS and work down. It is the default and it is the weakest ordering available. Attack paths vs CVSS shows why.
• Do not suppress to make the number smaller. Suppression changes a queue. It does not remove the condition, and in some tools it still counts toward risk and compliance.
• Do not skip the blast radius check on shared resources. A resource that many things depend on deserves attention before its score suggests it. See blast radius.
• Do not treat the list as the whole estate. It is a view of what was scanned, as step one showed.

If you only have an hour

Cut the sequence down to its two highest-value moves. First, list everything an outsider can reach and read only the findings attached to those resources. Second, list identities with administrative rights and the roles that can become them, and read only their findings. Skip the grouping and the exploit signals for now, and say so in your note.

It will not be a complete ordering, but it covers the two places where one mistake most often becomes an incident. The rest of the list is still there next week, and the day after you can do the steps you skipped.

What you should have by the end of the afternoon

A one-page note with four parts: what the data does and does not cover, the handful of shared causes worth fixing once, the internet-facing and identity items at the top with owners, and a plan to re-scan and confirm. It is short, it can be defended, and it will still be useful next week.

FAQ

Should I fix all critical findings first?

Not as a rule. Critical describes a flaw in a generic setting. A critical on an unreachable resource can wait behind a medium on a public service that holds sensitive data.

How do I know a finding is fixed?

When a fresh scan no longer detects it. A team marking a finding as resolved is a claim, and the scan is the check.

What if I have no information on which resources are internet-facing?

Start by listing load balancers, public IP addresses, open security group rules and public storage. Even a rough list is better than ranking on severity alone.

How often should I redo this ordering?

Whenever the picture changes materially, and on a regular schedule. A scan is a snapshot, so a ranking built from last month is out of date.

Secorvia keeps detection and triage as separate states, so a fix is not marked verified until a scan confirms it. See the triage guide and attack path analysis.