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.

400 critical findings

A scan comes back with 400 findings marked critical. Nobody has time to fix 400 critical anythings. 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.

Qualify with prejudice

My rule for a list like this: 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.

Peter Drucker said it better than I can: “There is nothing so useless as doing efficiently that which should not be done at all.”

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.

Is it real?

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.

Does it matter?

4. What would it cost if it went wrong? Money, customers, reputation, the regulator’s attention. The same flaw on a test box and on the system that moves customer money are not the same finding. The business knows.

Can we act?

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. 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.

Three critical findings land on the same morning.

The first is in a library on a server the platform team patches every month. Question 1 settles it in five minutes: the vendor already shipped the fix in an update the server got two weeks ago, and the version number never changed. It drops off the list.

The second is in a web app’s image upload code. Question 3 settles it: the app team turned that feature off last year, and the code never runs. It drops off the list too, with a note to remove the dead code.

The third is in a system that faces the internet, handles customer data, and has a flaw that threat intelligence says is being used in attacks this week. Questions 3 and 4 both say yes. Question 5 says the app team can ship a change by Thursday. Question 7 has a name on it. That one goes to the front of the line, and it gets the whole team’s attention, because the other two didn’t take any.

None of those three answers came from the security team. All three decisions did.

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.

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.

Picky needs the whole profile, early

A scan score is a bit like a profile photo. It’s the first thing you see, and it’s the worst case on purpose. The seven questions are the rest of the profile.

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.

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

The catch

Starting from “probably not” is only safe if the answers are good. If the platform team’s records are stale, question 1 gives you false comfort. If nobody checks whether a flaw is being used in the wild, question 3 can miss the one that matters most. A strong assumption with bad answers behind it is worse than no assumption at all.

So the answers have to be trustworthy, current, and easy to get. That’s exactly what’s hard today, because they live with other teams, in other systems, and nobody’s job is to hand them over. Which raises the next question: if we do share them, 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.

Clay first, chisel later.

Which of the seven is hardest to get answered where you work?