Penetration Test Process — Seven Phases in Detail

A professional penetration test follows a structured methodology — not creative improvisation, but a documented process in seven phases. Clients who understand the process can formulate a better scope, set realistic timelines, and evaluate the final report more effectively. This article walks through each phase from the client's perspective — what happens, how long it takes, and what you need to contribute. It complements our Cybersecurity Guide for mid-market companies, which covers the broader context of NIS2, GDPR, and compliance.

The phases described here follow the Penetration Testing Execution Standard (PTES), the internationally established reference methodology. It is generic enough for web, API, infrastructure, and mobile audits, and is supplemented in practice with vertical-specific checklists such as OWASP or the OSSTMM control objectives.

Phase	What happens	Typical duration
1. Pre-Engagement	Scope, rules of conduct, contracts	5–10 days lead time
2. Intelligence Gathering	OSINT, asset discovery, tech stack	1–3 days
3. Threat Modeling	Attacker profiles, risk prioritisation	0.5–1 day
4. Vulnerability Analysis	Vulnerability identification	2–5 days
5. Exploitation	Controlled verification of findings	2–5 days
6. Post-Exploitation	Impact assessment, lateral movement test	1–3 days
7. Reporting	Executive summary, technical documentation, recommendations	3–5 days

Phase 1 — Pre-Engagement

The most important part of a pentest is not the technical work but thorough preparation. A poorly scoped pentest produces irrelevant findings, blows the budget, or — worse — causes unintended outages that nobody agreed to. In pre-engagement we work through four core questions with you.

What is being tested? We define in writing which systems, IP ranges, applications, URLs, API endpoints, or cloud accounts are included in the test. Equally important is the exclusion list: which systems are left out because they must remain continuously available, are operated by third parties, or legally cannot be in scope.

What is permitted? The rules of conduct specify whether destructive tests are allowed, whether phishing or social engineering are part of the engagement, whether physical site access is tested, and whether brute-force against login endpoints is permitted. For cloud providers such as AWS or Azure, the pre-approval process must also be observed.

When may testing occur? We agree on concrete time windows. Test activities against production systems are scheduled in maintenance windows outside business hours wherever possible. Peak trading periods, quarter-end closing, and product launches are explicitly excluded periods.

Who is reachable in an emergency? At least two emergency contacts, reachable around the clock, with mobile numbers and a backup. If unexpected behaviour occurs during the test — an application becomes unstable, a system hangs, a third party reaches out — we pause immediately and contact the emergency list.

From our practice: in at least every third project, pre-engagement already uncovers issues the client was unaware of — for example systems that have been running in the production environment for years with no one having access any more, or third-party service providers who should also be included in the test. This clarification alone often justifies the pre-engagement fee.

Phase 2 — Intelligence Gathering (OSINT)

In the second phase we collect publicly available information about the target organisation. The principle: whatever we can find through legal means, any real attacker can find too. This phase proceeds largely without touching the target systems.

Specific activities include subdomain enumeration via Certificate Transparency logs (crt.sh), DNS reconnaissance, WHOIS lookups, searching for accidentally public Git repositories and documents, identification of technologies in use (server headers, Wappalyzer analysis), employee profiles on LinkedIn and Xing for later phishing assessment, and a check against known data leaks.

This material produces an asset inventory — and very often the first surprise: subdomains unknown to the IT department, test servers reachable on the internet, old marketing microsites running outdated WordPress, or forgotten cloud accounts of former employees. In roughly two thirds of our engagements, this phase already produces findings that would have remained invisible for years without a pentest.

Phase 3 — Threat Modeling

Before we begin actual testing, we prioritise the attack surface. Not every system deserves equal attention — resources are limited, and a pentest must go deep where business risk is greatest.

We consider three dimensions: which realistic attacker profiles are relevant (opportunistic mass attackers, targeted competitive espionage, insiders, organised cybercrime), which assets would cause the greatest damage if compromised (customer data, intellectual property, business continuity), and which entry vectors are most likely given your technical setup.

The result is a prioritised risk matrix that sets the focus for the phases that follow. In a typical mid-market audit, the bulk of test time then concentrates on two to three prioritised attack paths — rather than allocating equal time to every system.

Phase 4 — Vulnerability Analysis

This is where actual vulnerability identification begins. We combine three approaches: automated scanners for breadth, manual testing for depth, and code review when source code is available.

Automated scans provide an initial overview of known CVEs in software in use, missing patches, and obvious configuration weaknesses. Depending on scope we select from Nessus, Qualys, OpenVAS, and our own custom checks from the Reepa Security platform — the latter find configuration issues that generic scanners do not cover.

Manual tests are the core. Here we examine business logic flaws, incorrect access controls between roles, privilege escalation paths, session management weaknesses, and input validation. These classes are not found by scanners — they require understanding of the functional logic of the application.

Code review supplements the black-box test in grey-box engagements. We examine critical paths (authentication, authorisation, encryption, file uploads, external integrations) in the source code and compare with observable behaviour.

Every finding is documented immediately: affected component, reproduction steps, technical classification (CWE mapping), initial risk assessment. This documentation is the basis for the later report — we do not write the report from memory at the end, but log live throughout the engagement.

Phase 5 — Exploitation

The term sounds dramatic; the reality is controlled and documented. In the exploitation phase we verify that the identified vulnerabilities are actually exploitable — because theoretical risk assessment and real-world exploitability are two different things.

Concretely: if a scanner reports that an application may be vulnerable to SQL injection, we perform a controlled, non-destructive test that either proves or rules out exploitability. Where exploitability is proven, we limit ourselves to a proof of concept — such as reading a single column from a database table — without actually extracting or manipulating real data.

This step matters because it separates theory from practice. A vulnerability scan report with 200 "critical" findings is frequently non-exploitable to a large degree — for example because an upstream web application firewall blocks the attack, or because the supposedly vulnerable function is not externally reachable at all. The exploitation phase reduces the finding set to what represents genuine business risk.

All activities are logged with timestamps and source IP. If a security incident occurs in your environment in parallel, you can distinguish our activities from real attacks.

Phase 6 — Post-Exploitation

Once initial access has been demonstrated, we assess what a real attacker could reach from that point. This phase answers the question "What does this vulnerability mean for our business?".

Specifically we examine: which data would be accessible (personal customer data? payroll records? intellectual property?), which downstream systems would be reachable (lateral movement from the web application into the internal network?), and what persistence opportunities exist (can an attacker remain in the system after the initial vulnerability is patched?).

In this phase too we act in a controlled manner. We do not extract real data — we document reachability. We do not install persistence — we demonstrate the theoretical possibility. This is a material difference from a classic red team exercise, which explicitly also carries out persistence and lateral movement — see our comparison Red Team vs Pentest.

The outcome of this phase is a realistic impact assessment per finding — not "theoretically this could be bad", but "for this finding, the following data access was demonstrably reachable".

Phase 7 — Reporting

The report is the deliverable you are paying for. A good pentest report addresses three different reading audiences, each with the appropriate level of detail.

Executive Summary — one page, for management and compliance officers. What risks exist, how critical are they in aggregate, what are the business implications, what is recommended. No technical details, no tool names, no logs. Instead, clear statements such as "eight of the twelve findings are remediable within four weeks; the remaining four require architectural changes with three to six months of lead time".

Detailed findings catalogue — a dedicated page per vulnerability with classification (CWE number, CVSS score), precise description of the affected component, reproduction steps (so your development team can verify the finding), impact assessment with concrete business reference, and a prioritised remediation recommendation.

Technical appendix — for operational IT staff. Logs of test activities, timestamps, tool versions, payloads used. This section allows individual findings to be traced after the fact, or specific questions to be followed up if anything is unclear.

We deliver the report encrypted (PGP or S/MIME) by email and in parallel via a password-protected download URL. On request a presentation of the findings at your IT leadership meeting is available — usually very valuable, as open questions are resolved much faster in a discussion than by email.

What you as a client contribute

A successful pentest is a partnership, not a brief thrown over the wall. What we need from you to run the engagement efficiently:

• A technical point of contact, reachable during the test phase with a short response time
• For grey-box tests: test accounts in all relevant roles, ideally dedicated pentest accounts with clear labelling
• Architecture documentation where available — data flow diagrams, interface overviews, authorisation concepts
• Notification to your hosting provider and cloud vendor that the test is taking place (prevents automatic blocking)
• Clear escalation paths for emergencies and for the final findings discussion

From our experience: the better the preparation, the greater the depth and the more valuable the result. Engagements where the client side is chronically unreachable produce measurably thinner reports — not because we could do less, but because open questions cannot be resolved in a timely manner.

After the pentest — what comes next?

The report does not mark the end, but the beginning. Three typical follow-on activities:

Remediation support. We assist your team in implementing the recommendations — either in an advisory capacity through code reviews or by directly implementing changes. For critical architectural recommendations we deliver concrete migration plans with intermediate steps.

Re-test. After the most important measures have been implemented, we specifically recheck the remediated findings. Ideally we issue a re-test report documenting the improvement status — a useful document for cyber insurance, compliance audits, or partner inquiries.

Continuous validation. Because vulnerabilities constantly emerge anew — through software updates, new applications, configuration changes — we recommend moving from the annual snapshot to continuous validation. Our Reepa Security platform takes on this role and delivers monthly actual-versus-target reports against the pentest baseline.

Treating the pentest as a one-time event leaves you with a document for the drawer. Using it as a starting point for continuous improvement gives you a measurably better security posture — and one you can demonstrate to insurers, regulators, and business partners. We explore this topic further in the Cybersecurity Pillar and in the detailed article on pentest costs and investment models.

Frequently asked questions