0%
BACK TO OVERVIEW

What is a Penetration Test? Definition, Process, Costs and the Difference to Vulnerability Scanning

What is a Penetration Test? Definition, Process, Costs and the Difference to Vulnerability Scanning

Firewall, SIEM, EDR – and still compromised. Why?

A mid-sized company invests six figures in IT security. Next-generation firewall, a SIEM processing logs around the clock, endpoint detection on every device. On paper: perfectly positioned. Six months later: ransomware in the network, three weeks of downtime, customer data gone.

What failed? Not the technology. The technology did exactly what it was configured to do. What nobody had ever tested: whether that configuration would actually hold up when someone actively and creatively works against it. A vulnerability scanner would not have found the misconfigured VPN rule, because it technically had no CVE. An automated tool would not have recognised the combination of a weak Active Directory and a forgotten contractor account as an attack path.

That is exactly the gap a penetration test closes.

Implementing security measures and verifying whether they hold up under real attack conditions are two fundamentally different activities. A penetration test is the only method that answers the second question empirically.

68%
Of all breaches involve a human element (Verizon DBIR 2024)
194 days
Average dwell time of an attacker before detection
~30,000
Companies in Germany now under NIS2 obligations
1 in 3
SMEs have never conducted a penetration test

What a penetration test really is – and what it is not

A penetration test is an authorised, controlled attack attempt against a system, network, application or physical infrastructure with the goal of identifying vulnerabilities and attack paths before a real attacker finds them.

That sounds straightforward. The precision lies in the details:

  • Authorised: A written engagement agreement is not a formality – it is the legal foundation. Without it, the same actions constitute a criminal offence under § 202a StGB (unauthorised access to data) in Germany.
  • Controlled: Scope, time windows and escalation paths are defined in advance. A pentest does not cause uncontrolled damage – that is a fundamental difference from a real attack.
  • The goal is the attack path, not the list: The value of a pentest lies not in the number of vulnerabilities found, but in the answer to the question: how far can an attacker get by combining these vulnerabilities?

A penetration test is not an audit and not a compliance check. It is an empirical proof of what a real attacker can do with your current security architecture – under controlled conditions, with a documented outcome.

The most important difference – and why it matters for your budget

No term is more frequently confused in IT security. The difference is fundamental – and directly affects what you actually get for your security budget.

Vulnerability Scan
Automated, fast, surface-level
Tool-based, runs largely automatically
Compares systems against known CVE databases
Says: "This vulnerability exists"
No human judgement, no context
High false-positive rate without manual validation
Affordable, repeatable, good for continuous monitoring
Penetration Test
Human-led, deep, context-aware
Human-led, tool-supported
Verifies whether vulnerabilities are actually exploitable
Says: "This vulnerability leads to your AD in three steps"
Human judgement, context, creativity
Finds logic flaws and configuration weaknesses with no CVE
More effort, higher cost, substantially deeper

When to use which – an honest decision guide

Both methods are useful – but for different purposes. A vulnerability scanner is not a poor man's pentest, and a pentest is not a better vulnerability scanner. They answer different questions.

  • Vulnerability Scan: Weekly or monthly as continuous monitoring. Quickly shows whether new known vulnerabilities have appeared in the infrastructure. Good for patch management and compliance reporting.
  • Penetration test: Periodically, on specific occasions or as a regulatory requirement. Answers the deeper question: can someone actually break in – and how far do they get?

An organisation that only runs vulnerability scans knows which vulnerabilities exist – but not whether they are exploitable, how they could be combined, or how far an attacker gets with them. That is the difference between a list of hazards and an attack scenario.

The full spectrum: not just networks

When people talk about a penetration test, most think of networks and servers. The spectrum is considerably broader – and depending on the threat model, entirely different test types may be relevant. All of our services can also be combined individually.

By target

By information level: Black Box, Grey Box, White Box

Black Box
No prior knowledge
The tester starts like an external attacker – without any knowledge of internal systems, architecture or credentials. Most realistic approach, but more time-intensive.
When: Realistic external perspective, red team preparation
Grey Box
Partial knowledge
The tester has limited information – e.g. a standard user account. Simulates an insider or an attacker after initial access. Most efficient approach.
When: Most corporate pentests, NIS2 compliance evidence
White Box
Full knowledge
The tester knows the architecture, source code and configuration. Enables the deepest coverage in the shortest time. Less realistic, but maximally efficient.
When: Code reviews, secure development, maximum depth on a tight schedule

Red Team Exercise vs. Penetration Test: where the line is

The second most common confusion after pentest and vulnerability scan. Both are legitimate security exercises – but with fundamental differences in scope, objective and insight.

Penetration Test
Defined scope, maximum vulnerability coverage
Clear, pre-defined scope
Days to weeks
IT team knows a test is taking place
Goal: find as many vulnerabilities as possible
Result: technical report with risk assessment
Red Team Exercise
No fixed scope, one concrete objective
No fixed scope – that is the point
Weeks to months
Only management knows – IT is the blue team
Goal: reach a specific objective (server room, file, system)
Result: full attack chain + detection capability assessed

The key difference: a penetration test answers "What vulnerabilities do we have?" A red team exercise answers "Would we notice a real attack – and could we stop it?" For NIS2 and KRITIS compliance, penetration tests are the direct evidence. For a mature security organisation wanting to test its detection capability, a red team exercise is the logical next step. Get in touch if you are planning a tailored red team simulation.

What happens during a penetration test – phase by phase

Many decision-makers hesitate to commission a pentest because they do not know what they are buying. Transparency about the process builds trust – and sets realistic expectations.

Phase 01
Scoping & Rules of Engagement
What is being tested, and what is explicitly excluded? Rules of Engagement define time windows, permitted methods, emergency contacts and escalation paths. A written agreement is mandatory – it protects both parties legally. No serious pentest is possible without clear scoping. In a free initial call, we define the scope together.
Phase 02
Reconnaissance
Passive and active information gathering about the target. OSINT from public sources, DNS enumeration, network scanning, employee profiling, technology fingerprinting. The more an attacker knows, the more targeted the attack – and the more efficient the test. More about our Reconnaissance & OSINT module. How OSINT becomes the most dangerous tool in physical pentesting – in the Remote Recon blog post.
Phase 03
Exploitation
Active exploitation of identified vulnerabilities – controlled and documented. No automated mass scanning, but targeted, manual exploitation with proof of concept. Every successful exploit is documented immediately.
Phase 04
Post-Exploitation
How far can an attacker get after initial access? Lateral movement (spreading through the network), privilege escalation (from standard user to domain admin), data access, persistence. Particularly in Active Directory pentests, this phase reveals whether a breach stays contained or leads to full compromise.
Phase 05
Reporting
Documentation of all findings with CVSS risk ratings, proof-of-concept screenshots, attack path descriptions and concrete remediation recommendations. A good report has two layers: executive summary for management and technical detail for the IT team. Download a sample report →
Phase 06
Retest
After remediation of the findings, the retest verifies whether the fixes actually work. Without a retest, no pentest is complete – claimed fixes and verified fixes are two different things. For NIS2 and KRITIS, the documented retest is the actual proof of compliance.

Where AI stands in pentesting – an honest assessment

Few topics are discussed more in the security industry right now, and few are assessed more poorly. The honest answer is nuanced: AI is changing penetration tests – it is not revolutionising them. For how we test AI systems themselves for vulnerabilities, see our AI Pentest module.

What AI can do today

AI can do this
Accelerate code analysis
LLM-powered tools like GitHub Copilot or Semgrep AI identify patterns in source code that indicate vulnerabilities – faster than manual review.
AI can do this
OSINT processing
Structure, correlate and prioritise large volumes of public data – what used to take hours now takes minutes. More about our Recon module.
AI can do this
Generate payload variants
Fuzzing and exploit variants based on known patterns – increases coverage for repetitive test tasks.
AI can do this
Report generation
Structuring and drafting findings from raw data – saves time in documentation.

What AI cannot do – and why that matters

AI cannot do this
Creative attack combinations
An experienced pentester combines a forgotten VPN rule, a weak contractor account and a misconfigured AD trust into an attack path. AI without context cannot replicate this.
AI cannot do this
Physical pentesting
AI has no hands. Triggering REX sensors, cloning badges, navigating a mantrap – that remains a human domain. More about our Physical Pentest. How a REX sensor attack works in practice.
AI cannot do this
Real social engineering
Manipulating a helpdesk employee in a live conversation requires empathy, improvisation and situational judgement. Deepfake voices are changing the picture – but the steering remains human. Our Social Engineering module.
AI cannot do this
Tester intuition
The sense that something is off – a configuration that is formally correct but opens a gap in this particular context. Experience-based judgement remains the decisive human factor.

AI makes pentesters more productive. It does not replace them. A fully AI-automated "pentest" is not a penetration test – it is a vulnerability scanner with a better UI. The value lies in human judgement, creativity in the attack chain and contextual understanding. That is not automatable in 2026.

What AI is changing on the attacker side – and why that matters for you

The other side of the AI equation is often forgotten: attackers are already using AI. Phishing emails have become linguistically flawless through LLMs – spelling mistakes as a detection signal are a thing of the past. Reconnaissance runs faster, code generation for exploits has a lower barrier to entry, and deepfake voices for vishing attacks are possible for under €200.

This means: the threat landscape is evolving faster than traditional security measures. A penetration test that does not account for how AI-assisted attackers operate today is no longer fully representative.

What to consider legally – short and clear

Many decision-makers have legal concerns about commissioning a pentest. Those are understandable – but fully resolvable with the right framework.

  • § 202a StGB – Unauthorised access to data: A penetration test without a written agreement is legally indistinguishable from an attack. The engagement letter is not bureaucracy – it is legal protection for both parties.
  • Scope definition as protection: What is explicitly in scope is authorised. What is not is not. A clear scope means clear legal standing – even if a tester inadvertently touches third-party systems.
  • Third-party and cloud systems: AWS, Azure and other cloud providers have their own penetration testing policies. Systems you do not own require separate authorisation.
  • NIS2 and KRITIS as legal trigger: For companies under NIS2 or the KRITIS umbrella law, a documented pentest is no longer optional. What that means in practice is covered in the compliance post.

Concrete triggers – for decision-makers still on the fence

After major infrastructure changes
New data centre, cloud migration, new network segmentation. Every major change creates new attack surfaces that did not exist before.
Infrastructure Pentest →
Before launching a new application
Fixing security gaps after launch costs ten times more. A pre-launch pentest is the most cost-effective form of secure development.
Web App Pentest →
After a security incident
A breach that has been investigated does not mean all gaps are closed. A post-incident pentest confirms whether the attack path has actually been remediated.
Get in touch →
NIS2 / KRITIS compliance
For companies in scope, a documented pentest is the most direct route to regulatory evidence. Claiming compliance is not enough – proving it is mandatory.
Read the compliance post →
Annually as a security cycle
The threat landscape, infrastructure and personnel all change. What was secure last year is not necessarily secure today. Annual pentests are not a luxury – they are basic hygiene.
Plan a regular pentest →
After critical personnel changes
Departing employees with privileged access – AD accounts, badges, API keys – are a commonly underestimated risk.
Read the orphaned accounts post →
Before M&A processes
Technical due diligence without a security assessment is incomplete. Security debt in an acquired company becomes your own liability.
Request an M&A pentest →
On request from customers or insurers
Cyber insurers and enterprise clients increasingly require a current pentest report as a prerequisite for contracts.
Download sample report →

Costs put honestly – no price list, but real reference points

The most-searched topic that almost no provider answers honestly. No serious pentest has a fixed price, because the effort depends on too many variables. But reference points are possible – and fair. After a free initial call, you will receive a transparent fixed-price proposal from us.

Factor Higher effort when... Lower effort when...
Scope Entire infrastructure, multiple sites, cloud + on-premise Clearly bounded single application
Information level Black Box – tester has to discover everything independently White Box – architecture and code are known
Test depth Post-exploitation, lateral movement, privilege escalation Surface-level scanning without manual exploitation
Test type Physical + Social Engineering + Network combined Single test type, clearly defined
Report depth Executive summary + technical report + presentation + retest Technical report without retest
Time pressure Short-notice engagement, evening or weekend work required Plannable engagement with sufficient lead time

A pentest that only runs automated tools and compiles the output into a report is not a penetration test – it is an expensive vulnerability scan. Price alone says little about quality. The relevant question is: how much manual effort from experienced testers is actually included in the proposal?

Conclusion: a penetration test is not a cost factor – it is an investment with measurable return

Implementing security measures is the first step. Knowing whether they hold up is the second – and in practice, that step is skipped surprisingly often. A penetration test closes this gap: it delivers an empirical assessment of the actual security posture, prioritises investments and, for NIS2- and KRITIS-obligated organisations, is the most direct route to regulatory evidence.

The question is not whether you need a penetration test. The question is whether you want to know what an attacker can do with your current infrastructure – before they find out themselves. Browse our full blog archive for further insights into specific attack vectors and security topics.

Ready for the next step?

Whether an initial scoping call or a concrete proposal – we guide you from scoping to completed retest.

Request a free initial call →
Tags // #Pentesting #CyberSecurity #CriticalInfrastructure #RedTeam #NIS2 #Penetrationtest #VulnerabilityScan

© AccessGranted X GmbH