Penetration testing, demystified: scoping, budgeting, and getting real value

The three approaches

Black-box

The tester is given only what an external attacker would have — the company name, perhaps a public IP range or web URL. Everything else (subdomain enumeration, technology fingerprinting, account creation) is done from scratch. This simulates an opportunistic external attack.

Pros: realistic adversarial simulation. Cons: a significant chunk of the budget is spent on reconnaissance the tester would skip if you'd just told them. Right call for red team exercises, not for standard application reviews.

Grey-box

The tester gets limited prior information: a low-privilege user account, an architecture diagram, staging credentials, a list of in-scope endpoints, perhaps OpenAPI specs. Reconnaissance is shortened, more time goes into actual testing. The most common choice for annual web/API/network engagements.

For most growing businesses, grey-box is the right default. You get realistic adversarial coverage without paying for two days of OSINT that produces information you could have handed over.

White-box

The tester gets full source code, infrastructure documentation, admin credentials, and architectural threat models. This is the highest-coverage option — testers can identify vulnerabilities by reading the code in addition to probing the live system. Often called "crystal-box" in some literature.

Right call when: pursuing higher-assurance certifications (FedRAMP, ISO 27001 high-impact systems, financial services), shipping a new flagship product, or after a security incident where you need maximum confidence the issue is contained.

The five test types

Web application penetration testing

OWASP Top 10 (2021) and ASVS 4.0.3 are the reference standards. Findings typically cover authentication, session handling, access control, input validation, injection, cryptographic implementation, and business-logic flaws. 5–10 days for a single-application test; multi-tenant applications take longer.

API penetration testing

Increasingly scoped separately from web app tests because APIs have a distinct threat model (OWASP API Security Top 10 2023). REST, GraphQL, and gRPC each require different tooling and approach. 3–7 days.

Internal & external network testing

External: tests your internet-facing infrastructure for misconfiguration, exposed services, and exploitable vulnerabilities. Internal: assumes initial foothold (often a Wi-Fi connection or compromised workstation) and tests lateral movement, privilege escalation, and Active Directory abuse. 5–12 days combined.

Cloud penetration testing

Active exploitation of IAM misconfigurations, exposed storage, serverless permissions, container escape paths, and overly permissive role assumption. Must follow the cloud provider's testing policy: AWS permits most testing without pre-notification since 2019; Azure requires authentication via the Microsoft Cloud Penetration Testing Notification Form for certain test classes; GCP permits testing of your own resources without notification. 5–10 days.

Red team / adversarial simulation

Goal-oriented testing — the goal is typically "exfiltrate this specific data" or "achieve domain admin within 14 days." Combines technical exploitation with social engineering, physical access, and patient long-term persistence. Most appropriate for organisations with mature detection-and-response capabilities who want to test the blue team, not just the perimeter. 4–12 weeks, USD 50,000–150,000+.

How to scope an engagement that delivers

Six items to nail down before signing:

1. What's the business question? "We're closing a USD 5m enterprise deal next quarter and need a recent pen test report." That's a different engagement from "we just rebuilt our authentication and want assurance it's sound."
2. What's in scope? Specific URLs, IP ranges, AWS account IDs, mobile app bundle identifiers. Be precise — out-of-scope incidents are the most common cause of mid-engagement disputes.
3. What's the time budget? Days of effort, calendar window, and re-test inclusion.
4. What's the methodology? Ask the vendor which standards they map to. A vendor who can't cite a methodology cites no methodology.
5. What does the report look like? Ask for a sample (sanitised, of course). If the sample is a 200-page wall of CVSS data with no business context, the engagement will be too.
6. Re-test policy. Critical and high findings should include a re-test within 60–90 days of the original engagement, at no additional cost.

Three vendor patterns to avoid

The scanner farm. A "penetration test" delivered by running Nessus, Burp Suite Pro, and a half-dozen other automated tools, then dumping the output into a templated PDF. The dead giveaway: every finding has a generic remediation paragraph, no proof-of-concept beyond a screenshot, and no business-context narrative.

The certification farm. A vendor whose primary differentiator is that they hold every certification known to humanity (CREST, OSCP, OSCE, OSEE, CISSP, CISA, etc.). Certifications are useful — they're not the same as competence. Ask for the CVs of the specific testers who will work on your engagement, not generic firm credentials.

The retainer trap. A vendor who insists on a multi-year retainer for "continuous testing" when what you actually need is two focused engagements per year. Continuous testing has its place; it's often sold as a margin-padding alternative to engineering investment in DAST and bug bounty.

What to do with the report

The report is the start, not the deliverable. The real deliverable is a remediated environment. Three steps post-engagement:

1. Walk-through call. Schedule a 60-minute call with the lead tester and your engineering team within a week of receiving the report. Walk through each critical and high finding, validate the reproduction steps, agree on owners and target dates.
2. Risk-ranked register. Export findings into your issue tracker (Jira, Linear, GitHub Issues). Tag with severity, owner, target close date. This becomes part of the live risk register.
3. Re-test the criticals. Within 60–90 days, the vendor should re-test critical and high findings. The re-test report is what you give to customers, auditors, and insurers — not the original.

Who needs what, when

• Pre-launch SaaS: white-box web + API test in the month before public release. USD 15,000–30,000.
• SOC 2 / ISO 27001 pursuit: annual grey-box on your primary product surface. USD 15,000–25,000.
• Major architectural change (new auth, new payment flow, new tenant model): focused grey-box on the changed surface. USD 8,000–15,000.
• Post-incident: white-box on the affected surface plus adjacent attack paths. Budget depends on incident scope.
• Enterprise procurement gate: a third-party pen test report from the last 12 months almost always satisfies; share the executive summary, not the full report.