How to read your SMB Scanner Lite report

The published example is a recorded capture of example.com, a reserved IANA test domain. Its report ID is SMB-SANDBOX-20261028-A91144E4, the capture is timestamped 28 October 2026 at 17:25 UTC, and the result is 86/100, grade B. Everything below refers to that document, which is available in full under sample report and as HTML, JSON, CSV and TXT downloads.

1. The metadata block

Before the score, read the header. It answers the questions that decide whether the numbers mean anything.

• Target and scope. Exactly one hostname and the records published for it. Not "the company".
• Timestamp. A DNS record has no history; a report is a photograph. The date is part of the finding.
• Vantage. Where the observation was made. A record can resolve differently for a different resolver, and a firewall can answer one network and drop another.
• Policy version and edition. This capture is from the Public Sandbox Edition, which runs a read-only subset of the catalog against five allowlisted domains. That is why the counts below say eight completed rather than twenty-two.
• Consent record. A receipt hash, consent ID and policy version. In this capture it is CONSENT-20261028-A91144E4. It exists so that "who authorised this scan" is answerable after the fact.

2. The score, and the arithmetic under it

86/100 maps to grade B on the published bands: A is 90–100, B 80–89, C 65–79, D 50–64, F below 50. The score is a weighted mean over the controls that reached a conclusive status, where each control carries a weight from 1 to 5 and pass earns full credit, warning earns partial credit, fail earns none.

Notice what the category table does that the headline number cannot: it tells you where the remaining points are. Here, 86 overall with headers at 68 names the work to be done, and it is small.

3. Status and counts

Check the counts line before anything else: eight completed, zero inconclusive. Zero inconclusive is what makes this score interpretable, because inconclusive results are excluded from both the numerator and the denominator. A report that says 100/100 over two completed controls is not a good result; it is a narrow one.

In this capture, six controls pass and two warn. The two warnings are worth reading in full because they show how the report argues:

15  Strict-Transport-Security   warning
    Strict-Transport-Security header not enforced on reference landing page.

16  Content-Security-Policy     warning
    Content-Security-Policy header absent on static reference response.

Both are ordinary for a minimal reference site, both are fixable in a header configuration, and neither is presented as a catastrophe. That proportionality is deliberate: a warning is not a pass with nicer language, and it is not a breach.

4. Reading evidence like a sceptic

Each finding carries the observation that produced it, in a form you can re-run:

$ dig +short TXT example.com
"v=spf1 -all"

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"

The SPF record above is a strict no-mail policy, which is correct for a reserved documentation domain. That is exactly the kind of judgement an evidence-first report has to make explicitly: the same record on a business domain that sends invoices would be a finding, not a pass. Method notes should say so, and ours does on methodology.

5. A triage order that respects weight

1. Fails on weighted controls. DMARC enforcement, certificate validity, remote desktop and high-risk ports. Fix first, verify the same day.
2. Warnings on weighted controls. A soft SPF qualifier, a short HSTS max-age. Usually one configuration change.
3. Fails on light controls. Referrer or permissions policy. Batch these into the next deployment.
4. Inconclusive. Not a task for you; check whether the vantage or a firewall explains it before treating it as either.

6. What to do in the first week

Give every finding an owner and a date, and paste the evidence into the ticket. Then re-run the same query that produced the evidence and confirm the fix at the same vantage — a fix verified from inside the network is not verified. Keep the JSON export; it is the artefact that makes next quarter's comparison possible, and it is the one file in the pack that a script can read.

7. Red flags in any report, including this one's genre

• A score with no method, no weights and no way to recompute it.
• Findings without an observation: "weak TLS configuration" and nothing else.
• No timestamp, no scope, no statement of vantage.
• No limitations section. Every method has limits; a report that claims none is selling.
• "100% secure" or a guarantee against breach. No external assessment can offer one, and the limitations page says where this one stops.

If a report fails three of those, the number in it is decoration. If it passes them, you can disagree with a finding and still use the document — which is the whole point of writing down the observation instead of the conclusion.

What SMB Scanner Lite checks here

These are the controls from this area that the assessment evaluates from outside, without credentials and without touching anything private. Each one returns a status and, for every conclusive result, the record, header or handshake that produced it.

Only assess domains you own or are authorised to test — see responsible use. The published recorded assessment shows how a result and its evidence appear in a report, and the control catalog lists all 22 controls with their weights. Reference detail for this topic lives in External security posture assessment: what it measures.