A customer’s procurement team has asked for “evidence of recent penetration testing”, the insurer’s form asks about “regular vulnerability scanning”, and the two phrases have started being used interchangeably in meetings. They are not the same thing. Each answers a different question, each has a different cadence and cost profile, and most organizations eventually need both. Knowing the difference lets you buy the right one for the right reason.
Two different exercises
What a vulnerability scan does
A vulnerability scan is automated. A scanning tool probes systems, whether from the internet, from inside the network or through an agent on each device, and compares what it finds against a constantly updated catalogue of known weaknesses: missing patches, outdated software versions, insecure configurations, default credentials, exposed services, expired certificates. It produces a ranked list of findings with severity ratings and suggested fixes.
Its strengths are breadth, repeatability and cost. It can cover every device, run on a schedule, and show whether last month’s findings were fixed. Its limitation is that it only knows what is in its catalogue. It cannot chain three minor issues into a serious compromise, it cannot judge whether a finding matters in your context, and it cannot think like an attacker. It is a smoke detector, not a fire drill.
What a penetration test does
A penetration test is human-led. A skilled tester, working within an agreed scope and rules, attempts to achieve a defined goal: reach the internal network from the internet, obtain administrative control of the domain, access a particular set of data. They use scanning tools as a starting point, but the value is in what happens next: reasoning about how weaknesses combine, trying approaches no tool would, and demonstrating real impact rather than theoretical severity.
The output is a written report describing what was attempted, what worked, how far the tester got, the evidence, and prioritized recommendations. Its strengths are depth and realism. Its limitations are that it is a snapshot in time, it covers only what was in scope, and it costs more because a person is doing the work. Our penetration testing engagements are scoped so that the goal reflects what would actually hurt the business, not just what is technically interesting.
Internal, external, and what “scope” means
Both scans and tests can be run externally, meaning from the internet against whatever your organization exposes, or internally, meaning from a position inside your network as if an attacker had already got in through a phishing email or a compromised laptop. External testing answers “what can a stranger reach?”; internal testing answers “how bad is it once someone is inside?” The second question is often the more uncomfortable one, and it is the one many organizations skip.
Scope and rules of engagement are the contract of a penetration test. They define which systems are in and out, what times testing may run, what techniques are permitted, whether social engineering of staff is allowed, what happens if the tester finds evidence of an existing compromise, and who to call if something breaks. A test without a written scope is a liability, not a test.
Reading the results without panicking
A first scan of any real network produces a long list, and severity ratings can be alarming out of context. The useful way to read the results is to ask three questions of each finding: is the affected system reachable by an attacker, does the weakness give them something they want, and is there a compensating control already in place? A critical rating on an isolated lab machine may matter less than a medium rating on the server that holds customer records. A penetration test report does this prioritization for you; a scan leaves it to whoever reads it, which is why scanning works best as part of a managed vulnerability management programme with a person interpreting the output.
Cadence and remediation
Scanning should be continuous or at least frequent, because new weaknesses are published constantly and every patch cycle changes the picture. The realistic measure of a scanning programme is not how many findings it produces but how quickly the important ones are closed and whether they stay closed. Penetration testing is periodic: typically once a year for many organizations, and after significant change such as a new internet-facing application, a cloud migration or an office move. Retesting after remediation, to confirm the fixes actually worked, is part of a proper engagement.
When each is required
Insurers commonly ask about regular vulnerability scanning and about how quickly critical findings are fixed. Larger customers, especially in regulated sectors, often ask for evidence of penetration testing before onboarding a supplier, and some payment and industry frameworks require it explicitly. If a requirement lands, read the wording carefully: “vulnerability assessment” and “penetration test” are different deliverables, and providing the wrong one wastes money and delays the contract. A broader network security assessment often bundles scanning, configuration review and a targeted test into a single exercise for organizations starting from scratch.
Common questions
Is a vulnerability scan the same as a penetration test?
No. A vulnerability scan is an automated check of systems against a catalogue of known weaknesses, producing a ranked list of findings. A penetration test is a human-led attempt to achieve a defined goal, such as reaching internal systems, by combining weaknesses the way a real attacker would. Scans are broad, frequent and inexpensive; tests are deep, periodic and require skilled people.
How often should we run vulnerability scans?
Frequently enough to catch new weaknesses soon after they are published and to confirm that patches were applied. For most organizations that means continuous or at least monthly scanning of internal systems and internet-facing services, with critical findings addressed on a short, defined timeline. What matters is the remediation cadence, not the scan count.
How often is a penetration test needed?
Many organizations test annually, and additionally after significant changes such as launching a new internet-facing application, migrating to the cloud or restructuring the network. Customer contracts, insurers and industry frameworks may set their own expectations. A retest after remediation confirms the fixes worked and is usually part of a well-run engagement.
Should a small business start with a scan or a test?
Usually a scan, or a network security assessment that includes one, because it finds the obvious gaps quickly and inexpensively, and fixing those first makes a later penetration test more valuable. Testing a network with unpatched systems produces a predictable result. Once the basics are in place, a scoped penetration test shows what a determined attacker could still achieve.
If you have been asked for one and are not sure which, our vulnerability management, penetration testing and network security assessment pages describe how each is scoped and delivered, and you can contact us to match the right exercise to the requirement in front of you.
