Penetration testing — how does it differ from vulnerability scanning?

The company scans its infrastructure regularly. The latest report shows no critical vulnerabilities, and most findings have low or medium priority. IT deploys some fixes and considers the situation under control. Only during a penetration test does it emerge that several seemingly unrelated weaknesses can be combined into a single scenario leading to access to critical assets.

The scanner found problems. The penetration tester checked what could be done with them.

This distinction matters to any organisation planning penetration testing. Automated vulnerability scanning and a professional penetration test answer different questions. The first provides a broad, repeatable picture of potential weaknesses. The second shows whether a real attacker could exploit and combine them to cause a business impact. Bringing both perspectives together enables informed risk decisions.

Useful insights

• Vulnerability scanning automatically identifies potential weaknesses across a broad scope, but usually does not validate a complete exploitation scenario.
• A penetration test combines tools, expert analysis and a controlled attack simulation. It assesses the vulnerability along with the possible attack path, reach and impact on data and processes.
• Vulnerability assessment and penetration testing complement each other. Scanning works well as a regular check, while penetration testing provides periodic, in-depth validation of resilience.
• An assessment delivers value only when it leads to prioritisation, remediation, retesting and continued monitoring.
• The test scope should reflect changes in the environment, system criticality, internet exposure and business risk — not just the calendar.

Why a scanner report alone does not answer the most important question

An automated scanner can identify an outdated component, an insecure service configuration, an open port or missing security headers. This is valuable information, particularly when the environment contains hundreds of systems and changes constantly. Problems arise when the findings list is treated as a complete assessment of organisational resilience.

A scanner follows rules and signatures. It may indicate that a weakness probably exists, but it usually lacks business context: the value of the data, user privileges, system dependencies, segmentation effectiveness or an application’s importance to continuity. It may also fail to identify business logic flaws or connect several findings into a multi-stage attack path.

From a management perspective, the number of vulnerabilities is therefore not the main issue. More important questions are whether the weaknesses can be exploited, which assets they lead to, which process they could disrupt and which fixes would actually reduce risk. A well-planned penetration test provides these answers.

What is penetration testing?

A penetration test is an authorised, controlled attempt to breach the security of a system, application, network or another agreed area. The tester adopts an attacker’s perspective while staying within the defined scope, schedule and safety rules. The goal is not simply to break in, but to provide evidence of which scenarios are feasible and what they mean for the organisation.

NIST defines penetration testing as testing how well a system, device or process withstands active attempts to compromise its security. In practice, this means moving from a vulnerability hypothesis to controlled validation, considering environmental risk and staying within the owner’s authorisation. A broader discussion of planning and assessment techniques is available in NIST SP 800-115.

A professional penetration test may cover:

• internet-facing external infrastructure;
• internal networks and segmentation controls;
• web applications and APIs;
• cloud environments;
• network devices and services;
• identity, authentication and authorisation controls;
• resilience against selected social engineering scenarios — where this scope has been explicitly agreed.

For web applications, a useful reference is OWASP Web Security Testing Guide, which structures testing areas including authentication, authorisation, session management, input validation and business logic. However, a methodology does not replace scope decisions. The same test set will not suit an information portal, online banking and a production control system.

A penetration test is not an audit of everything

A penetration test answers questions about a specific agreed scope at a particular time. Testing one application does not establish the security of the entire organisation. Nor does it replace an architecture audit, code review, process assessment, compliance analysis or continuous monitoring. It is one risk management tool, particularly valuable when an organisation needs to verify whether attack scenarios are realistically achievable.

What is vulnerability scanning?

Vulnerability scanning is an automated assessment of systems, services or applications for known weaknesses and insecure configurations. The tool identifies assets, checks available services, compares versions and system responses with a rule database, and produces a list of potential issues with severity ratings.

Its main strengths are scale and repeatability. Scans can run regularly, results can be compared over time and new exposures can be identified quickly. Vulnerability assessment therefore supports a continuous vulnerability management programme: inventory, classification, ownership, remediation and verification.

What a scanner does well

• quickly covers large numbers of addresses, hosts and services;
• detects many known vulnerabilities and common configuration errors;
• supports recurring checks after updates and changes;
• helps track remediation backlogs and recurring issues;
• helps identify areas requiring manual analysis.

The limitations of automated scanning

Scanner results are the starting point for analysis, not a final verdict. Tools may produce false positives: findings that prove unexploitable when verified. They may also miss weaknesses arising from business logic, unusual architecture, incorrect trust relationships or a chain of several flaws.

Scanning can also affect the environment. Excessive intensity, an unsafe check or scanning a legacy system may cause problems. Even automated assessments therefore require an agreed scope, configuration, execution window and response plan for unintended effects.

Penetration testing versus vulnerability assessment — key differences

Put simply, scanning asks 'What might be a weakness?’ and penetration testing asks 'Can it be exploited, and to what end?’ In practice, the boundary is not always clear-cut: testers also use scanners, and mature vulnerability assessments may include manual validation. Their primary objectives and depth of analysis nevertheless differ.

Area	Vulnerability scanning / vulnerability assessment	Penetration testing
Primary objective	Broad identification of potential vulnerabilities and configuration errors	Controlled validation of exploitability and attack impact
How we work	Primarily automated, based on rules and signatures	A combination of tools, manual analysis, experience and tester judgement
Outcome	A list of findings requiring assessment and prioritisation	Confirmed attack paths, evidence, impact and recommendations
Business context	Limited; depends on the data supplied to the tool and the analysis process	High, provided the scope and objectives are properly defined
Combining multiple weaknesses	Usually limited	A key part of the penetration tester’s work
Business logic flaws	Often missed or poorly assessed	Can be identified and verified manually
Frequency	Regularly, for example after changes and on an agreed cycle	Periodically and after significant changes or incidents, or before launching a critical system
Impact on the environment	Usually lower, but depends on configuration and the system under assessment	Controlled but potentially greater; requires Rules of Engagement and safety procedures
Business question answered	'What potential weaknesses can we see?’	'How realistic is the attack scenario, and what could it mean for the organisation?’

This is why reports should not be compared solely by their number of findings. A scanner may list hundreds of items, some with no practical significance in the environment. A penetration test may produce only a few findings, but one could demonstrate a route to compromising a privileged account, customer data or a critical process.

Black box, grey box and white box — types of penetration testing

The information shared with the tester affects the time, depth and perspective of the assessment. These models are not a quality ranking. Each serves a different purpose.

Test type	Initial information	What it assesses	Typical use	Limitation
Black box	Minimal information, similar to an external attacker’s knowledge	The external attack surface, reconnaissance opportunities and initial access	A new internet service, public infrastructure or exposure assessment	Reconnaissance consumes some of the time; the test may not reach deeper areas
Grey box	Limited access, such as a standard user account and basic documentation	Privilege escalation, role separation, data access and post-account-compromise scenarios	Business applications, customer portals and internal systems	Results depend on how representative the provided access is
White box	Extensive information: architecture, test accounts, configurations and sometimes code	In-depth analysis of controls and broader coverage within limited time	Critical systems, pre-production reviews and in-depth application assessments	Less representative of an external attacker’s starting point, but improves assessment efficiency

The models can also be combined. An organisation may begin with a short black-box phase, then supply accounts and documentation so the tester can go beyond the attack surface. The choice should follow the objective: external exposure, resilience after account compromise or the broadest possible system coverage.

What does a professional penetration test involve, step by step?

A good IT security test begins before the first technical attempt. The most important decisions concern the objective, scope, permitted activities and communication. Without these, a test may be too shallow, poorly aligned with risk or unnecessarily dangerous to production.

1. Agreeing the objective and scope

The organisation identifies the systems, domains, applications, APIs, addresses and environments to be assessed. Exclusions are equally important: critical systems, data, times or techniques the tester must avoid. The objective should be measurable, such as assessing whether a basic user account can access customer data.

2. Rules of Engagement and operational preparation

The rules define permitted techniques, the testing window, load limits, data handling, escalation and stop conditions. Both sides need current contact details. If the tester finds a critical weakness or an unintended effect on a service, they should know whom to contact and how.

3. Reconnaissance and attack surface mapping

The tester gathers information about assets, services, technologies, entry points and trust relationships. This may involve public data, documentation, application traffic and automated tools. The aim at this stage is to build an understanding of the environment rather than exploit vulnerabilities.

4. Identifying and manually validating weaknesses

Scanner results are verified manually, and the tester also looks for issues automation commonly misses: authorisation and business logic flaws, excessive privileges, unsafe trust relationships and ways to bypass controls.

5. Controlled exploitation attempts

The tester validates selected scenarios only as far as necessary to demonstrate the risk. More invasive actions should be avoided where the same conclusion can be demonstrated safely. The evidence scope must follow the prior agreement, not technical curiosity.

6. Assessing escalation and reach

If access is obtained, the tester checks — within authorised boundaries — whether privilege escalation, lateral movement or access to further systems or data is possible. This is where an isolated finding becomes a path towards significant business impact.

7. Documentation, reporting and recommendations

The report should include scope and limitations, methodology, confirmed findings, evidence, impact assessment, a likely attack scenario and remediation recommendations. A good recommendation goes beyond 'update the component’. It also identifies ownership, priority, dependencies and how to verify the fix.

Stage	Main question	Outcome for the organisation
Scope and rules	What are we testing, and what must not be affected?	Controlled operational risk and comparable results
Reconnaissance	What does the accessible attack surface look like?	A map of systems, services and entry points
Validation	Which weaknesses are real in this environment?	Fewer false positives and better prioritisation
Exploitation and escalation	How far could an attacker get?	A confirmed scenario and its impact on data and processes
Reporting and retesting	What should be fixed, and does the fix work?	A risk reduction plan and evidence that changes are effective

What does a penetration test actually show?

A penetration test is not intended to prove that a tester can find a flaw. It should turn technical findings into decisions. Administrators need configuration and remediation details; system owners need to understand the impact on availability and data; management needs to understand disruption risk, accountability and investment priorities.

Depending on its scope, a test may reveal:

• the possibility of unauthorised access to an application or data;
• escalation from a standard user account to administrative privileges;
• segmentation bypass and lateral movement between systems;
• the possibility of compromising an account, application or infrastructure component;
• abuse of a legitimate application function in ways its designers did not anticipate;
• insufficient visibility of attacker activity in logs and the detection process.

Expert comment: 'A scanner organises potential weaknesses into a list. A penetration test shows which can be combined into a scenario with a real business impact. The test’s greatest value is not the number of findings, but the answer to two questions: what can an attacker achieve, and what needs fixing first?’

It is also worth checking whether the confirmed scenario would be visible to the security team. Penetration testing does not replace monitoring, but it can inform improvements to detection rules, logging and playbooks. If the organisation uses SIEM in a company, test findings can help verify whether important actions were recorded, correlated and escalated correctly.

When is scanning enough, and when is a penetration test needed?

Scanning is useful where frequent, broad and repeatable checks are needed. A penetration test is appropriate when deeper analysis is required, a real scenario needs validating or a system has high business value. A mature programme combines both.

Scanning is the right first choice when:

• an organisation wants to check large numbers of assets regularly;
• it needs to identify known vulnerabilities quickly after changes and updates;
• it tracks remediation timeliness and backlogs;
• it is building an exposure inventory and vulnerability management programme;
• it wants to identify systems and issues for deeper analysis.

A penetration test is needed when:

• a new internet-facing system, application, API or service is being launched;
• the architecture has changed significantly, services have moved to the cloud or identity has been redesigned;
• a system processes sensitive data or supports a critical business process;
• the organisation needs to test whether weaknesses can be combined to bypass layers of protection;
• the organisation wants to assess resilience following user account compromise;
• an incident has occurred and a related attack path needs verification after the cause has been addressed;
• management needs evidence of which scenarios genuinely threaten business continuity.

Both approaches are usually needed

A practical model is to scan the environment regularly, analyse and remediate findings, and commission periodic penetration tests of key areas. Testing checks not only vulnerabilities but also architectural assumptions, access controls, segmentation and detection capability. Remediation is followed by a retest, and the findings inform vulnerability management and monitoring.

Expert comment: If scanner reports keep growing but it remains unclear which weaknesses form a real attack path, start by defining the assessment objective. Discussing the test or audit scope helps match the method to critical systems, environmental changes and business risk, without treating penetration testing as a replacement for regular scanning.

Case study: three weaknesses, one real scenario

The scenario below is an illustrative editorial example. It does not describe a specific customer or an actual VigilHorizon engagement.

A manufacturing company ran monthly vulnerability scans of its infrastructure. The report listed several low- and medium-severity findings: a service revealing excessive detail, a service account with overly broad privileges and a network segment accessible from more zones than the architecture required. None was rated critical.

During the penetration test, the tester did not assess these issues in isolation. They checked whether the first issue helped identify an account and system dependencies, whether excessive privileges enabled access to another asset and whether segmentation rules allowed further movement. Within a controlled scope, they confirmed a scenario leading from a low-value service to an asset supporting production.

The scanner was not wrong. It correctly identified technical weaknesses, but lacked the context to assess their combined impact. The penetration test changed remediation priorities: instead of starting with the most striking result in the report, the organisation restricted the service account’s privileges, improved segmentation, reduced information disclosure and added detection rules for the observed path.

After the changes, a retest was performed. The findings were then used to improve monitoring and Incident Response scenarios. As a result, the test did not end with a report: it changed the architecture, detection and response.

How often should penetration testing be performed?

There is no single frequency suitable for every company. An annual test may be a reasonable baseline for a stable environment, but the calendar alone should not determine assessments. A system changed a month after testing may need an earlier reassessment, while an unchanged, low-risk niche application may need a different cycle from a public portal handling customer data.

Consider penetration testing:

• periodically, based on risk classification and asset criticality;
• before launching a new system or important feature;
• after a significant change to architecture, integrations, privileges or a provider;
• after cloud migration or an expansion of the internet-facing attack surface;
• after an incident, to verify a remediated path or similar systems;
• when contractual or regulatory requirements or the threat profile change.

NIS2 does not require every organisation to perform a particular penetration test on an identical schedule. Article 21 does, however, address vulnerability management and policies and procedures for assessing the effectiveness of cybersecurity risk management measures. Appropriately selected tests can provide such verification, but their scope should follow risk. The operational perspective on these requirements is discussed further in NIS2 and security monitoring, while the legal source remains the text of the NIS2 Directive.

Common organisational mistakes

Treating scanning as a comprehensive resilience test

A broad report can look convincing, but it does not automatically establish whether an attack is feasible. The conclusion should be that scanning builds visibility, while in-depth validation helps explain actual impact.

Commissioning a penetration test without a business objective

A list of IP addresses does not describe critical processes. Without an objective, a tester may focus on technically interesting areas that matter less to the organisation. The scope should reflect data, system owners, downtime tolerance and the scenarios the company is most concerned about.

Relying solely on CVSS scores

Technical ratings are useful but do not capture the full context. A medium-rated vulnerability may be an important link in an attack chain. A highly rated finding may be difficult to exploit because of additional controls. Prioritisation should combine technical severity, exposure, feasibility and business impact.

Failing to assign owners and remediation deadlines

A report without assigned actions soon becomes an archive. Each significant finding should have an owner, deadline, risk mitigation approach and closure criterion.

Skipping the retest

’Fix deployed’ does not necessarily mean the attack path is closed. A change may be incomplete, leave a bypass or address the symptom rather than the cause. Retesting confirms effectiveness within the agreed scope.

Treating penetration testing as the end of the process

A test is a snapshot of the environment at a particular time. New deployments, accounts, integrations and vulnerabilities change the situation. Findings should therefore inform regular scanning, change management, training, logging and SOC 24/7, where the risk calls for continuous event analysis and response.

Does your organisation need a penetration test?

The following checklist does not replace scope analysis, but helps identify when scanning alone may be insufficient.

Question	Answer
Has the critical environment gone without a penetration test for the past 12 months?	YES / NO
Has a new application, API, integration or significant feature been deployed since the last test?	YES / NO
Has the organisation migrated to the cloud or changed its identity model?	YES / NO
Is the system internet-facing, or does it serve remote users and partners?	YES / NO
Does it process sensitive data or support a process whose disruption would affect revenue or business continuity?	YES / NO
Are only automated scans performed, without manual validation?	YES / NO
Do reports contain many findings whose combined impact the organisation cannot determine?	YES / NO
Have privilege escalation, segmentation and resilience after account compromise remained untested?	YES / NO
Did the latest incident reveal a weakness that could also affect other systems?	YES / NO
Does a contract, audit or risk profile require an independent assessment of control effectiveness?	YES / NO
Have previous fixes not been retested?	YES / NO
Is the security team unsure whether test scenarios would be detected and handled?	YES / NO

The more 'yes’ answers, the stronger the case for an in-depth assessment. The right model still needs to be selected: an application test, an internal infrastructure test, or perhaps an architecture review or process audit rather than another exploitation attempt.

What should you do with test results?

The value of a penetration test emerges after the technical work. The report should trigger a structured remediation process:

1. Confirm context and ownership. Identify the affected systems and processes and who owns the decision.
2. Prioritise according to risk. Combine feasibility, exposure, impact on data and availability, and business dependencies.
3. Address the cause, not just the symptom. Fixes may involve code, configuration, privileges, segmentation, deployment processes or monitoring.
4. Apply compensating controls. If a permanent fix takes time, limit exposure, access or escalation opportunities.
5. Perform a retest. Check that the scenario has been closed and the change has left no bypass.
6. Update detection and response. Ensure significant actions would be visible in logs, analysed and escalated.
7. Integrate the findings into the ongoing programme. Update scan rules, configuration standards, deployment checklists and the plan for further assessments.

This closes the loop between identification and resilience: scanning reveals a broad range of issues, penetration testing validates a scenario, remediation reduces risk, retesting confirms the outcome, and monitoring detects what cannot be eliminated entirely.

Summary

Automated vulnerability analysis gives an organisation scale and regularity. However, it does not fully establish whether the weaknesses form a real path to data, privileges or critical processes. Penetration testing provides that perspective, but it is neither a one-off solution nor a replacement for continuous oversight.

The most mature approach combines both. The organisation identifies potential issues regularly, periodically validates the most important scenarios, addresses root causes, confirms results through retesting and monitors the environment between assessments.

If you want to check whether your scanning programme reflects actual risk and which penetration test scope suits your systems, talk to VigilHorizon about penetration testing, a security audit or risk analysis. We start with the scope and business importance of your systems, rather than a predefined package disconnected from your environment.

Frequently asked questions (FAQ)

1. What is a penetration test?​

An authorised, controlled attempt to breach the security of an agreed system, application or network. The objective is to establish whether weaknesses can be exploited and what that could mean for the organisation.

2. How does a penetration test differ from vulnerability scanning?​

Scanning automatically searches for potential vulnerabilities across a broad scope. Penetration testing uses expert work to validate findings, combine them into attack paths and assess the impact on data and business processes.

3. How does a penetration test differ from a security audit?​

A penetration test focuses on controlled validation of attack feasibility within a defined scope. An audit may assess architecture, configuration, documentation, processes, compliance and risk management much more broadly. The scopes can complement each other, but the terms are not synonymous.

4. Is penetration testing safe?​

Penetration testing involves controlled risk because it includes active attempts. It therefore requires Rules of Engagement, exclusions, limits, a testing window, emergency contacts and agreed data handling. No one should promise a complete absence of impact on the environment.

5. How long does a company penetration test take?​

Duration depends on scope, system count, application complexity, the black-, grey- or white-box model and required depth. A reliable estimate requires agreement on assets, objectives, limitations and reporting.

6. How often should penetration testing be performed?​

The cycle should follow risk and the pace of change. Testing is performed periodically and after significant deployments, migrations, architectural changes or incidents, and before launching critical systems. 'Once a year’ alone is insufficient if the environment changes more frequently.

7. Can a vulnerability scanner replace a penetration test?​

Not when the objective is to validate a complex scenario, business logic flaws, privilege escalation or impact on a critical process. It can, however, support regular checks effectively and supply data for deeper assessment.

8. Does penetration testing replace regular scanning?​

No. A penetration test is limited in scope and time. Regular scanning identifies newly known vulnerabilities and changes in exposure between tests. Both should feed into one vulnerability management process.

9. Does NIS2 require penetration testing?​

The Directive does not impose one identical penetration testing obligation on every organisation. It requires a risk-based approach, vulnerability management, and policies and procedures to assess the effectiveness of security measures. Penetration testing may be an appropriate verification method depending on activities and risk.

10. What should a penetration test report contain?​

At minimum: scope, limitations, methodology, an executive summary, findings, evidence, impact assessment, attack scenarios and recommendations. It should also establish priorities and support subsequent retesting.

11. Is retesting always needed after a penetration test?​

Retesting is the best way to confirm that fixes closed the identified path without leaving a bypass. Its scope may be narrower than the original assessment, but should include the findings the organisation claims to have addressed.

12. How much does a penetration test cost?​

Cost mainly depends on scope and effort: the number of applications, roles, interfaces and addresses, the test model, environment and reporting requirements. Comparing proposals without aligning their scope can mean comparing assessments of very different depth.

13. Can penetration testing be performed in production?​

Yes, where risk has been consciously assessed and the rules appropriately constrain activities. For some systems, an environment closely resembling production will be safer. The decision depends on the objective, service criticality and whether reliable results can be obtained outside production.

Learn more

• SIEM in your company — why deployment alone does not improve security
• What a 24/7 SOC is and why monitoring alone is not enough
• Incident Response: responding to a cyberattack step by step
• NIS2 and security monitoring—what the Directive actually requires
• The VigilHorizon SOC 24/7 plan