Short answer. When evaluating API pentest vendors in 2026, the questions that matter are these. How do you test business logic and not just OWASP categories? What is the split between automated and manual work in your engagement? Can you show me a finding from your last engagement that required understanding what the customer’s product does? What does your retest process look like? And, if you are in India and a buyer might ask, what is your CERT-In empanelment status? Anything else (years in business, client logos, certifications) is signal, not selection criteria. The five above tell you whether the engagement will be a real pentest or an automated scan with a report.
A founder evaluating pentest vendors for the first time sees three to seven vendors in a week. Each pitch sounds similar. Each quote is in roughly the same range. The decision feels arbitrary. It is not. There are specific questions that separate vendors who will find what is actually wrong with your API from vendors who will run a tool and write a report.
This is the buyer-side checklist for evaluating API pentest vendors in 2026. The lens is a Seed-to-Series B SaaS founder, not a Fortune 500 procurement team. The questions are what we wish more buyers asked us.
The key questions to ask before hiring an API penetration testing provider
Ask these eight questions before you sign. Each one separates a real manual API pentest from an automated scan with a report. If a provider cannot answer one of them with a specific example, treat that as your answer.
- Manual vs scanner-only. What share of the engagement is manual exploitation versus automated scanning? APIs fail on business logic and broken object level authorization (BOLA and IDOR), which scanners cannot reach. A provider whose answer is “our platform does both” is usually thin on the manual half. Ask for the split as a number.
- Named, certified tester. Who runs my engagement, by name, and what are their credentials? OSCP is the current baseline for hands-on API exploitation skill. Get the named tester and credential written into the SOW, not a team-average count.
- Methodology and version. Which methodology do you follow for APIs? The answer should name the OWASP API Security Top 10 (2023 edition) and PTES, plus NIST SP 800-115 where a regulated buyer needs it. “We follow OWASP” without a named guide and version is marketing copy.
- Retest included. Is a retest included in the price, and within what window? A pentest without fix verification is half a service. A serious provider includes at least one full retest after your fixes at no extra charge.
- Report format for SOC 2 and customer security reviews. Will the report survive a SOC 2 auditor and an enterprise customer security questionnaire? Ask for reproduction steps (HTTP request and response), business impact in plain language, severity with rationale, and control mapping.
- Scope handling for large API surfaces. How do you scope a large, GraphQL-heavy, or undocumented API with many endpoints and webhooks? Ask how they prioritize when they cannot test every endpoint in the window, and whether they do scope discovery before quoting.
- Sample report availability. Can I read a sanitized sample report before signing? Sanitized samples are an industry standard. A provider who refuses on “client confidentiality” grounds either has no sample worth sharing or cannot sanitize their own reports.
- Founder-led vs BDR handoff. Does the person who scopes my engagement also run the testing and sign the report, or does a salesperson hand off to a junior tester after I pay? Junior-only delivery with a senior name on the proposal is a known failure mode.
At Cybersecify, both founders ship on every engagement. Rathnakara GN (OSCP, M.Sc Cyber Security) leads the API pentest delivery and writes the report, with no handoff to junior staff. The testing is manual-led against the OWASP API Security Top 10 (2023 edition) and PTES, both plans include one free retest within one month of the v1.0 report, and the sample report is public without an NDA. The sections below expand each question with sample answers and red flags.
Questions that do not actually matter much
Skip these. They look like diligence and are mostly noise.
“How many years have you been in business?” Pentest quality is a function of the tester on your engagement, not the firm’s incorporation date. A 10-year-old firm staffed with junior testers is worse than a 2-year-old firm with senior practitioners on every engagement. Ask who will actually be doing the testing.
“How many clients have you served?” Volume hides depth. A vendor with 500 clients on a junior-staffed factory model finds less than a boutique with 20 clients and senior testers in every report. The number tells you about the vendor’s sales engine, not their technical depth.
“Are you SOC 2 / ISO 27001 certified?” A pentest vendor having SOC 2 is a fine signal about their internal data handling, but it tells you nothing about their pentest quality. The actual pentest deliverable is what you are buying.
“Show me your client logos.” Logos are noisy. Some are paid testimonials, some are projects that went badly, some are stale. The logo of a name-brand company on a vendor’s site does not mean the vendor delivered a good pentest for them.
“What certifications do your testers have?” OSCP, CREST, CompTIA PenTest+ are good signals but cert-only filtering misses substance. A cert-holder on your engagement matters more than the firm-wide cert count. Ask which certified tester will be on yours.
These are not zero signal. They are just lower signal than what comes next.
Questions that matter
flowchart TD
A[Vendor proposal arrives] --> B{Methodology<br/>described?}
B -->|No| Z[Reject]
B -->|Yes| C{Scope discovery<br/>done before quote?}
C -->|No| Z
C -->|Yes| D{Retest included<br/>in price?}
D -->|No| Y[Push back]
D -->|Yes| E{Auth landscape<br/>asked about?}
E -->|No| Y
E -->|Yes| F[Strong candidate]
Y --> G{Vendor adjusts?}
G -->|Yes| F
G -->|No| Z
1. How do you test business logic vulnerabilities? Business logic flaws are the highest-impact findings in modern APIs: a refund endpoint callable multiple times, a workflow step skippable, an admin endpoint that depends on session state but only checks the bearer token. A serious vendor will describe how they read the product, build a model of the rules, and probe the gaps. A vendor whose answer is “we run our scanner and it finds them” is selling automation, not depth. See our breakdown of what agents can and can’t test for what this distinction looks like in practice.
2. What is your split between automated and manual testing? Honest vendors quantify this. “About 30 percent automated for coverage during discovery, 70 percent manual for business logic and chained-exploit analysis” is a real answer. “It’s all integrated, our platform does both” is marketing language that usually means the manual side is thin. Ask for the split and ask for the methodology document. If it is not written down, it is not happening.
3. Show me a finding from your last engagement that required understanding what the customer’s product does. This is the single most useful question. A real finding will be specific: “We discovered that the discount endpoint accepted a coupon code through both a query parameter and a request body. The API combined them additively, so the same coupon applied twice.” A pattern-only finding sounds like: “We found an authentication bypass via missing JWT verification.” The first one required product knowledge. The second one did not. You want vendors who can talk about the first kind.
4. What does your retest look like? Is it included or extra? A pentest without retest is incomplete. After you fix the findings, you need someone to verify the fixes actually worked and did not introduce regressions. A serious vendor includes retest within the engagement scope (usually a 30-day window after the initial report) at no additional cost. A vendor who charges separately for retest is unbundling for revenue, and the dynamic incentivizes them to find new things during retest rather than verifying old findings.
5. How do you handle scope discovery? Do you quote before or after? Vendors who quote before scope discovery are guessing. The quote will either be padded (to cover the unknown) or under-scoped (and they will renegotiate during the engagement). Vendors who do scope discovery first ask for your API documentation, sample request flows, and tenant structure before committing to a price. The discovery itself usually takes 30-60 minutes and should be free.
6. What is your reporting format and timeline? A real API pentest report has technical detail for engineers (reproduction steps, payloads, expected vs actual response) and an executive summary for board or investor circulation. Timeline matters: a 10-day engagement where the report arrives 3 weeks later is half a vendor. Ask for a sample report (sanitized) before signing. Most vendors will share one. If they refuse, that is data.
7. CERT-In empanelment status (India-only buyers). If you are an Indian buyer and you may have to file a cybersecurity incident with CERT-In under the 6-hour reporting rule, or if a government or regulated buyer asks for it, you need a CERT-In empanelled pentest vendor. If neither applies (most early-stage SaaS), empanelment is not a hiring filter. Empanelled firms tend to be larger, less founder-involved, and price 2-4x higher than boutique. Choose based on your actual compliance needs.
Questions about the engagement, not the testing
Most buyer checklists stop at methodology. The engagements that go wrong usually go wrong on the operational terms nobody asked about.
What goes into the SOW. Get eight things in the document: the named tester and credential, the scope written out literally (URLs, API base paths, environments) with exclusions stated, the methodology and version, the duration in business days, the retest terms including the window and the deliverable it produces, the report format and who you may circulate it to, the data-handling terms, and the payment split. A vendor who will not write the tester’s name and the retest window into the SOW is keeping the option to change both after you pay. Ours names Rathnakara GN, quotes 5 business days per scope, and includes one free retest within one month of the v1.0 report, returned as a v2.0 report rather than a status email.
Which environment gets tested. Ask what changes between production and staging. Production forces the tester to hold back anything that could break the live system, so fewer attacks get attempted. Staging allows harder testing, but only if it mirrors production on authentication provider, authorization rules, rate limiting and WAF posture, and has data realistic enough for business logic to behave normally. A staging copy with auth stubbed out is not a test environment, it is a demo. Agree the known differences and the destructive-test boundary in writing before day one, not while something is on fire.
What the vendor does with your data. Where evidence lives during the engagement, who inside the firm can reach it, what happens to it when the engagement closes, whether findings are reused in marketing and under what anonymization, and whether they will sign your NDA before scoping rather than after. Put the answers in the contract.
What happens when documentation does not exist. Ask how they build the endpoint inventory when the OpenAPI spec is missing or 18 months stale, which is the normal case. A usable answer names discovery as its own phase: proxy capture, frontend bundle inspection, introspection or schema inference where applicable, route extraction from source or a startup log, and probing for older API versions still resolving. Then ask what that does to the timeline and the price. We treat it as a timeline variable rather than a surcharge, and undocumented endpoints have produced a large share of the critical findings we have reported.
How to compare two quotes. Reduce each to price per scope and testing days per scope. Then ask whether report writing sits inside the window, whether the days are business days or calendar days, whether the retest is included, and whether the senior name on the proposal is full time on your engagement. Most price gaps between quotes are explained by one of those four, not by quality.
What the right answer sounds like
For comparison, here is what the right and wrong answers sound like to the methodology question.
Question: “How do you test for object-level authorization issues across tenant boundaries?”
Wrong answer (vendor selling coverage):
“Our platform automatically detects authorization issues by analyzing API responses for sensitive data patterns. We use machine learning to identify anomalies in access patterns.”
That is automation language. It does not describe how the test would actually find your specific tenant-isolation bugs.
Right answer (vendor with depth):
“We need two test accounts in your system, one per tenant. After you provision them, we capture requests from tenant A that return tenant A’s resources. Then we systematically modify resource IDs, parent references, and pagination cursors to attempt access to tenant B’s resources. We also test indirect access paths (tenant A’s user creating a comment on tenant B’s resource via shared identifiers). Most critical findings of this category we have shipped came from testing the indirect paths, not the obvious ID swap.”
The second answer describes a concrete workflow. The first describes a feature.
India-specific evaluation
Three things matter more in India that get less attention elsewhere.
Founder involvement. In a founder-led pentest firm, the most senior technical person on your engagement is also accountable for it. In a larger firm with delivery pyramids, the senior people pitch, junior people execute. For Series A SaaS, founder-led is usually the better fit because the engagement is small, the questions are nuanced, and a junior tester’s mistake compounds. Ask if a co-founder will be on your engagement and what their role will be.
Payment terms. Under the Indian MSME Act, buyer-vendor payment terms have specific rules. For a pentest engagement, 50 percent advance and 50 percent on delivery is standard and reasonable. 100 percent upfront is uncommon and transfers control to the vendor before they have delivered anything. 100 percent on delivery is more buyer-friendly but rare for first engagements where the vendor lacks trust signals. If the vendor proposes 100 percent upfront on a multi-week engagement, push back. The standard split exists for a reason.
DPDP-aware reporting. The DPDP Act is now enforceable. A pentest report that names PII categories vaguely is harder to file as part of your DPDP compliance evidence. Ask if the vendor’s report explicitly identifies the data categories at risk (PII, payment data, health information, etc.) and maps them to DPDP categories where relevant. This is a small thing in the report but a meaningful signal about whether the vendor is current with Indian regulation.
Red flags during evaluation
Three patterns to watch for.
The pitch is heavy on automation language with no explanation of manual testing. “Agentic.” “AI-powered.” “Continuous.” Usually means automation does most of the work and the human review is thin. Per our breakdown of what agents can’t test, automation alone cannot do business logic, chained exploits, or tenant isolation.
The quote arrives without scope discovery. A specific number from a vendor who has not asked about your API surface, tenant structure, or authentication model is a guess. The engagement will be padded (vendor side) or underscoped (your side). Either way, you renegotiate later. Better to do scope discovery first.
Payment terms ask for 100 percent upfront on a multi-week engagement. Standard split is 50/50. 100 percent upfront protects the vendor at the cost of the buyer’s negotiating position. If a vendor insists, ask why. The honest answer is “we have been burned by non-payers before.” Fine, but then negotiate for milestone-based delivery so you have recourse if quality slips.
What we recommend doing next
If you are mid-evaluation and want a sanity check on a vendor’s proposal, send us the scope and the quote (no NDA needed for a 30-minute review). We will tell you what is reasonable, what is missing, and what to push back on. No selling. No follow-up unless you want one.
If you are earlier in the process and want to understand pricing before talking to vendors, our pentest cost in India breakdown covers the realistic range with what each tier actually includes. Our pentest plans on /pricing/ show the fixed-scope tiers we offer for Series A SaaS, and our API pentest service page details the methodology we run. For a deeper read on what to look for in the actual report, how to read a VAPT report walks the structure.
If you want to start with a low-commitment diagnostic, book a free 30-min discovery call with the founders. We will assess your API security posture and recommend what to prioritize. No payment, no commitment.
Cybersecify is a Bengaluru-based founder-led cybersecurity consultancy serving AI-first and API-first SaaS startups in India. Both founders are on every engagement: Rathnakara GN leads pentest delivery, Ashok Kamat leads consulting and client work.