How to read a security report: a practical guide

The first reaction most people have when they receive a security scan report with 100 or 150 items is the same: panic, followed by "where do I even start?" The good news is most of those items require no action at all — they're controls that already passed, or informational observations. The real work is separating signal from noise.

What each field in the report actually means

Score. It's an aggregate rating — usually 0 to 100 — calculated from how many controls passed, how many failed, and how each is weighted by severity. A score of 75 doesn't literally mean "75% secure"; it means that, in that scanner's weighting, there are still meaningful gaps, but nothing critical left open (otherwise the score would drop much further).

Severity. Usually a scale like Critical → High → Medium → Low → Informational. It's the most important dimension for deciding order of fixes — not the number of items.

• Critical: active, immediate exploitation is plausible (e.g., an exposed secret, a publicly accessible database). Fix this first, always.
• High: a real vulnerability, but it takes more steps to actually exploit (e.g., missing CSP).
• Medium/Low: weakens the security posture, but on its own is rarely the vector of a successful attack.
• Informational: not a failure — it's collected data (detected technology, valid certificate) that helps the overall diagnosis.

Status. Passed, Failed, Observed, Inconclusive. "Observed" and "Inconclusive" are not failures — they generally mean the test didn't find a confirmed risk condition, or needs more context (authenticated access, for example) to reach a conclusion. Treating this as a confirmed vulnerability is a common mistake that wastes an IT manager's time fixing things that don't need fixing.

Evidence. The concrete snippet backing up the finding — the header that was missing, the exact value found. It's always worth reproducing the evidence before applying any fix: reports reflect the moment of the scan, and something may have already changed since then.

The right order to fix things

1. Critical first, no exceptions — even if it's just 1 or 2 items.
2. High, prioritizing whatever has the lowest risk of breaking something when fixed (e.g., adding a security header is usually safer to apply than changing an authentication configuration).
3. Medium, grouped by category — fixing all security headers at once is usually more efficient than going item by item in random order.
4. Low and Informational, when there's time left — they matter for the score, but not for real day-to-day risk.

Common mistakes when acting on a report

• Fixing by quantity, not severity. Closing 10 low-risk items feels like more progress than fixing 1 critical item — but real risk barely changes.
• Treating a "dependent failure" as an isolated item. Some findings only resolve after another one does (e.g., CSP quality depends on CSP existing in the first place). Fixing in the wrong order makes it look like the fix "didn't work."
• Not re-running the scan after fixing something. Without post-fix verification, you have a belief, not a confirmation — and headers and configurations have a surprising way of "coming back" after a future deploy.
• Applying everything at once in production. Security fixes can also break functionality (a poorly tuned CSP, for example). It's worth rolling out gradually, testing each change.

Score isn't the goal — it's the thermometer

The point of a security report isn't to "reach 100." It's to have real visibility into where the gaps are, to decide with information what's worth fixing now versus what can wait, and to track progress over time. A site that goes from 60 to 85 over a few weeks, fixing things in the right order, is in a much better position than one that tries to force a 100 score by fixing everything at once without understanding what each item actually means.

If you don't have a starting point yet, the security checklist for institutional sites covers the items that show up most often in this kind of report, even before running the first scan.