How we run a VAPT engagement, day by day
Pulling back the curtain on a typical 10-day web-application VAPT - recon to retest, with the timeline that actually ships.
A lot of cybersecurity firms sell "pentest" as a one-word product. We don't. The word covers a wide range of work - and the difference between a useful engagement and an expensive PDF lives in the details of how it's run.
Here's what a typical 10-business-day web-application VAPT looks like at Black Vault - start to retest. No fluff, no surprises.
Day 0 - Pre-engagement
Before the timer starts, we lock down five things:
- Scope - explicit URLs, sub-domains, in-scope vs out-of-scope features, environment (staging vs prod), allowed test windows.
- Rules of engagement - what tests are off-limits (e.g. no DoS), VPN allowlists, test accounts, IP whitelist for our egress.
- NDA + MSA - signed before any traffic crosses.
- Single Slack channel - your eng lead, our test lead, daily standup async.
- Success criteria - what would make this engagement a "yes, we got our money's worth."
This usually takes two business days of email + one call. We don't start day 1 until this is signed off.
Day 1 - Reconnaissance
Quiet, broad, and almost entirely passive at first.
- DNS enumeration, subdomain discovery, TLS fingerprinting
- Public exposure search (GitHub, Pastebin, BreachForums) - looking for leaked secrets, old commits, dev URLs
- Tech-stack fingerprinting via header analysis + JS introspection
- Mapping the app surface - every route, parameter, role, authentication flow
We close day 1 with a content map - every endpoint discovered, classified by role/access level. This map drives everything else.
Day 2 - Authentication & session
Auth is where most apps have the cheapest critical bugs.
- Login flow analysis (rate limits, account-enumeration via timing or response variance)
- Session token cryptography review -
iat/expclaims, signing alg confirmation, key rotation - Password reset flow - link entropy, time-bound, single-use, account-binding
- Multi-factor: enrollment / bypass / fallback paths
- OAuth/SSO integrations - redirect-URI validation, scope creep
We log every finding with a CVSS pre-score and a one-line "what would this let an attacker do" sentence. No vague "session management weakness" - specifics or it didn't happen.
Days 3-5 - Access control & business logic
This is where senior testers earn their fee.
- IDOR / BOLA / BFLA - every endpoint that takes an identifier in the path, query, or body
- Privilege escalation - what does a
viewersee when theyPATCH? What does amembersee when theyDELETE? - Multi-tenant isolation - cross-tenant reads, cross-tenant writes, cross-tenant references in webhooks
- Business-logic abuse - coupon stacking, race conditions on payment hooks, negative quantities, decimal-precision tricks
Scanners can't find these. They take careful reading of the app + a hypothesis-driven test plan. We aim for 40-60 considered hypotheses per app, of which maybe 8-15 produce findings worth writing up.
Day 6 - Server-side & integration
- SSRF - every endpoint that takes a URL as input
- File uploads - content-type bypass, polyglot files, path traversal
- Server-side template injection
- XXE / SSTI / deserialization where applicable
- Third-party integrations: webhook auth, payment-callback validation, OAuth callbacks
Day 7 - Client-side & CSP
XSS, prototype pollution, postMessage abuse, clickjacking, CSP weaknesses, mixed-content, cookie scoping. Front-end risks frame how dangerous server-side bugs actually are - an IDOR plus a stored XSS isn't an IDOR, it's a worm.
Day 8 - Chaining
We stop hunting new bugs and start chaining the ones we have.
Two low-impact bugs that chain into a critical are worth more than five mediums sitting on the shelf.
Common chains we'll attempt: open-redirect → OAuth hijack, prototype-pollution → auth-bypass, SSRF → cloud-metadata → IAM credential theft, stored XSS → admin-panel takeover.
Day 9 - Reporting
The report has three audiences and three sections:
- Executive summary (2 pages) - what we found, what it means, what to fix first. Written for a CFO.
- Technical findings (~30 pages typical) - per-finding: CVSS, CWE, repro steps, screenshots, request/response samples, fix.
- Appendix - methodology, tools, exclusions, attestation page.
We write this section by section throughout the week, not in a panic on day 9. Day 9 is final-pass and proofreading.
Day 10 - Handover
- Live walk-through of every critical/high with your engineering team
- Slack channel stays open for clarifications
- Optional retest engagement available once you've patched - separately scoped, focused only on the findings being re-verified
What's not in a 10-day engagement
Being upfront about this matters more than the methodology itself:
- A 10-day web pentest does not cover infrastructure or cloud posture
- It does not include source-code review beyond the bits we can see
- It does not mean "we found everything" - it means "we tried hard for 10 days using current best practices"
The right next step depends on your stack. For an enterprise SaaS, the typical follow-up is an API-focused engagement and a cloud-posture review. For a fintech, it's adding social-engineering and red-team simulation. For an e-commerce, it's pre-Black-Friday operational hardening.
If you've read this far and want to scope an engagement: book a 15-minute call. We'll come back with a written scope inside 48 hours.
Keep reading
Recon
What an attacker sees on day one - an external recon walk-through
Before any exploit runs, an attacker spends a few hours mapping you. Here's what that looks like, with concrete commands.
SOC
Why we built our SOC on open source instead of buying SIEM-as-a-Service
Wazuh + Elastic + MISP + TheHive can outperform a commercial SIEM at one-tenth the cost - if you have the engineering discipline to run it.
Want this rigor applied to your stack?
15-minute call. We'll map your environment and ship a written scope inside 48 hours.