Penetration testing: the complete guide.
What a penetration test is, the main types, the full lifecycle, typical cost, and how it differs from vulnerability scans, bug bounty and red teaming — written by senior operators who have done nothing else for ~10 years.
- 1. What is a penetration test?
- 2. Why run penetration tests?
- 3. Types of penetration tests
- 4. Black-, grey- and white-box
- 5. The penetration testing lifecycle
- 6. Methodologies & standards
- 7. Common tools
- 8. What a good report contains
- 9. Pentest vs. scan, bounty, red team
- 10. Cost & effort
- 11. Choosing a provider
- 12. Compliance: ISO 27001, DORA, PCI DSS, BAIT
- 13. FAQ
What is a penetration test?
A penetration test — pentest for short — is an authorised, time-boxed security assessment. Experienced attackers try, under controlled conditions, to break into a system, application or network the way a real adversary would. The goal is not to list as many CVEs as possible, but to prove which weaknesses are actually exploitable — and what the impact would be if an attacker exploited them.
Done well, a pentest is not a compliance ritual — it is an honest calibration of your defence against reality. You end up with a prioritised report of findings, reproducible evidence, business impact and concrete remediation steps.
Why run penetration tests?
Find risk before the attacker does
Automated scans find known patterns. Humans find the chain of two medium findings that produces a critical compromise.
Compliance and audit evidence
ISO 27001, PCI DSS, DORA, BAIT / VAIT / KAIT and many customer contracts require regular third-party penetration testing.
Ship releases with confidence
Major releases and architectural changes are when most new attack surface is introduced — pentests catch it before go-live.
Calibrate your detection
If your SOC does not see the attacks in a test, it will not see them in a real incident. A pentest produces reproducible attack traces to test playbooks against.
What types of penetration tests exist?
Web application pentest
Attacks on auth, session handling, authorisation, injection, business logic, uploads, APIs. Methodology: OWASP WSTG and ASVS.
API pentest (REST / GraphQL)
BOLA / IDOR, mass assignment, rate limiting, auth bypasses, schema introspection. Methodology: OWASP API Security Top 10.
External network pentest
Everything reachable from the internet: perimeter assets, VPNs, exposed panels, mail, DNS, cloud edge. Focus on initial access.
Internal network & AD pentest
From a standard user (assumed breach) to Domain Admin: Kerberos attacks, ACL abuse, lateral movement, BloodHound path analysis.
Cloud pentest (AWS / Azure / GCP)
IAM misconfigurations, privilege escalation, cross-tenant access, unsecured buckets, exposed metadata services, CI/CD attacks.
Mobile app pentest (iOS / Android)
Reverse engineering, storage, crypto, IPC, deep links, certificate pinning, backend APIs. Methodology: OWASP MASVS / MASTG.
SAP pentest
RFC, SAP Gateway, web front ends (Fiori), authorisations (SoD), custom ABAP, AD integration. Rarely tested, high impact.
AI / LLM pentest
Prompt injection, indirect injection through data sources, tool abuse, data leakage, guardrail bypass. Methodology: OWASP LLM Top 10.
Physical / social engineering
Physical access, tailgating, badge cloning, phishing, vishing — usually a red-team module rather than a standalone pentest.
OT / ICS pentest
Control systems, segmentation, protocols (Modbus, S7, DNP3). Careful and largely passive — availability comes first.
Black-, grey- and white-box: what is the difference?
Black-Box
No prior knowledge, no account, no documentation. Realistic for external perimeter — but expensive and incomplete on complex applications.
Grey-Box
Default approach. Accounts across multiple roles, docs and an architecture overview. Best balance of realism and coverage.
White-Box
Full access including source code and design docs. Highest coverage, ideal for security-critical components and crypto review.
How does a penetration test unfold?
- 1. Scoping
What is tested, why, with which roles, in what time window, what is explicitly out of scope, who are the points of contact and emergency contacts. Output: Rules of Engagement (RoE).
- 2. Reconnaissance
Passive and active reconnaissance: subdomains, exposed assets, technologies, people, leaks. Goal: understand the attack surface and identify focus points.
- 3. Enumeration & vulnerability discovery
Manual analysis of every endpoint, parameter, role and flow. Automation only as support. Output: prioritised attack hypotheses.
- 4. Exploitation
Controlled exploitation of findings to prove exploitability and impact. No data exfiltration without approval, no availability impact.
- 5. Post-exploitation & lateral movement
What is reachable from here? Kerberoasting, ACL abuse, credential reuse, pivoting. Mapped to MITRE ATT&CK so detection teams can compare directly.
- 6. Reporting
Two parts: management summary with risks and recommendations, technical section with reproducible steps, payloads, affected assets and CVSS / business-impact rating.
- 7. Debrief & retest
Joint debrief with engineering and security. Once fixes ship: retest of critical and high findings so the remediation actually holds.
Methodologies and standards that matter
Web Security Testing Guide and Application Security Verification Standard for web apps.
Reference for API attacks (BOLA, mass assignment, auth).
Mobile Application Security Verification Standard and Testing Guide.
Attacks on LLM-based applications: prompt injection, tool abuse, data leakage.
Taxonomy for post-exploitation techniques — bridges pentest findings to detection logic.
Process framework for technical security testing — often cited in audit questions.
Penetration Testing Execution Standard — pragmatic end-to-end framework.
For threat-led testing of critical financial infrastructure — the basis for DORA TLPT.
Which tools are typically used?
Tools are a means to an end. The core work is understanding the application and attacking it manually. Typical arsenal:
Burp Suite Pro, Caido, ffuf, nuclei, sqlmap, Postman, mitmproxy
Nmap, masscan, Amass, Subfinder, Shodan, Censys
BloodHound, Impacket, Rubeus, Certipy, Kerbrute, Responder, NetExec (CrackMapExec)
Pacu, ScoutSuite, Prowler, CloudFox, Rusty Hog
Frida, Objection, MobSF, apktool, Ghidra
Cobalt Strike, Sliver, Mythic, Havoc — bei uns aus einer intern gehärteten Infrastruktur.
What a good pentest report contains
- Management summary framed as risk, not CVSS numbers.
- Scope, timeframe, accounts used, test depth and limitations — audit-ready.
- Findings with reproducible steps, requests / payloads and screenshots.
- Business impact per finding, not just CVSS. Two 6.0 CVSS findings can have very different consequences.
- Concrete remediation guidance — including patterns, not just 'update the library'.
- Attack path as a narrative: how did the tester go from A to Domain Admin?
- Appendix with raw data, requests, screenshots and a machine-readable findings list (JSON / CSV) for your risk register.
Pentest vs. vulnerability scan, bug bounty and red teaming
| Format | Goal | Depth | When it fits |
|---|---|---|---|
| Vulnerability Scan | Find known weaknesses | Automated, signature-based | Continuous, broad coverage |
| Penetration Test | Exploitable weaknesses in scope | Manual, chained, verified | Regular per system / release |
| Bug Bounty | Crowd-sourced findings over time | Broad, unstructured, variable | Complement to pentests on mature products |
| Red Teaming | Test detection and response | Objective-driven, threat-led, no warning | Mature security orgs, TIBER / DORA |
What does a penetration test cost?
We quote pentests per engagement based on scope, complexity and required depth — not per CVE. A focused web-app test with a single role model typically runs 8–15 person days, an internal AD test 10–20 person days, and a DORA TLPT attack several weeks including the threat-intel phase.
Quotes far below the market rate are almost always either automated scans with a manual cover page or run by juniors. Neither produces evidence that stands up to an audit or a board briefing.
How to choose a pentest provider
- Senior operators actually on the engagement — not juniors with a senior reviewer.
- Demonstrable experience in the relevant area (banking, energy, critical infrastructure, SAP, cloud, AI).
- Certified offensive infrastructure (ISO 27001, BSI IT-Grundschutz) for your test data.
- Sample reports you can review critically — structure, reproducibility, quality of statements.
- Clear rules of engagement, defined emergency contacts, clear liability and data clauses.
- Direct communication with the testers — no sales layer between you and the engineers on technical questions.
Pentests and compliance: ISO 27001, DORA, PCI DSS, BAIT
Regular penetration testing is an explicit or implicit part of nearly every relevant framework: ISO 27001 (A.8.29), PCI DSS (Requirement 11.4), BAIT / VAIT / KAIT for German financial institutions, DORA (Art. 24 f. threat-led penetration testing) and, increasingly, NIS2 for operators of essential services.
Important: a 'compliance-oriented pentest' is not a 'weak pentest'. A good report covers both — your real attack surface and the evidence your auditor cares about (scope, methodology, retest, ownership).
Frequently asked questions
What is a penetration test?
A penetration test is an authorised, time-boxed security assessment in which experienced attackers attempt to exploit real weaknesses in systems, applications or networks — with the goal of surfacing risks before real adversaries do, and documenting them so they can be remediated.
How does a pentest differ from a vulnerability scan?
A vulnerability scan is automated and reports potential weaknesses based on signatures. A penetration test is manual, verifies exploitability, chains findings together and evaluates real business impact.
How much does a penetration test cost?
Pricing depends on scope, complexity and depth. A focused web-app test typically starts in the low five figures; a full internal network or Active Directory test is materially higher. We quote per engagement, not per vulnerability.
How often should a pentest be run?
At minimum annually for critical systems, plus after every major release, significant architectural change and before production rollouts of new environments (e.g. a new cloud region or M&A integration).
What is the difference between a pentest and red teaming?
A pentest looks for as many findings as possible within a defined scope. Red teaming is an objective-driven, intelligence-led attack against the entire organisation — including people and processes — to test detection and response capability.
Which standards and methodologies are used?
We work methodically against OWASP WSTG and OWASP ASVS (web), OWASP MASVS (mobile), MITRE ATT&CK (post-exploitation), and NIST SP 800-115 and PTES for the overall process. TIBER-EU / DORA TLPT engagements follow the TIBER-EU Framework.
Ready for an honest penetration test?
Speak directly with a senior operator — confidential, no sales layer in between.