Blog · Assessment and scoring
What is a security posture assessment?
The phrase gets used for everything from a questionnaire to a full red-team engagement. Here is the narrow, defensible version: a fixed catalog of externally observable controls, each with a status and an observation behind it.
The short version
- A posture assessment measures configuration that is visible from outside, on a repeatable catalog, and reports a status per control.
- It is not a penetration test, a code review or a compliance audit — and it should say so in the report.
- The value comes from comparison over time, which requires the same scope, the same vantage and a published method.
- Ask any provider what is excluded. A method with no stated limits is marketing.
In a meeting, "security posture assessment" usually means "someone looked at our security and gave us a number". That is not a method, it is a deliverable. The useful definition is narrower: a repeatable evaluation of a fixed set of controls, performed from a defined vantage point against a defined scope, with a recorded observation supporting each result.
Each part of that sentence is doing work. Repeatable means next quarter's result can be compared with this quarter's. Fixed set of controls means the score cannot be moved by measuring different things. Defined vantage means "the firewall blocks us" is an observation, not a mystery. Recorded observation means you can check the finding without trusting the person who wrote it.
What an external assessment can measure
The catalog behind SMB Scanner Lite has 22 controls in five categories. This is what "external" means concretely: DNS records, mail policy records, a TLS handshake, HTTP response headers, and whether specific high-risk services answer.
| Category | Controls | Examples |
|---|---|---|
| DNS and domain integrity | 5 | DNSSEC chain, CAA authorisation, zone transfer, name record hygiene, address resolution |
| Email authentication | 5 | SPF strength and validity, DMARC enforcement, DKIM presence and key strength, MX posture |
| Transport security | 4 | Protocol versions, certificate validity and coverage, cipher suites, HTTPS redirect path |
| Browser security headers | 4 | HSTS, CSP, framing and MIME-sniffing protection, referrer and permissions policy |
| Network and service exposure | 4 | High-risk ports, SMB, remote desktop, database and admin interfaces |
Two of those categories are the ones worth acting on first in most small businesses, and neither requires a budget: a domain that anyone can forge, and a remote desktop port open to the internet, are the two findings that most often turn out to matter.
Four statuses, and why the fourth matters
| Status | Meaning | Credit |
|---|---|---|
| Pass | The control met its expectation, and the observation is quoted | Full |
| Warning | Present but weaker than it should be — a soft SPF qualifier, a short HSTS max-age | Partial |
| Fail | Absent, invalid or actively unsafe | None |
| Inconclusive | The check could not reach a conclusion: timeout, blocked, or an ambiguous answer | Excluded |
That fourth status is where most assessment tools quietly cheat. Counting "could not tell" as a failure punishes a firewall for doing its job; counting it as a pass rewards silence. Removing it from the calculation and reporting the count separately is the honest option, provided the report shows how many controls actually ran.
Why evidence changes the conversation
A finding without an observation is an opinion. With one, it is a task: here is the TXT record we received, here is the header that was missing, here is the certificate chain and the hostname it covers. Anyone can re-run the query from outside the network and compare. If the answers disagree, the finding is stale or vantage-specific — and that is a legitimate result rather than a broken tool.
It also changes what happens after the report. A developer can verify the problem without asking permission, and a manager can verify the fix without commissioning a second assessment.
In the published recorded assessment, one finding reads like this:
15 Strict-Transport-Security warning weight 4
Evidence: Strict-Transport-Security header not enforced on reference landing page.
Recommended: send HSTS with max-age of at least one year over HTTPS only.
That is the whole argument: a status, the observation behind it, and the change that would clear it. A reader who disagrees can fetch the headers and say why, which is a better conversation than one about a score.
What it is not
- Not a penetration test. Nothing is exploited, no application logic is tested, and no credentials are used. The comparison covers this properly.
- Not a code review or a vulnerability scan of your application. A missing authorisation check on an invoice page is invisible from outside.
- Not a compliance audit. Frameworks ask whether a control exists and is documented; they do not usually check whether your SPF record is valid today.
- Not a guarantee. A high score means the measured controls met their expectations. It says nothing about the parts nobody measured.
Eight questions to ask before you buy one
- What exactly is in the catalog, and how many controls does it contain?
- How is each status assigned, and is the rule published?
- What does the score weigh, and can I recompute it from the report?
- Will I get the raw observation behind each finding, or only a severity label?
- What is explicitly out of scope, in writing?
- Does it need credentials or any access beyond a public request?
- Can I re-run it on the same scope at a known interval, and compare results?
- Who is allowed to be scanned, and how is authorisation recorded?
The answers to those eight questions separate a method from a dashboard. Ours are answered on the methodology page, with the boundary written down on limitations — and the catalog itself is browsable under capabilities.
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.
| Control | What is evaluated |
|---|---|
| 22 controls, five categories | DNS, email authentication, TLS, browser headers and service exposure, each weighted 1-5. |
| Four statuses | Pass, warning, fail and inconclusive, with inconclusive excluded from the score rather than counted as failure. |
| Evidence on every finding | The record, header or handshake that produced the result, quoted so it can be re-checked. |
| Grade bands | A 90-100, B 80-89, C 65-79, D 50-64, F below 50, applied to the weighted mean. |
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.