Back to blog

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.

Apr 12, 2026 7 min read Black Vault Security
VAPTMethodologyPentest

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/exp claims, 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 viewer see when they PATCH? What does a member see when they DELETE?
  • 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:

  1. Executive summary (2 pages) - what we found, what it means, what to fix first. Written for a CFO.
  2. Technical findings (~30 pages typical) - per-finding: CVSS, CWE, repro steps, screenshots, request/response samples, fix.
  3. 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.

Want this rigor applied to your stack?

15-minute call. We'll map your environment and ship a written scope inside 48 hours.