From signing the quote to retesting: how a pentest engagement works
A pentest is not an automated scan followed by an auto-generated PDF report. It's a structured engagement, with distinct phases, decisions made together, and support that continues well after the report is delivered.
Step one: defining the scope
Before signing anything, a 30-minute conversation defines what will be tested. Web application, API, network infrastructure, mobile app, the scope is precise. "All of the company's security" is not a scope: it's a surface impossible to cover seriously in a few days.
The quote defines the exact scope, duration, box type (black, grey, or white), and expected deliverables. Once signed, planning begins.
D-7: pre-engagement access checks
One week before the engagement starts, a verification is done: making sure the access defined in the scope actually works. Test accounts created? VPN configured? Staging environment reachable from outside?
This step seems trivial. But it prevents a common scenario: the tester starts the engagement, spends the first hours debugging access problems, and loses an entire day on a fixed-duration engagement, without a single test having been run.
Black box, grey box, or white box?
The level of information provided to the tester fundamentally changes the nature of the engagement.
Black box: no information beyond the target URL or IP. Simulates an external attacker with no prior knowledge of the organisation. Realistic, but limited in depth on a short engagement.
Grey box: some information: a standard user account, sometimes an overview of the architecture. The most common case. Simulates an attacker who has done their research, or a compromised account from phishing.
White box: full access: source code, documentation, architecture. Allows searching for vulnerabilities in business logic and code. Ideal for a code audit or complex API.
There's no universal answer. The right choice depends on what you want to test, your team's maturity, and the time available. A dedicated article breaks down this choice by context.
The pentest itself: looking for what shouldn't be there
A pentest has no step-by-step guide. There's no checklist to tick through in a fixed order. The objective is to find something that shouldn't exist (a vulnerability, a misconfiguration, a logic flaw), without knowing in advance whether it's there.
The work looks more like an investigation than a procedure: observing how the application behaves, forming hypotheses about what might be poorly implemented, running targeted tests to confirm or rule them out. Each finding shapes the next.
The most critical vulnerabilities are rarely the ones automated tools find. They live in business logic: behaviours the application wasn't supposed to have, but which are there because nobody anticipated that specific case. An attacker does anticipate it.
Everything tested is documented in real time: what was attempted, what was found, and how.
Writing the report with Cybreach Engine
The report is written during and after the engagement using Cybreach Engine, an internally developed tool. For each vulnerability, the documentation includes: technical description of the flaw, proof of exploitation (raw request, screenshot, result obtained), criticality assessed in real context (not just a theoretical CVSS score) and a concrete remediation recommendation.
The final report is structured in two parts: an executive summary for decision-makers (what was found, what the real risk is, what the remediation priorities are) and the full technical detail for the teams doing the fixing.
The debrief: walking through the report together
The report doesn't arrive by email without explanation. A debrief meeting is held, by video or in person, to walk through the most critical vulnerabilities, answer questions, and make sure the technical teams understand what needs fixing, in what order, and why.
This is often where the real questions emerge: "does this apply to our other environment too?", "we had a WAF, why didn't it block this?". These are useful questions. Answering them live, with the evidence in front of everyone, is more effective than back-and-forth emails.
3 months of post-report support
Delivering the report is not the end of the engagement. For 3 months, weekly availability is maintained: a short check-in, by video or message, to answer the technical questions that come up during remediation.
Developers have specific questions during remediation: "is this approach sufficient?", "if I change this, does it cover that case?". Being able to answer those questions in context prevents partial fixes, exactly the kind of pitfall described in our article on the empty session cookie.
Retesting is included: once fixes are deployed, every identified vulnerability is re-checked to confirm it is genuinely resolved, not just worked around or surface-patched.
Frequently asked questions
How does a pentest engagement unfold?
In distinct phases: scoping, access checks a week before, offensive testing, a detailed report, a debrief meeting, then a retest and post-report follow-up.How long does a pentest take?
The testing duration depends on the scope, typically one to five days, plus the upfront scoping and the post-report follow-up.Is a retest included after fixes?
Yes: a retest confirms that the fixed vulnerabilities really are fixed, as part of the post-report follow-up.
Further reading
A question after reading?
A question about how an engagement works or what would fit your context? Send a message, no strings attached.
Or book a 30-minute scoping call directly
Book a call →