Quick answer: a penetration test typically runs two to three weeks and moves through four phases, scoping and rules of engagement, reconnaissance, controlled exploitation, and reporting, ending with a severity-ranked report and a free retest once fixes are in place. Here’s what actually happens in each phase, based on how we run engagements.
Before anything starts: scoping and rules of engagement
The first conversation isn’t technical, it’s about boundaries. What’s in scope (specific IP ranges, applications, or a named set of employees for a phishing simulation) and what’s explicitly out of scope, what testing windows avoid your peak business hours, and who on your side needs to know testing is happening versus who should genuinely be kept in the dark, since a test that everyone’s expecting doesn’t tell you much about real-world response.
This stage also sets the rules for how far exploitation is allowed to go. We agree in writing whether we can pivot from one compromised system to others on the network, whether production data can be touched at all, and what an emergency stop looks like if something behaves unexpectedly. None of this is boilerplate, it’s the difference between a test that tells you something real and one that risks your actual operations.
Week 1: Reconnaissance
Before touching anything, we build a picture of what’s actually exposed: which subdomains resolve, which ports are open, what software versions are running, what shows up in public breach data for employee email addresses, and what an attacker could learn about your organization from what’s publicly indexed. A surprising amount of useful information for an attacker is sitting in plain sight, old subdomains nobody remembers, an admin panel indexed by search engines, or a job posting that names the exact software stack in use.
Week 1–2: Controlled exploitation
This is the phase people picture when they hear “penetration test,” but it’s the smaller half of the actual work. Every finding from reconnaissance gets tested to see whether it’s actually exploitable, not just theoretically weak, an outdated software version doesn’t automatically mean a working exploit exists, and part of the value of a real test versus a vulnerability scan is telling the difference.
For web applications, this follows an OWASP-based methodology: injection flaws, authentication weaknesses, access-control issues, and the rest of the Top 10, tested against your actual application rather than a generic checklist. For network testing, it’s about what a foothold on one system actually grants, can it reach systems it shouldn’t, extract credentials, or escalate to broader access.
What we don’t do
Within the agreed rules of engagement, we stop short of anything genuinely destructive, we’ll demonstrate that a vulnerability grants access to sensitive data without exfiltrating or altering it, and we’ll show that a foothold could pivot further without actually taking down a production system to prove it. The goal is evidence a business can act on, not a demonstration of damage for its own sake.
Week 2–3: Reporting
This is where a lot of testing providers fall short, and it’s the part we spend the most deliberate effort on. A useful report isn’t a 200-page dump of raw scanner output, it’s a severity-ranked list of findings, each one explained in terms of real-world business impact, with clear remediation steps your team can act on without needing a security background to interpret them.
- An executive summary in plain language, for whoever needs to understand risk without reading every technical finding
- Each finding ranked by real-world severity, not just a raw CVSS score with no context
- Proof-of-concept detail sufficient for your team (or ours) to verify and fix the issue, not so much detail that the report itself becomes a risk if it leaked
- Specific, prioritized remediation steps, not just “patch this system”
- A free retest once fixes are in place, so the report ends with confirmation, not just a list of open items
How often this should happen
Annually at minimum, and after any major infrastructure change, a new public-facing application, a cloud migration, or a merger all meaningfully change your attack surface. A test from eighteen months ago tells you very little about an environment that’s changed significantly since. See our Penetration Testing service for how we scope an engagement to your environment.