Seven questions

Part 1 ended on a claim: the information a good decision needs comes down to about seven questions, and the answers are spread across more people than you’d think. This is those seven questions.

48,000 critical findings

Add up every scanner you run across 1,200 apps, the long-standing ones and the newer AI-driven ones, and you get 48,000 findings marked critical. They don’t land on one person. They land on dozens of teams that already have full-time jobs: designing and building, deciding what to build next, watching how it’s used, keeping it running. Every finding pulls someone away from that work, and the context switching adds up fast. And most of them aren’t critical, not for you, not today. The trouble is that the scan can’t tell you which ones are.

So the usual move is to start at the top and work down, as fast as you can. That feels responsible. It’s also the most expensive way to find out that most of the list didn’t matter.

Picky needs the whole profile, early

A severity score is a bit like a profile photo: it’s the first thing you see. Except here, a high number isn’t flattering. On a 0 to 10 scale, a 9.8 means the scanner assumed the worst: anyone can reach it, it’s easy to use, and nothing stands in the way. That’s the right default when you know nothing else. The seven questions are the rest of the profile, and they’re how you find out whether the worst case is your case.

Being picky only works if that profile shows up at the first look, not weeks later in a spreadsheet. When an answer is missing, the honest move isn’t to assume it’s fine. It’s to go ask. And the more findings sit waiting on answers, the slower the whole list moves.

So get the answers you can right away, starting with the cheap ones. Then make the call early, with the facts in hand and a simple, written-down way of deciding, a model or even a plain decision tree, so the same facts get the same answer every time.

That’s the bet from part 1 again. Share earlier, so decisions are informed from the first look.

Qualify with prejudice

When I was CTO and CISO at the same time, I had one rule for a list like this, and I still use it: qualify with prejudice. Start from “probably not.” Every finding has to earn its place on the list before anyone spends a day on it. Work the ones with the most impact first, and get the pile as small as you honestly can before you start working it.

If you came up in security, that probably sounds backwards. Most of us were taught the opposite: assume it’s exploitable until someone proves it isn’t. That instinct is a good one, and when you know nothing else, it’s still the right default. But it was built for a list you could actually work through, and 48,000 findings isn’t that list anymore. Both rules want the same thing: nothing that matters left open. Starting from “probably not,” and then doing the work to make that safe, gets you there faster. The rest of this piece is that work.

Peter Drucker said it better than I can.

Prejudice here means a strong starting assumption, not a closed mind. The evidence can overturn it, and when it does, that finding goes to the front of the line. And it doesn’t take the decision away from security. Security still makes the call. It just makes it with the answers in hand.

The seven questions

In my experience, a good decision about a finding needs answers to seven questions. They fall into three groups: is it real, does it matter, and can we act. Next to each one is who usually holds the answer.

1. Has it already been fixed? A vendor can fix a flaw in the exact version you run without changing the version number. On paper it still looks vulnerable. Platform teams and vendors know.
2. Is something already blocking the way in? Another control may already stop it: a setting, a firewall rule, a feature that’s turned off. Platform and network teams know.
3. Can anyone reach it, and is anyone trying to? Code that never runs. A door nobody can get to. A flaw nobody is using yet, or one that’s being used right now. App teams and platform teams know the first part. Threat intelligence knows the second.

4. How sensitive is it, if it’s exposed or if it’s down? Sensitive in two ways. Exposed: the money, the customers and the data it can reach (not just what it stores), and the regulator’s attention. Down: who depends on it, inside the company and out, whether their work can wait, and when it matters most. The same flaw on a test box and on the system that moves customer money at month-end are not the same finding. The business knows, with the data owners and operations.

5. Can we change it safely, and how fast? Some systems can take a change today. Some can’t move without months of testing, and some can’t move at all. This is also the most expensive question to ask. It pulls a team off their work to size a fix that doesn’t exist yet, and the answer is a guess until they try. So save it for the findings that have earned it. App teams and operations know.
6. Should we retire it instead? Sometimes the best fix is turning it off. The business and the app owner know.
7. Who would actually do the work? If nobody owns it, it doesn’t get fixed, no matter how critical it is. The org chart knows, sort of.

Look at where the answers live. Almost none of them are in the security team. That’s not a knock on security. It’s the point of the whole series. The decision sits with one team, and the facts it needs are scattered across five.

A made-up example

Here’s what that looks like. This example is invented, but I suspect it’ll look familiar.

Four critical findings land on the same morning.

OpenSSL → Question 1 settles it in five minutes: ↓ the vendor backported the fix two weeks ago, and the version number never changed. It drops off the list.

Management port → Question 2 settles it: ↓ a firewall rule only lets the admin network in. It stays mitigated, as long as the rule does.

Redis client library → Question 3 takes the urgency out: ↓ the service doesn’t call the flawed function today. But ↑ the code is still there, and the next change could call it. So it gets upgraded in the next normal release. A plan, not a fire drill.

Front-end library → ↑ It faces the internet, ↑ customer accounts sit behind it, and ↑ it’s being used in attacks this week. Only now is question 5 worth asking, because asking it isn’t free. The app team stops, looks, and comes back with a targeted patch by Thursday. It goes to the front of the line, with the whole team’s attention, because the other three didn’t take any.

The order matters

Notice which questions did the work. The cheap ones went first. Has it been fixed, is something blocking it, can anyone reach it: those are mostly lookups, if you know where to look. The expensive ones, like what it would cost and who would do the work, need people in a room. You only want to spend that time on findings that survived the cheap questions. The most expensive one, how fast can we change it, is like asking engineers for an estimate: don’t, until you know the thing is worth doing.

That’s qualifying with prejudice in practice. Most findings fall out at the first three questions. The few that are left get real attention, faster.

The catch

Garbage in, garbage out. → Starting from “probably not” is only safe if the evidence holds up. Stale platform records make question 1 false comfort. A strong assumption on weak evidence is worse than none.

Evidence, not someone’s word. → The evidence has to be trustworthy, current, easy to get, and checkable. And sharing it doesn’t hand off the responsibility. The other teams supply the evidence. Whoever makes the call still owns it.

Keep the receipts. → Every answer should leave a trail: what it was, where it came from, who gave it, and when. That’s how whoever made the call can show what it rested on, and how you find out later which sources were wrong.

Make the toil visible. → Today the work hides behind “we’ve been chasing a ton of false positives.” A trail turns that into numbers: how many findings came in, how many each question settled, how long each answer took, and how often a “probably not” turned out to be wrong.

Nobody’s job, yet. → That’s exactly what’s hard today, because the evidence lives with other teams, in other systems, and nobody’s job is to hand it over. Which raises the next question: if we do share it, who gets to see what, and who gets to act on it? That’s part 3.

Where to start

Don’t boil the ocean. Pick one kind of decision, say critical findings on internet-facing systems. For each of the seven questions, write down who holds the answer where you work, and how long it takes to get it today. Then build a rough first version together.

And treat it as never done. Keep adding data where the decisions are weakest, keep tuning the model when it gets one wrong, and keep checking the sources themselves: how fresh they are, how complete, how often they turn out to be wrong. A source that has quietly gone stale is worse than one you know is missing.