Most clients have never bought a penetration test before. The deliverable — a long PDF, sometimes a presentation — is the visible part. The invisible part is the process that produced it. Here's how we structure a typical engagement.
Day 0: Scoping
Before any testing starts, we run a 30–60 minute scoping call. We're trying to answer three questions: what assets are in scope, what threat model are we testing against, and what would success look like? The cheapest finding is the one we know to look for before we start.
We also confirm rules of engagement — testing windows, points of contact, what to do if we find something critical at 2 AM. Surprisingly often, the answer "call this person immediately" turns out to matter mid-engagement.
Days 1–2: Reconnaissance and mapping
We map the application. Every endpoint, every parameter, every dependency, every flow. For larger apps, this can take two days. We're not testing yet — we're learning what the app does and what it's supposed to do.
This phase is where business logic starts to make itself visible. The pieces that "feel weird" while mapping are the pieces we come back to during exploitation.
Days 3–8: Active testing
This is the main phase. We work through the test plan in priority order: authentication, authorization, input validation, business logic, infrastructure, third-party integrations. We test each as a senior engineer who's seen the bug before would test it — not as a checklist runner.
We also work in pairs. One tester finds an interesting behaviour; the other confirms and tries to chain it. This is where most of our high-severity findings come from.
Days 9–10: Triage and impact analysis
By this point, we have a list of findings. Triage is about translating "I can do this weird thing" into "here's what an attacker would do with it and how bad it is." A bug that lets you read another user's preferences is very different from one that lets you read their payment method, even though both look like the same class of issue.
Every finding gets a severity, a clear reproduction path, and a recommendation we'd actually be willing to defend in a meeting with your team.
Day 11–12: Report and handoff
The report is structured for two readers: the engineer who needs to fix the bug, and the executive who needs to make a budget decision. The technical sections include reproduction steps, payloads, and references. The executive summary is one page, in plain language, with risk implications and a remediation timeline.
We also include a section we call "what we tested and didn't find." It's an unusual section, but it's important — it's the only way to know what the test covered. A clean report means very different things depending on what was actually looked at.
The optional retest
For most engagements, we include a retest 30–60 days later. You fix the findings, we verify the fixes, and we issue an updated report. This is often the most-cited piece by clients during sales and compliance conversations — "we found these, we fixed these, here's the proof."
What you should expect from any pentest
You're hiring a person, not a tool. The right questions to ask any pentest provider are: who's actually doing the work, what's their experience, will they pair, and can you talk to them mid-engagement? If the answer to any of those is unclear, you're buying scanner output dressed up as a report.