What does a vulnerability assessment do?
A vulnerability assessment helps a business understand where weaknesses exist and which should be addressed first. It can examine software, exposed services, configuration and other security controls. The result should explain affected assets, supporting evidence, severity, limitations and recommended action, rather than simply deliver a file of scanner alerts.
An external assessment considers the systems reachable from the internet. An internal assessment starts from an agreed position within the organisation. The word “vulnerability” does not determine that starting point: a buyer should confirm whether the work covers public infrastructure, internal networks, applications or a defined combination.
For example, a review might establish that a remote access service is unnecessarily exposed or that a server appears to use affected software. Those are useful findings even when actively exploiting the weakness would add little value or create disproportionate risk. Our External Vulnerability Assessment page explains the internet-facing service scope.
What does a penetration test do?
A penetration test uses an adversarial approach to investigate attack paths within agreed boundaries. The tester may try to cross an access boundary, combine several weaknesses or demonstrate a permitted effect using test data. The objective is evidence about exploitability and consequences, not disruption or unrestricted access.
The scope determines what can be demonstrated. A test of a customer portal may examine whether one test user can access another test user’s records. A network engagement may examine whether an agreed foothold permits movement to a protected system. Neither scenario is automatically included just because the engagement is called penetration testing.
Some findings can be validated without completing every possible attack step. If a safe proof already establishes the control failure, obtaining more data or extending access may be unnecessary. A report should distinguish observed impact from further consequences that remain plausible but untested.
The practical differences at a glance
These are typical emphases, not rigid product definitions. Both activities can use automation and manual work, and both need interpretation. Ask the provider to describe the actual methods and deliverables.
| Consideration | Vulnerability assessment | Penetration testing |
|---|---|---|
| Main question | What weaknesses are present and how should we prioritise them? | Which agreed attack paths are viable, and what impact can be demonstrated? |
| Typical approach | Discovery, vulnerability checks, configuration review and validation | Targeted investigation, controlled exploitation and examination of connected weaknesses |
| Evidence | Affected assets, observations, verification and contextual risk | Prerequisites, repeatable control failures and bounded evidence of impact |
| Coverage trade-off | Often seeks breadth across the agreed estate | Often spends more time exploring selected paths in depth |
| What neither guarantees | An exhaustive inventory of every possible flaw | Proof that no other route to compromise exists |
Why scanning and human validation both matter
Automated tools make repeated checks and broad discovery practical. They can identify exposed services, detect certain configuration issues and compare observations with known vulnerability information. Their coverage depends on reachability, permissions, supplied credentials, supported technologies and the checks enabled.
An alert is a lead to investigate. A reported software version may not establish that a particular flaw is exploitable in the deployed configuration. Conversely, a clean scan does not prove that business rules or user permissions are correct. Those questions may require knowledge of the application and tests using more than one role.
Human validation should improve the confidence and usefulness of the result. It may confirm affected functionality, review configuration, safely reproduce a behaviour or explain why an alert does not apply. It does not require harmful exploitation of every reported issue. NIST’s technical testing guide describes different assessment techniques and their limitations; it is a methods reference, not a UK legal testing schedule.
Hypothetical example
A fictional business has a supplier portal containing synthetic order records. Consider two different questions about that same environment.
- Assessment question: which public services and software configurations need attention? An assessment identifies an unnecessary administration interface and verifies its exposure.
- Penetration-test question: can a supplier account access another supplier’s orders? An explicitly authorised test uses two test accounts and synthetic records to establish whether the server checks ownership.
- Evidence: the report records the intended permission rule, relevant account roles and observed result. It separates the confirmed test-record disclosure from any untested production-data impact.
- Action: restrict the administration interface and correct the record-level authorisation control. Retest both changes, including legitimate supplier access.
A service scan alone may not reveal the order-ownership failure. A portal penetration test may not inventory every public server unless that coverage is included. Combining appropriately scoped activities answers both questions without pretending either engagement covers everything.
Which service should your business choose?
Start with the decision the report must support. A board seeking an overview of exposed infrastructure needs different evidence from an engineering team preparing to launch a sensitive customer workflow.
- You lack a reliable view of exposed systems: begin with discovery and an assessment of the agreed assets. Confirm ownership before testing unexpected systems.
- You need to understand whether controls can be bypassed: consider a targeted penetration test with realistic roles, scenarios and impact limits.
- You have many known, unaddressed weaknesses: prioritise remediation alongside testing. Repeatedly documenting the same issues does not reduce exposure.
- You are launching or materially changing a service: combine relevant baseline checks with deeper testing of the changed functionality and its trust boundaries.
- You need evidence that fixes work: commission a defined retest of the relevant findings, rather than assuming a completely new broad assessment is necessary.
Cost comparisons are meaningful only when the scope, depth, access and deliverables are comparable. Asset counts alone do not capture the complexity of user roles, business workflows or network relationships. A less expensive engagement may be suitable for a narrow question; it should not be mistaken for wider assurance.
Agree the scope before comparing proposals
Record the domains, systems, applications and environments included, the test starting point, available accounts and exclusions. Decide whether testing is authenticated, unauthenticated or both. An authenticated review can reveal information unavailable from the public interface, but its permissions and handling requirements need to be agreed.
All testing requires explicit written authorisation and rules of engagement. Set test windows, permitted actions, data-handling requirements, escalation contacts and stop conditions. Identify third-party assets and obtain the necessary permissions rather than assuming that ownership of a website authorises testing every connected provider.
Ask how the provider handles discoveries outside the original scope. The sensible response is to record and clarify them, not silently expand activity. Also agree how urgent findings will be communicated during the engagement: waiting for the final report may leave an avoidable exposure unresolved.
What useful evidence and reporting should include
A technical finding should describe the affected component, prerequisites, observations and recommended correction. Severity should reflect the technical characteristics and relevant business context. A numerical score or alarming label alone does not explain whether a system is reachable, what information is affected or which existing controls limit the risk.
Decision-makers also need an executive summary, scope and coverage statement, prioritised actions and clear limitations. Ask whether findings were confirmed, inferred from available evidence or left unverified for safety reasons. This distinction makes the report more useful, rather than less credible.
For procurement, agree who will receive the report, how sensitive evidence will be protected and whether a technical readout is included. Clarify whether remediation advice and retesting are included in the engagement or separately scoped. Do not assume that an assessment provider will implement changes to your systems.
How the two activities work together after remediation
An assessment can provide a baseline, help prioritise fixes and identify areas for deeper investigation. Penetration testing can then examine selected high-consequence paths. Results from either should feed the same remediation process, with owners, agreed priorities and a record of unresolved risk.
Retesting checks whether a correction addresses the finding under relevant conditions. It should confirm that the original failure is prevented and that necessary legitimate functionality still works. Where appropriate, include related roles, adjacent endpoints or configuration variants to avoid closing an issue fixed in only one place.
Keep closure evidence and record partial fixes honestly. Security Retesting & Validation can support this process. A successful retest closes the tested question; it is not a permanent guarantee about the whole environment.
Frequently asked questions
Is vulnerability assessment just automated scanning?
No. Scanning can support discovery and checking, but a useful assessment also evaluates relevance, prioritises findings and explains remediation. Confirm the degree of validation and analysis included.
Does penetration testing always include a vulnerability assessment?
It may include discovery and vulnerability checks, but it does not automatically provide a comprehensive assessment of every asset. Compare the written coverage rather than assuming one service contains the other.
Do we need both?
Sometimes. They complement each other when you need both broad weakness identification and deeper evidence about selected attack paths. One well-defined activity may be enough for a narrower decision.
Can testing affect live systems?
Yes, poorly controlled testing can affect availability or data. Agree safe methods, test accounts, limits and stop conditions, and use representative non-production systems where practical.
Which should happen first?
If basic exposure and known weaknesses are poorly understood, an assessment can establish priorities. A critical application release or specific control concern may justify targeted penetration testing sooner.
Does a clean report mean we are secure?
No. Results reflect the agreed scope, access, methods and time of testing. Maintain remediation, change management and further assessment appropriate to the risks.
AUTHORISED SECURITY TESTING
Choose testing around the question you need answered.
Discuss the systems, evidence and business decision involved. We can help define an authorised scope across our security testing services.
Compare the wider SabreShield cybersecurity testing services.