Blog · Assessment and scoring
External security assessment vs penetration testing
Both produce a document with findings in it, which is why they get confused in procurement conversations. The difference is what a tester is allowed to do, and what question the engagement is answering.
The short version
- An external assessment checks whether the outside is configured correctly. A penetration test tries to break in.
- A penetration test needs written authorisation and a scope document before anything happens. Unauthorised testing is not testing.
- An assessment is repeatable and cheap enough to run quarterly; a pentest is an event, usually annual or change-triggered.
- Neither replaces the other, and one report should never be presented as the other.
The distinction is easiest to hold onto as a question. An external assessment asks: is this configured the way it should be, and can anyone see otherwise? A penetration test asks: given a motivated person and permission to attack, can they get in? The first is breadth. The second is depth.
Side by side
| External posture assessment | Penetration test | |
|---|---|---|
| Goal | Measure configuration against a fixed catalog | Demonstrate whether an attacker can achieve an objective |
| Access | Public requests only; no credentials | Whatever the rules of engagement allow, often including credentials |
| Technique | Read records, negotiate TLS, inspect headers, check reachability | Exploit, chain, escalate, pivot, sometimes deceive |
| Output | Status per control with the observation quoted | Narrative of what was achieved, with proof and impact |
| Authorisation | Still required, but limited to public observation | Written scope, rules of engagement, testing windows, emergency contacts |
| Cadence | Quarterly, or after infrastructure changes | Annually, before a launch, or after a significant change |
| Blind spots | Application logic, authentication, internal network | Coverage depends on scope and time; usually a snapshot |
Why the confusion exists
Three reasons. Both produce "findings". Both are sold by the same kinds of provider. And many vendors describe automated configuration checks as "penetration testing" because the phrase carries more weight with a buyer who has one line item for security.
That inflation is not harmless. A business that believes a header scan was a penetration test skips the engagement that would have found the authorisation bug in its customer portal. A business that believes a pentest covers its email spoofing exposure gets a clean report and no DMARC record.
What a penetration test finds that an assessment never will
- Broken access control: one customer reading another's invoice by changing an ID.
- Authentication weaknesses: password reset flows, session fixation, token handling.
- Business logic abuse: refunds, discounts, workflow bypasses.
- Chained exploits where each step is unremarkable and the combination is not.
- Insider and social engineering paths, if that is in scope.
None of that is visible to an anonymous request, which is exactly why an assessment cannot claim to cover it.
What an assessment does that a pentest will not
- Cover every domain you own, not just the one in scope, for roughly the effort of one.
- Detect drift: the DMARC record that was tightened and then quietly loosened six weeks later.
- Produce a comparable number each quarter, so a trend exists at all.
- Give a non-specialist a starting point that does not require reading an exploit write-up.
Drift is the underrated half. Most small business exposure is not a clever attack; it is a control that was correct in March and is not in September, because someone changed a DNS host or renewed a certificate through a different provider.
When you need which
| Situation | Start with |
|---|---|
| No one has ever looked at your external configuration | Assessment — it is the cheapest place to find the boring, high-consequence gaps |
| Taking payments or handling customer accounts in a new application | Penetration test before launch, assessment on the domain |
| A customer or insurer asks for evidence of security testing | Depends on what they specified; read the requirement rather than guessing |
| You changed hosting, DNS provider or mail platform | Assessment, to confirm nothing regressed |
| You suspect a specific incident | Neither: incident response, in that order of urgency |
What the two artefacts actually look like
The formats differ as much as the methods. Illustrative shapes below, not real engagements:
| Assessment finding | Penetration test finding |
|---|---|
16 Content-Security-Policy — warningEvidence: header absent on the static response. Action: publish a policy in report-only mode, then enforce. |
“Access control bypass in invoice view” Method: changed an object identifier in the request. Impact: a second customer's invoice was readable. Screenshot and request attached. |
The first can be fixed in a deployment and re-checked with one command. The second cannot be found by any amount of header inspection, and cannot be fixed without changing application code. Both are useful; neither substitutes for the other.
Authorisation is not a formality
A penetration test without written authorisation is not a penetration test, it is an attack with a report attached. Scope, testing windows, excluded systems, data handling and an emergency contact belong in a document both sides sign before the first packet. It is also why "we ran a pentest on a supplier's portal to see" is a bad idea regardless of intent — see responsible use.
An external assessment sits at the low end of that spectrum: it reads what you publish and makes ordinary requests. Authorisation is still the right starting point, and this project records consent before a scan of any kind. That is a design decision, not paperwork.
How they fit together
The pattern that works for a small business is a cadence, not a purchase: an external assessment each quarter as a baseline and a drift check, and a penetration test when the application changes materially, before a launch, or annually if a customer or insurer requires it. Findings from either should end up in the same register, with an owner and a date, or neither will be fixed.
If you want the method behind the assessment half, it is published in full: methodology, the catalog, and what the method cannot establish.
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.