Vulnerability scan or penetration test? What each one actually finds

A vulnerability scan is an inventory exercise: an automated tool looks for known weaknesses and hands you a list. A penetration test is an evidence exercise: a human uses those weaknesses to see how far into your systems they can actually get. The difference is not the tooling, it is the question being asked. A scan asks "where might there be a hole?" A pentest asks "can that hole be used to reach the customer database?" Neither replaces the other, and the clearest proof of that comes from the rules themselves. PCI DSS puts scanning under requirement 11.3 and penetration testing under 11.4, as separate obligations. Turkey's banking IT regulation lists automated scanning tools in Article 16 and an annual test by an independent team in Article 18. So if what you have is a scanner report, you have not had a penetration test.

What a scanner does well, and where it stops

Scanning is pattern matching. The tool discovers hosts, identifies open ports and the versions of services running on them, compares that against databases of known vulnerabilities, and produces a list. It does this far faster than any person: an unpatched library, an expired certificate, an admin panel still on its default password, an internal service exposed to the internet by mistake. One distinction matters a lot here. An unauthenticated scan looks from the outside and infers; an authenticated scan logs in, reads the installed package versions, and is markedly more accurate. PCI DSS 4.0 spells this out in 11.3.1.2, which requires internal scans to be performed via authenticated scanning. The reason is simple: from the outside, a scanner cannot know what is really installed on a host.

Scanners have two structural limits. The first is false positives, which is why a raw scan list is a set of candidates rather than a set of confirmed exposures. The second matters more: a scanner only finds flaws that somebody else has already discovered and catalogued. Bugs unique to your own application, with no CVE number attached, sit outside its field of view entirely.

The flaws a person finds and a tool cannot

The blind spot is short to describe and it is exactly where breaches happen. Authorisation flaws live here. If changing the invoice number in a URL from 1043 to 1044 shows you another customer's invoice, you have a real vulnerability with no CVE to its name. Business logic flaws are the same story: applying the same discount code twice, entering a negative quantity to earn credit, skipping the payment step and landing on the confirmation page anyway. No tool can judge these, because only your business rules define which user should reach which record and which action. Broken access control, the number one entry in the OWASP Top 10 for years running, falls into precisely this class and is the hardest to detect automatically. The same holds even more strongly for APIs: confirming that an endpoint responds is easy, working out whether it returns somebody else's record is human work.

Three "lows" add up to one "critical"

The second difference is chaining. A scanner scores findings one at a time; an attacker combines them. Say directory listing was left enabled on a staging host, which the scanner rates medium. An old backup file in the same directory is readable, rated low. The third piece is something the scanner never reports at all: the database password inside that backup is also in use on the production server. Individually, none of the three would alarm anyone. Together they form a route to the customer database. That is the real product of a penetration test. Not a list of findings, but a demonstrated path. The most valuable line in the report is not the name of a vulnerability, it is the sentence "following these steps, I reached this data."

Why the standards keep them apart

PCI DSS 4.0.1 is the cleanest example. Internal vulnerability scans go at least once every three months (11.3.1), external scans at least once every three months and by a scanning vendor approved by the PCI SSC (11.3.2). Penetration testing sits in its own group: internal testing at least every 12 months (11.4.2), external testing at least every 12 months (11.4.3), testing that segmentation controls actually work every 12 months (11.4.5), and every six months for service providers (11.4.6). On top of that, 11.4.1 requires a documented methodology based on industry-accepted approaches, along with organisational independence of the tester from the team that manages the systems under test. NIST SP 800-115, the OWASP testing guides, PTES and OSSTMM are the usual accepted references. A passing ASV scan does not count as a penetration test, and a passing penetration test does not retire the scanning requirement.

Who mandates what in Turkey

In banking the split is written into law. Article 16(3) of the Regulation on Banks' Information Systems and Electronic Banking Services requires banks to run automated vulnerability scanning tools against networked systems and devices, reporting findings to the information security officer with the most critical ones listed first. Penetration testing appears separately, in Article 18(7): a bank must have a penetration test carried out at least once a year by independent teams that played no part in designing, developing, implementing or operating the services delivered through those information systems. Note the independence condition. The team that built the system cannot audit its own work.

Under KVKK, Turkey's data protection law, the picture is different. Article 12 requires "necessary technical and organisational measures" without naming a frequency or a method. The regulator's Personal Data Security Guide is more specific, stating that vulnerability scans and penetration tests should be performed regularly to protect information systems against known weaknesses, with the resulting findings assessed. The two are named together, not as alternatives to each other. Public bodies and critical infrastructure operators additionally fall under the Information and Communication Security Guide, which expects an annual compliance audit. In EU financial services there is a heavier layer still: Article 26 of DORA requires in-scope entities to run threat-led penetration testing (TLPT) at least every three years, on live production systems supporting critical functions. ISO 27001 takes a different route and does not dictate a pentest as such; A.8.8 covers technical vulnerability management and A.8.29 covers security testing in development and acceptance, and the auditor asks for evidence of how you do it.

Red teaming is a third thing

Penetration testing and red teaming get conflated constantly. A pentest is scope-driven: find as many issues as possible in the agreed systems and report all of them. A red team engagement is objective-driven: the team is handed a goal such as "get into the payroll system," works quietly like a real intruder, and what actually gets measured is whether you notice and respond. In other words, a red team exercise tests your incident response capability more than your patch levels. Sequence matters here. Buying a red team engagement before you have closed your known holes wastes money, because the outcome is a foregone conclusion.

How often, and in what order

Scanning is continuous work; penetration testing is periodic. The numbers explain why: 48,185 new CVEs were published in 2025, roughly 21% more than the year before. A host that was clean yesterday can be exposed today without anyone touching it, because the world moved rather than the server. A workable rhythm looks like this: automated scanning of internet-facing assets weekly or at least monthly, internal scanning at least quarterly, a penetration test annually and after every significant change, whether that is a major release, an architecture change or a data centre migration.

Order matters as much as frequency. A company that has not scanned and has not applied its patches will be paying a specialist day rate to rediscover what a free tool would have printed out. Half the report fills up with missing-update lines, and the time that should have gone into business logic and access control disappears. The right sequence is inventory, scan, patch and fix configuration, then test. Preparing properly beforehand has a direct effect on what you get back.

Is the report in your hands a real test?

Scanner output with a cover page bolted on does get sold as a penetration test report. Telling the difference is not hard. A real report gives reproduction steps for each finding: which request, which parameter, which response. It gives evidence: screenshots, request bodies, a redacted sample of the data obtained. It states business impact, naming whose data becomes reachable, not just a CVSS score. It contains at least one finding no scanner could have produced, such as an authorisation bypass or a broken workflow. It names the testers and the methodology. And the contract defines retesting after remediation, with a window. If none of that is present, what you bought was a scan, and it should have been priced like one.

Questions to ask before you sign

• Exactly which IP ranges, domains and applications are in scope, and what is explicitly out?
• Will testing be authenticated, and with which roles (anonymous, standard user, administrator)?
• Which methodology is followed (NIST SP 800-115, OWASP WSTG, PTES)?
• What is the split between automated tooling and manual testing, and does the sample report show manual findings?
• Is the testing team independent of the people who built and run the systems?
• Is a retest after remediation included in the price, and within what timeframe?
• If production is in scope, how is the risk of disruption managed and who gets called if something breaks?

The short version: a vulnerability scan gives you the list of known holes and needs to run continuously; a penetration test shows how much ground those holes actually give away and needs a human doing it on a cycle. At Wedevit we run the two as one programme: mapping your internet-facing assets, setting the scanning rhythm and prioritisation, scoping the test around your commercial risk, carrying it out, ranking findings by business impact and retesting after the fixes land. A first step that costs nothing: open your most recent penetration test report and look for a single finding a scanner could not have produced. If there isn't one, that test never really happened.