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.
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.
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. 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, Security on Demand (INR 9,999) is 4 hours of founder-led work that produces an honest assessment of what your security posture looks like and what to prioritize. Full refund if you do not continue. Comes off the price of the next engagement if you do.
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 S Kamat leads consulting and client work.