Penetration Testing and Vulnerability Scanning Explained

By Grocito14 October 2026

A vulnerability scan is an automated check that looks for known weaknesses across your systems, while a penetration test is a scoped, human-led attempt to exploit weaknesses the way an attacker would. Scans are cheap and repeatable, so they suit regular use. Penetration tests find chained and logic flaws that tools miss, so they suit launches, major changes and contract requirements.

Key takeaways

Scanning, penetration testing, code review and bug bounty programmes answer different questions; most businesses need a mix, not one of them.
Automated scans find known issues quickly but cannot judge business logic. Human testers find how small weaknesses combine.
Test before launch, after major changes, on a regular rhythm and whenever a customer or contract asks for it.
A good test starts with written scope, written authorisation and clear rules of engagement.
The value is in the fixing: a report is only useful if findings are fixed, retested and tracked.
Never test a system you do not own or do not have written permission to test.

What is the difference between vulnerability scanning and penetration testing?

The two are often sold under the same label, which causes disappointment on both sides.

Vulnerability scanning

A scanner is software that checks your websites, servers and network services against a database of known weaknesses, such as outdated software, missing security headers, exposed services and weak configurations. It is broad, fast and repeatable. It produces a long list, some of which are false alarms, and it cannot tell which findings actually matter for your business.

Penetration testing

A penetration test, or pen test, is carried out by a person (usually with tools) who tries to get in. They validate which weaknesses are real, combine small issues into a bigger one, and show what an attacker could reach. For example, a harmless-looking information leak plus a weak password reset might together expose customer accounts. A scanner would list the pieces separately and miss the story.

Code review and bug bounty

A code review reads the source code for security mistakes, which finds problems a black-box test cannot see, such as unsafe handling of secrets. A bug bounty invites outside researchers to report problems in return for a reward. It can work for mature products with a team ready to triage reports, and it is a poor starting point for a business with no security process yet.

What does each approach find and miss?

Scanning finds: outdated components, known flaws, expired certificates, open ports, missing hardening. It misses: logic flaws, broken access control between users, and anything needing human judgement.
Penetration testing finds: exploitable chains, authorisation mistakes, weak business logic, poor session handling. It misses: anything outside the agreed scope or the time window, and it is a snapshot, not a permanent state.
Code review finds: insecure patterns, hard-coded secrets, unsafe dependencies. It misses: problems that only appear in the live configuration.
Bug bounty finds: a wide variety of issues from many perspectives. It misses: whatever researchers find unrewarding, and it depends on your ability to respond.

No single method covers everything, which is why layering them is sensible.

When does a business need each one?

Before launch. A new website, app or API deserves a test before real customer data arrives, while changes are still cheap.
After a major change. A new payment flow, a login redesign, a migration or a new integration changes your attack surface.
Regularly. Scans can run on a schedule, and many teams plan a penetration test on a rhythm that fits how fast the product changes.
For customer or contract requirements. Larger customers, insurers or partners may ask for evidence of testing. Ask them what form of evidence they expect.

If you are small and have limited budget, start with the basics in our website security checklist for business owners and, if you expose an API, work through the API security checklist for business applications before paying for a deeper test.

How do you scope a penetration test?

Scope is the most important decision. Write down:

What is in scope: named domains, applications, APIs, environments (ideally a staging copy with realistic data, plus a limited production check).
What is out of scope: third-party services you do not control, and anything fragile.
Rules of engagement: testing windows, who to contact if something breaks, whether denial-of-service style tests are allowed, how found data is handled and stored.
Written authorisation: a signed document from someone with authority over the systems. If your hosting or cloud provider has its own testing rules, check them first.

Black, grey and white box in plain terms

Black box: the tester knows nothing beyond what an outsider would. It mimics a real attacker but spends time on discovery.
Grey box: the tester has ordinary user accounts and some documentation. This is usually the best value for web apps because time goes into the features that matter.
White box: the tester also sees the source code and architecture. It is the most thorough and finds the most.

What should a good report contain?

Ask to see a sample report before you buy. Look for:

An executive summary that a non-technical manager can understand.
A clear severity rating for each finding, with an explanation of how it was judged.
Evidence, such as screenshots or request details, so your team can believe and verify it.
Reproduction steps, so a developer can see the issue for themselves.
Fix guidance that is specific to your technology, not a generic paragraph.
A scope and methodology section stating what was tested and what was not.

A report that is a pasted scanner export with a cover page is a warning sign.

How do you choose a tester?

Ask about qualifications and experience, and ask who will actually do the work.
Ask for references from comparable projects.
Ask which methodology they follow. Testers commonly structure web testing around OWASP guidance, and a good one can explain how.
Insist on written authorisation and a confidentiality agreement before any testing starts.
Ask how findings are delivered, whether a debrief call is included and whether retesting after fixes is part of the price.

Fixing, retesting and handling results responsibly

Triage findings with the tester. Fix the severe ones first.
Assign each fix to a named owner with a target date.
Ask for a retest of the fixed items, and keep the evidence that they were closed.
Store the report securely. It is effectively a map to your weaknesses, so share it only with people who need it.
Feed lessons back into how you build, for example by adding checks to your CI/CD pipeline.

Reduce what tests will find

Testing is cheaper and more useful when the basics are in place: apply updates promptly, remove unused accounts and services, give people the minimum access they need (least privilege), enforce multi-factor authentication, back up and monitor. Our DevOps services cover automation of patching, scanning and deployment checks if you want help.

A worked example

Imagine a small online training company about to launch a student portal. Its developers run an automated scan weekly, which catches an outdated library. Before launch, the company commissions a grey-box penetration test with signed scope covering the portal and its API. The tester discovers that a student can change a number in a web address and view another student's certificate. The scanner could never have found that. The developers fix the access check, the tester retests, and the company keeps the report for a larger customer who later asks for evidence of testing.

FAQ

Is a vulnerability scan the same as a penetration test?

No. A scan is automated and looks for known weaknesses. A penetration test is led by a person who tries to exploit weaknesses and combine them, which finds logic and access-control problems that scanners usually miss.

How often should a small business do a penetration test?

There is no single rule. A sensible approach is to scan regularly, test before launching something new, test after major changes and test when a customer or contract asks for it.

Can I run a penetration test on any website?

No. Only test systems you own or have clear written permission to test. Testing someone else's system without authorisation can be illegal, even if your intentions are good, and laws vary by country.

What should I do with a penetration test report?

Triage the findings, fix the serious ones first, then ask for a retest and keep the evidence. Store the report securely and share it only with people who need it.

Next steps

List the systems that hold customer data or take payments, then check that updates, access and backups are in order. After that, decide whether a scan, a scoped test or both fit your situation. If you would like help preparing for a test or fixing what it finds, you can contact us.