VI · EN
Get a consultation098.169.1103
Back to News
— TECHNICAL / PENETRATION TESTING

Why Penetration Testing Matters: Scanning Is Not Enough

A vulnerability scanner returns a list of what could be wrong. A penetration test answers a different question entirely: how far can an attacker actually get inside your systems. The gap between those two answers is where most breaches happen.

TECHNICAL·18.08.2026·13 min read·The TechShield Team

Many companies believe their security risk is under control because a vulnerability scan report lands in an inbox every month. The report runs dozens of pages, has charts, has severity ratings, and most of it is green. The problem is that the report only answers the easy question: which software versions carry known vulnerabilities?

The hard question — and the only one an attacker cares about — is this: if I chain these scattered weaknesses together, can I get from the internet to your customer database? Only a penetration test answers that, because it is the only process in which a human being genuinely tries.

01What a pentest is, and how it differs from vulnerability scanning

Vulnerability scanning is automated: a tool compares software versions, configurations, and known signatures against a vulnerability database and lists the matches. It is fast, inexpensive, can run daily, and is very good at surfacing published flaws. What it does not have is business context — it does not know which data matters, and it cannot chain several small weaknesses into an attack path.

Penetration testing is human-driven, goal-oriented, and scoped by agreement in advance. The tester plays the attacker: mapping the attack surface, finding weaknesses, exploiting them for real, escalating privileges, moving laterally, and pushing toward the most valuable assets. The output is not a list of CVEs but a narrative: from this entry point, the attacker moved through B and C, and ended up reading table D.

The two do not replace each other. Scanning keeps the attack surface from expanding between tests; pentesting verifies that the defences you rely on actually hold. A company that scans but never pentests ends up with a long list of known issues and no idea which of them is genuinely dangerous.

Vulnerability scanning — breadth

Automated, continuous, surfaces known flaws across a wide surface. Does not verify real exploitability.

Penetration testing — depth

Expert-driven, real exploitation, demonstrating the concrete business impact of each attack path.

Red teaming — detection capability

Simulates a prolonged, unannounced campaign to measure whether the defensive team detects and responds in time.

A scanner tells you which windows are unlocked. A pentest tells you which room the burglar reached.

02Vulnerability exploitation is now the number one way in

Verizon's 2026 DBIR, built on analysis of more than 22,000 breaches, found that exploitation of technical vulnerabilities accounts for 31% of all initial access — up from 20% the previous year, a 55% increase in twelve months — making it, for the first time, the most common attack vector, ahead of both phishing and credential abuse.

More striking still: edge devices and VPNs rose from 3% to 22% of exploitation-driven breaches, a sevenfold increase in a single year. Several large ransomware campaigns during this period began with a single unpatched flaw on a device sitting at the network perimeter.

The implication for businesses is direct. The most consequential attack surface today is not the internal application — it is the outer edge, the part that is least often reviewed and where scanners typically have the least access. That is precisely the scope where a controlled penetration test creates the most value.

03What scanners will never find

An entire class of vulnerabilities is structurally invisible to automated tools, because they are not software defects but flaws in logic that humans designed. These are usually the most damaging findings, since they allow the system to be abused exactly the way it was built to work.

Across TechShield's testing engagements, the highest-value findings almost always fall into the categories below — and none of them appear in an automated scan report.

Business logic flaws

Ordering a negative quantity to trigger a refund, skipping payment by calling the final-step API directly, applying a discount code repeatedly.

Horizontal access control failures

Changing an ID in a URL to read another customer's record. The scanner sees an HTTP 200 and considers it normal.

Chained attack paths

A low-severity information leak plus a default account plus one misconfigured permission becomes a path to domain administrator.

Supply chain and integration gaps

API keys exposed in browser-side code, webhooks that never verify signatures, third-party services trusted far more than they should be.

Human process weaknesses

A help-desk password reset flow that can be socially engineered, or access rights of departed staff that were never revoked.

The most dangerous vulnerability is rarely a coding error. It is a process working exactly as designed — when the design itself is wrong.

04A pentest only pays off when the findings get fixed

This is the part most organisations miss. Cobalt's State of Pentesting 2026 report shows the typical organisation resolves 86% of its high-risk findings — a respectable figure on its own. But measured across the full five-year dataset, the overall resolution rate sits at just 52%. Nearly half of all discovered vulnerabilities were found, written into a report, and left exactly where they were.

Speed matters as much as completion. The median organisation takes 39 days to resolve a serious finding. The spread, however, is enormous: top performers achieve a high-risk finding half-life of 10 days, while the bottom tier stretches to 249 days. For the same vulnerability, one company closes its window of exposure in two weeks; another leaves it open for eight months.

For AI and large language model systems the picture is worse. AI/LLM pentests carry the lowest resolution rate Cobalt tracks — 38.4% in 2026 — with a mean time to resolve of 36 days. This is the direct consequence of AI features being bolted onto products far faster than security teams can learn to reason about them.

Put remediation SLAs in writing internally

Critical within 7 days, high within 30, medium within 90 — with a named owner for each item.

Always include a retest round

A pentest is not finished until the fix is verified to actually close the original attack path.

Track half-life, not backlog size

The number of open findings says little about risk. The average time to close a critical one says everything.

05Penetration testing in compliance frameworks and tenders

Roughly 75% of information security professionals report that they conduct penetration tests to satisfy regulatory compliance requirements. That reflects how thoroughly pentesting has been written into the frameworks now in force — it is no longer a discretionary engineering activity.

In Vietnam, Decree 85/2016/ND-CP together with Circular 12/2022/TT-BTTTT establish the duty to inspect and assess information security for systems against their approved assurance level, including evaluating the implementation of protection measures against each criterion in the level proposal dossier. For systems processing personal data, the Personal Data Protection Law No. 91/2025/QH15, effective 1 January 2026, requires proportionate protective measures — and independent testing is the most practical way to demonstrate those measures actually work.

Internationally, ISO/IEC 27001 requires technical vulnerability management and evaluation of control effectiveness; PCI DSS mandates penetration testing periodically and after any significant change to the cardholder data environment; SOC 2 treats a recent pentest report as standard evidence for the security criterion. For Vietnamese companies serving overseas clients, an independent pentest report from the last 12 months has become one of the earliest documents requested in due diligence.

In most tenders today the question is no longer whether you are secure, but what date is on your most recent test report.

06How often to test, and what to put in scope

Annual testing has become the minimum standard, but for companies shipping software continuously a year is far too long — a system tested in January may be unrecognisable by June. A more workable rule combines a fixed schedule with event-based triggers.

On scope, the most common mistake is testing the flagship web application and nothing around it. Yet according to 2026 DBIR data, it is the network perimeter where the share of breaches has grown fastest.

Minimum cadence

Every 12 months for all critical systems; every 6 months if you process payment data or sensitive personal data at scale.

Event-based triggers

After any major architectural change, cloud migration, system merger, or launch of a payment-handling feature.

External scope

Public domains, VPN gateways, firewalls, misconfigured cloud services, and publicly readable object storage.

Internal scope

Assume the attacker already holds one workstation inside — test privilege escalation and lateral movement toward core systems.

Applications and APIs

Including APIs with no user interface, routinely missed because they never appear on a functional diagram.

AI components

If the product integrates a language model, bring it into scope now — this is the category with the lowest remediation rate today.

07Choosing a testing partner: seven questions to ask

The quality of a test depends almost entirely on the people running it. Two reports of identical length can represent wildly different levels of effort: one is reformatted tool output, the other is four weeks of manual exploitation.

The seven questions below separate the two before a contract is signed, and are worth asking of any provider — including TechShield.

01 — What proportion of the test is manual?

Ask for an explicit split between tool-driven coverage and hands-on exploitation by a tester.

02 — Who actually performs the work?

Request the credentials and certifications of the specific individuals assigned, not of the company in general.

03 — Does the report include proof of exploitation?

Every significant finding needs concrete reproduction steps your engineers can verify themselves.

04 — Is impact expressed in business terms?

Not merely CVSS 9.1, but which data was exposed and what it would mean for operations.

05 — Is a retest after remediation included?

Fix verification belongs inside the contract scope, not as an add-on service.

06 — How does the partner protect your data?

Your tester will hold the most sensitive information about your systems — ask how it is stored and how it is destroyed.

07 — Will they walk your developers through the findings?

The real value lies in fixes being made correctly, which usually needs a direct conversation between tester and engineer.

A good pentest report does not reassure you. It tells you exactly what to fix first.

Key takeaways

  • 01Vulnerability exploitation now accounts for 31% of initial access according to the 2026 DBIR, up 55% year over year, with edge devices and VPNs rising from 3% to 22%.
  • 02Automated scanners cannot find business logic flaws, horizontal access control failures, or chained attack paths built from several minor weaknesses — usually the most damaging category.
  • 03The five-year overall vulnerability resolution rate is just 52%; the median time to fix a serious finding is 39 days, with leaders at 10 days and laggards at 249.
  • 04Penetration testing is required directly or indirectly by Decree 85/2016, Circular 12/2022, ISO/IEC 27001, PCI DSS, and SOC 2 — around 75% of security professionals test for compliance reasons.
  • 05Test at least every 12 months plus after every major architectural change, and always include AI components, which currently show the lowest remediation rate at 38.4%.
// READY TO ACT

Assess your organisation's security posture

The TechShield team can help you review your risks and build a security strategy fit for the age of AI. Book a free consultation today.

Accent color

Density