If you've ever asked a pentest company for a price and got "starts at $5,000" in reply 10 seconds later, you got a bad answer. You didn't get a quote. You got a sales reflex. The honest answer to "what does this cost" is "let's spend 30 minutes scoping it." Anything else is the vendor either over-charging to cover their own uncertainty or under-charging in a way that will quietly grow into change-order surprises once the engagement begins.
We have a checklist we work through on every scoping call. Seventeen questions, give or take a few follow-ups depending on the answers, that let us send back an accurate quote, a realistic timeline, and a scope document that won't drift mid-engagement. The call takes about half an hour. By the end of it we both know whether we're a good fit, and within 24 hours you have a quote you can take to your finance team without caveats.
This post is that checklist. If you're shopping for a pentest, you can read it as a preview of exactly what we'll ask you, or use it to evaluate other vendors who skip these questions. A vendor who quotes without asking most of these is guessing, and you'll pay for the guess one way or another.
Section 1: Scope
These five questions determine what surface area we're actually covering. Scope is where most pentest engagements quietly go sideways, so we lock it down first.
1. What is the URL of the application we'll be testing?
Sounds obvious. We ask because we need to confirm whether it's production, staging, or a dedicated test environment, and which one the client actually wants tested. We also need it to check accessibility from our IP block before the engagement starts. A target sitting behind a corporate VPN you forgot to mention can add a full day of setup.
2. Are there separate URLs for the API, admin panel, or B2B portal?
Many apps have a primary URL, but the real attack surface lives on api.example.com, admin.example.com, or partners.example.com. Each of those is its own application with its own auth flows. If they're in scope, the engagement is materially bigger. If they're explicitly out of scope, we want it in writing.
3. How many user roles exist?
Admin, manager, standard user, viewer, customer, vendor, super-admin? Each role multiplies the access-control matrix we have to test. Every role pair gives us another "can A read B's data" check to run. Roles count more than features for sizing the engagement; an app with 30 features and 2 roles is often smaller than an app with 10 features and 7 roles.
4. Multi-tenant or single-tenant?
Multi-tenancy adds an entire dimension to the test: confirming that one tenant cannot read, modify, or even enumerate another tenant's data. This is one of the highest-risk bug classes in modern SaaS, and finding it requires deliberate tenant-pair testing rather than incidental discovery. It adds time to the engagement, and we'd rather price that honestly than skip the work.
5. Anything you specifically want us to leave alone?
Third-party services you don't own (Stripe, SendGrid, Twilio), production payment flows, customer PII tables, certain destructive endpoints. We respect explicit exclusions, but they need to go in the scope document so neither side is surprised. "Don't run automated scanners against the SMS gateway" is a perfectly reasonable rule. We just need to know it on day zero, not day three.
Section 2: Technology
Knowing the tech stack lets us pick the right tools, prioritise the right bug classes, and avoid wasting your budget on payloads that can't possibly land on your framework.
6. What's the tech stack?
Django, Rails, Node, PHP, .NET? React, Vue, Angular, server-rendered? Which database, which auth library, which ORM? This shapes the bug classes we prioritise. A Rails app gets a different first-pass than a serverless Node API. Our methodology is stack-aware, and that starts on the scoping call.
7. Are you on AWS, Azure, GCP, or on-prem?
This affects what we look at incidentally (S3 misconfigurations, exposed metadata endpoints, weak IAM, public storage buckets) and whether we offer a combined web-plus-cloud engagement. Many clients don't realise their cloud posture is part of their web application's attack surface until we walk them through it.
8. Authentication mechanism: passwords, SSO, OAuth, SAML, OTP, MFA?
Authentication is where roughly 30% of our findings come from across our engagement history. We need to know how it's set up before quoting because SSO via SAML, an in-house password system, and OAuth-with-Google each demand different test sequences. MFA bypass attempts alone can be a full day of work if you're doing anything custom.
9. APIs: REST, GraphQL, gRPC, WebSockets?
Each API type calls for a different test methodology and toolchain. GraphQL especially needs introspection-aware fuzzing and per-field authorisation checks. WebSockets need their own session-aware proxying. If you have a mix of all four, we want to know on day one so we can scope each surface individually rather than lumping them together.
Section 3: Compliance and Reporting
The report is the deliverable. Knowing who it's for and what it has to prove changes how we document everything.
10. Why are you doing this pentest? Is a specific client requesting it?
This informs what the report needs to look like. SOC 2 evidence chain? ISO 27001 control mapping? PCI DSS attestation? Or simply "we want to know what's broken before we ship"? Each calls for a different report depth, a different executive summary, and sometimes a different deliverable format. We'd rather build the right report from day one than rewrite it after delivery.
11. Do you need a Letter of Attestation, and who is it being shared with?
We issue an attestation letter on every job by default, but if it's going to a specific overseas client, a procurement team, or an enterprise vendor-review process, we add their name and the engagement reference to the letter so it satisfies their checklist. Easier to do that upfront than to reissue letters later.
12. What's the timeline pressure?
"Report in 2 weeks or we lose the contract" is a very different engagement from "we have 6 weeks." Both are fine (we run engagements at both speeds) but they're scheduled, staffed, and sequenced differently. Telling us the real deadline lets us commit to a date instead of a hope.
Section 4: Engagement Logistics
The boring questions that decide whether the engagement runs smoothly or stalls on day two waiting for a test account.
13. When can we test: what hours, what days, anything off-limits?
Most clients prefer 9am to 8pm on weekdays. Some need us to avoid month-end billing runs, holiday traffic peaks, or the daily backup window. We log every active testing hour and share that log in the report, so the operations team can correlate any anomalies they saw with our actual activity.
14. Will you provide test accounts, or do we self-register?
For any authenticated testing we need at least two test accounts per role, three for multi-tenant work so we can prove cross-tenant isolation properly. If you're testing payment flows, we'll want real Stripe test cards or a sandbox configuration. Test accounts being slow to provision is the single most common reason engagements start late, so we flag it on the call.
15. Will your WAF or rate limiter block us, and can it be allowlisted?
We test with the WAF on, because it's part of your real defensive posture, and then again with the WAF off (or with our IPs allowlisted) so we can find the bugs underneath it. Both passes give a complete picture: the WAF-on view tells you what's exploitable today, and the WAF-off view tells you what's lurking if the WAF ever fails open. Coordinating the allowlist takes a day of lead time we want to start early.
Section 5: After the Test
The engagement doesn't end at report delivery. These two questions cover what happens next.
16. How will fixes be tracked, and when do you expect to re-test?
We include a re-test in every quote: your engineers patch, we verify the patches actually closed the issue. We need to know if you're patching same-week or same-quarter so we can schedule the re-test window rather than dropping it on someone's calendar with no notice. Some clients want a single re-test round; some want rolling re-tests as each fix lands.
17. Who at your company is the technical escalation contact during the test?
If we find something critical (and by critical we mean "all customer data is readable by an unauthenticated attacker" critical) we need somebody we can call within 30 minutes to escalate. Not the CEO. Not procurement. The senior engineer or security lead who can actually take action: pull the affected service, rotate a credential, or push an emergency patch. We agree on this name and number on the scoping call.
Why we ask these BEFORE quoting
A quote written without these answers is a guess. We've seen vendors send a $3,000 quote for what they thought was a 5-day pentest, when the actual app turned out to be a multi-tenant SaaS with six roles, a GraphQL API, a separate admin portal, and a B2B integration layer. Two weeks in, the same vendor was emailing change orders because reality had finally hit. The client paid more in the end and lost trust along the way.
We'd rather quote accurately the first time. That means a scoping call that feels almost like a mini-discovery session, because it is. By the time we hang up, we have enough information to write the statement of work, estimate the days, and tell you confidently which of our services are the right fit and which aren't worth the spend for your situation. The call protects you from surprise costs and protects us from underquoting work we've then committed to deliver. Both sides win.
What you should ask US back
A scoping call is a two-way interview. While we're learning about your application, you should be learning whether we're the right team to test it. Here are five questions you should ask any pentest vendor (us included) before signing anything:
- Who personally is doing the testing? Get names, not "our team." A pentest is only as good as the human running it, and you deserve to know whether that's a named senior tester or an anonymous junior on rotation.
- What certifications and track record do they hold? OSCP, OSWE, CRTO, Bugcrowd or HackerOne rankings, CVE credits, public writeups. Any of these are reasonable evidence the person has real skill.
- Show me a sanitised sample report. Reports vary enormously in quality. Ask to see one before you commit. If the vendor refuses or sends a slide deck instead, that tells you something.
- What's your re-test policy? Is it included? Time-bound? Capped at a number of issues? Re-test terms vary wildly and they affect the real cost of the engagement.
- Can you provide references from comparable clients? Not logos on a slide, actual contacts who'll take a 10-minute call to tell you what working with the vendor was like.
If a vendor can't answer those, you're not buying a pentest. You're buying a PDF. There's a difference.