Pentest engagement — execution

TL;DR: Executing a pentest is the disciplined middle of the engagement sandwich between pentest-proposal-and-scoping (the contract) and pentest-report-writing-deep (the deliverable). The work itself is roughly 60% testing and 40% communication: a clean kickoff, a daily cadence the client can trust, immediate “blast radius” escalation for criticals, and evidence captured the moment you find a bug so future-you can write it up without re-exploiting. This note covers the rhythm from kickoff call to draft delivery, including time budgeting across multiple assets, Jira/ticketing integration, and the tooling baseline that keeps you out of trouble.

Why it matters

Most failed engagements are not failures of skill — they are failures of execution. Common rot:

Silent weeks. The client hears nothing for ten days, panics, and escalates to your account manager. Trust is now negative even if you find a beautiful RCE on day eleven.
Lost evidence. You popped a shell on Tuesday, the box was patched on Thursday, and your screenshot folder is empty. Now the finding is “trust me, it worked.”
Critical sat on. A reachable unauthenticated RCE was found Monday morning, mentioned in a daily on Friday, and exploited by a real attacker Wednesday. The post-mortem will eat you.
Scope drift. You “just checked” a subdomain that turned out to be a third party. Welcome to a CFAA conversation.
Report shock. Client sees the report and is surprised by every finding, because nothing was previewed during testing.

Execution discipline — kickoff, cadence, escalation, evidence, scope hygiene — is what separates a deliverable from a lawsuit. Pair this with demonstrating-impact, disclosure-and-comms, and testing-methodology-checklists.

Kickoff call

The kickoff is a 30–60 minute meeting on day zero or day one. Goals:

Confirm scope, in writing, again

Re-read the SoW out loud. Confirm:

IP ranges, domains, mobile bundle IDs, repo URLs, AWS account IDs.
Out-of-scope assets explicitly. Third-party SaaS, shared infrastructure, prod vs staging.
Test windows (24/7? business hours only? change-freeze dates?).
Allowed techniques (social engineering? physical? DoS testing? credential stuffing?).
Data handling: can you exfiltrate sample data to prove impact, or stop at directory listing? See demonstrating-impact.

Establish comms channels

Primary: dedicated Slack/Teams channel with the client’s security team. Keep it.
Secondary: email distribution list for daily/weekly status.
Escalation: named on-call person + phone number for criticals. Write it down.
Ticketing: how findings flow into the client’s Jira/ServiceNow. Get the project key, issue type, required fields, and a test ticket creation done live on the call.

Logistics

VPN credentials, test accounts (one per role), allowlisted source IPs.
Confirm SOC awareness — do they know testing is happening, or is this a stealth assessment (purple-team-feedback-loop)?
Confirm a “stop test” word/signal in case prod breaks.

Day-by-day cadence

A typical 2-week web app engagement looks like:

Day 1 — Recon and access verification

Confirm every in-scope asset is reachable from your test environment.
Confirm every test account works and roles are correct.
Begin passive recon, surface mapping (expanding-attack-surface, getting-feel-for-target).
Send first status update by EOD. Even if it is “kickoff complete, access confirmed, recon started.”

Days 2–4 — Broad sweep

Run methodology checklists across the surface (testing-methodology-checklists).
Authenticated and unauthenticated passes.
File low-hanging findings into your tracker as you find them.

Days 5–7 — Depth on interesting targets

Pick the 3–5 most promising chains and go deep.
This is where SSRF, request smuggling, business logic, auth bypass live (ssrf, http-request-smuggling).

Days 8–10 — Chain, escalate, prove impact

Combine medium findings into critical chains.
Demonstrate impact concretely — pivot, exfil sample, escalate role (demonstrating-impact).

Days 11–12 — Cleanup and report draft

Verify every finding still reproduces.
Capture missing screenshots.
Draft report in parallel (pentest-report-writing-deep).

Day 13 — Internal QA

Day 14 — Deliver draft + readout call

Adjust ratios for engagement length, but the shape holds: recon, sweep, depth, chain, prove, write.

Status updates

Daily status (short)

Sent end-of-day via Slack or email. Three sections:

Today: what was tested (assets, areas).
Findings so far: count by severity, no details unless critical.
Tomorrow: plan.

Five lines. Not a novel. Clients want to know you exist and are working.

Weekly status (longer)

Sent end-of-week. Includes:

Coverage map (what % of scope tested, what remains).
Findings table with titles + severities (no full writeups yet).
Blockers (access issues, environment instability).
Risks to timeline.

Immediate “blast radius” escalation

If you find any of these, you stop testing the issue and call the client within minutes, not hours:

Unauthenticated RCE on internet-facing asset.
Mass PII or credential exposure (open S3, exposed DB, leaked secrets in public repo).
Authentication bypass affecting all users.
Active compromise indicators — you find an actual attacker already inside.
Critical chain that, if discovered by an adversary now, would cause material harm.

Script for the call: “We found X. Reachable from Y. Impact is Z. We have stopped further exploitation. You should consider patching/blocking/rotating immediately. We will send a one-page write-up within the hour for your IR/ops team.” Then send the one-pager. Then keep testing other areas. See ir-from-source-signals for what the client side of this looks like.

Evidence collection discipline

The rule: capture everything the moment you find it, because the environment will change.

Per-finding evidence folder structure:

findings/
  F-001-ssrf-internal-metadata/
    request.http
    response.http
    screenshot-01-burp.png
    screenshot-02-metadata-response.png
    notes.md
    timeline.txt

What goes in:

Raw request and response (Burp save-item, curl -v output).
Screenshots with timestamps and URL bars visible.
Video for multi-step or timing-dependent issues.
Commands run, copy-pasted exactly.
Source IP and user-agent used.
Account context (which test user, which role).
Reproduction notes — exact prerequisites, environment state.

Store evidence in an encrypted, access-controlled location per the SoW. Do not put client data in personal Dropbox.

Reference h1-disclosed-report-reading-method and reading-public-pocs-effectively for what good evidence looks like.

Time management across multiple assets

When scope is wide (10+ apps, large network range), allocate explicitly:

Tier-1 assets (crown jewels, primary product) — 60% of time.
Tier-2 assets (supporting apps, internal tools) — 30%.
Tier-3 assets (marketing sites, low-value) — 10%.

Use a coverage spreadsheet with one row per asset and columns for: recon done, auth tested, common bugs checked, business logic tested, evidence captured, report draft written. Update daily. This is also what you show in the weekly status to prove coverage.

If you find a deep rabbit hole on a tier-3 asset, timebox it. One hour max, then back to plan. Note it in the report as “area for follow-up.”

Client ticketing integration (Jira)

Many mature clients want findings as Jira tickets, not just a PDF.

Setup on kickoff

Get the project key (e.g., SEC).
Get the issue type (often a custom “Vulnerability” type).
Get required fields: severity, CVSS, affected asset, CWE.
Get the workflow: New → Triaged → In Progress → Fixed → Verified → Closed.
Get API token + permission to create issues, or a service account.

Per-finding flow

Create Jira ticket as soon as finding is confirmed (don’t wait for report).
Include short repro steps and one screenshot in the ticket body.
Link the ticket ID back into your tracking spreadsheet and final report.
The full writeup lives in the PDF/markdown report; the ticket is the work item.

Retest flow

When the client marks tickets “Fixed,” you retest, attach new evidence, and transition to “Verified” or back to “In Progress” with notes. Build this into the engagement timeline if retest is in scope.

Tooling baseline

Per-engagement baseline that travels with you:

Burp Suite Pro with a clean project file per client. Save the project file daily.
VS Code for notes, scripts, report drafting.
Obsidian or similar for finding tracker with templates.
ffuf / feroxbuster for content discovery.
nuclei with up-to-date templates for known-CVE sweeps.
httpx, subfinder, amass for recon (expanding-attack-surface).
A VPN kill-switch so your home IP never touches scope by accident.
Tmux + asciinema for terminal session capture as evidence.
A separate browser profile per client (Firefox containers or Brave profiles).
Encrypted disk (LUKS / FileVault) on the laptop, full stop.

See building-a-research-home-lab for the broader environment.

Workflow to study

Run a personal “mock engagement” against a Hack The Box ProLab or a self-hosted lab (htb-machine-walkthrough-methodology, building-a-research-home-lab).
Time-box it to 5 working days. Pretend a fake client exists.
Send yourself daily status emails. Write them as if to a real client.
Capture evidence for every finding as if for a real report.
At the end, write a full report (pentest-report-writing-deep) and Jira-style tickets for each finding.
Look back at what slipped: missing screenshots, fuzzy repro, scope drift, missed criticals.

The gap between “I found the bug” and “I delivered a defensible finding” is the entire job.

References

https://owasp.org/www-project-web-security-testing-guide/
https://www.pcisecuritystandards.org/document_library/
https://www.crest-approved.org/membership/penetration-testing/
https://csrc.nist.gov/pubs/sp/800/115/final
https://www.sans.org/white-papers/33343/
https://portswigger.net/burp/documentation/desktop/penetration-testing