A bad pentest costs you twice. Once when you pay for it. Again when the breach, audit failure, or rejected enterprise security questionnaire reveals what it missed. Five questions, asked before you sign, separate the vendors who will find what attackers would actually use from the vendors who will run a scanner against your app and email you a PDF. This is the standalone expansion of the vendor-evaluation section in our Penetration Testing 101 pillar, with deeper treatment of each question, sample answers, and the red flags that tell you to walk away.
If you have already been through a low-quality pentest, you know the feeling. The report arrived. It listed twenty-three findings. Most were “missing security headers” and “outdated jQuery.” None of them were the access control bug that your enterprise customer’s security team found in their own review three weeks later. You paid for the engagement, you owe your developers time fixing irrelevant noise, and you still do not have a usable audit artifact. The next pentest you buy needs to not be that.
The five questions below are the diagnostic. Use them in the discovery call. Use them in the email thread. Use them in writing on the SOW. If a vendor cannot give a specific, concrete answer to each one, the vendor is not ready to be paid.
Why pentest quality varies wildly in the Indian market
The penetration testing market in India has a structural problem. The label “pentest” is unregulated. Anyone with Burp Suite Community Edition, a branded PDF template, and a website can sell what they call a pentest. The price floor in this market is roughly INR 30K to 50K for what a vendor will describe in their proposal as a “full pentest with report.” The price ceiling for the same descriptive language is INR 5L and above. Both ends of that range will use words like “comprehensive coverage,” “OWASP methodology,” and “experienced team.”
The actual delivery varies enormously. We have seen reports from the low end of the market that consist of:
- A Burp Suite Pro scanner export with the CVSS scores reformatted into a table
- A methodology section that is one paragraph copied from OWASP’s website
- No reproduction steps for any finding (just a CVE reference and severity rating)
- No retest, no remediation guidance, no business impact statement
- A cover page with the buyer’s logo and the vendor’s logo, sometimes with a meaningless seal
The cost of that engagement is not the INR 50K you paid. It is:
- The INR 50K wasted
- Your developers’ time triaging false positives and irrelevant findings
- The enterprise customer security team that reviews the report, recognizes it as scanner output, and sends it back asking for “a real pentest”
- The auditor (SOC 2, ISO 27001, DPDP) who flags the report as insufficient evidence of independent testing
- The actual access control or business logic bug that nobody tested for, which is still in production
The total cost can easily run 5 to 10 times the engagement fee, plus the opportunity cost of the time. The buyer protection is the discovery call before you sign. Ask the questions below.
Question 1: What methodology do you follow, and can you share a sample report?
This is the single most diagnostic question. It tells you whether the vendor has a repeatable testing process or is winging it per engagement.
What a good answer looks like
The vendor names a specific methodology with version: OWASP Web Security Testing Guide v5.0 for web applications, OWASP API Security Top 10 (2023) for APIs, OWASP Mobile Application Security Testing Guide for mobile, PTES (Penetration Testing Execution Standard) for general framework, NIST SP 800-115 for some regulated contexts. They can explain how that methodology shapes their day-by-day testing: reconnaissance on day one, authentication and session testing on day two, authorization testing on day three, business logic on day four, and so on. They share a sanitized sample report within a day of asking. The sample report’s methodology section is two to four pages and actually describes what was tested, not what could in principle be tested.
A specific reference point. The Cybersecify sample report is publicly available, has the methodology section spelled out, and shows the structure of findings. You can compare any vendor’s sample against that as a baseline for what a real audit-acceptable report looks like.
Red flags
“We follow OWASP.” Vague. OWASP is an organization that publishes many standards. Ask which OWASP guide, which version, and how it shapes their testing.
“We cannot share a sample report due to client confidentiality.” This is the most common dodge. Sanitized sample reports are an industry standard. Every credible firm shares one. Citing confidentiality on a sanitized sample means either the vendor has no sample worth sharing or their reports contain identifying information they cannot sanitize. Both are bad signals.
Methodology section in the sample is one paragraph of boilerplate. “Our testing follows industry best practices including OWASP and NIST guidelines” is not a methodology. It is marketing copy.
The sample report findings are all OWASP Top 10 categories with no business-logic findings. Every real engagement on a non-trivial application produces at least one business-specific finding. If the sample has none, the vendor either does not test for business logic or could not get one across the engagement.
“We use Burp Suite Pro” answered as if it were a methodology. Burp Suite is a tool. The methodology is what you do with the tool. Tools do not test, testers do.
Decision rule
If the vendor cannot share a sample report within 48 hours of asking, do not sign. If the sample report’s methodology section is generic or absent, do not sign. If the methodology answer is vague or boilerplate, ask for specifics. If specifics are not forthcoming, walk.
Question 2: Who actually does the testing, and what are their credentials?
The single biggest factor in pentest quality is the human running the engagement. Methodology, tooling, and process all matter, but the senior pentester’s judgment is what catches the business logic flaw that scanners and junior testers both miss.
What a good answer looks like
The vendor names the lead pentester. They share the lead pentester’s credentials. They confirm in writing that the named lead runs the engagement personally, not as a manager assigning work to junior staff. Credentials that signal real testing skill:
- OSCP (Offensive Security Certified Professional). 24-hour hands-on practical exam. Cannot be passed by memorization. The current industry baseline for manual exploitation skill.
- CompTIA PenTest+. Practical and theoretical coverage of scoping, testing, and reporting. A solid baseline credential when paired with hands-on experience.
- CREST CRT or CCT. UK-based, rigorous practical exams, recognized in enterprise and financial services especially in the UK, EU, and Singapore.
- OSWE (Offensive Security Web Expert). Advanced manual web exploitation. Less common, higher signal.
- M.Sc Cyber Security or equivalent. Foundational academic depth that complements practical certifications.
The vendor also confirms how the lead tester interacts with the engagement: does the lead scope it, run the core testing, and write the report? Or does a senior consultant scope it, junior testers run the engagement, and the senior reviews the report at the end? Both models exist. The first is what you want.
A reference point. At Cybersecify, every engagement is led by Rathnakara GN (Co-founder and CHO). His credentials are OSCP, CompTIA PenTest+, and M.Sc Cyber Security. He scopes the engagement, leads the testing, and writes the report. No handoff to junior staff. Our team page lists the team-level credentials. The Cybersecify firm-level credentials available to engagements include OSCP, CompTIA PenTest+, and the academic foundation. We do not pluralize these as “OSCP-certified engineers” because the firm operates founder-led, not as a body shop.
Red flags
The vendor will not name the lead pentester before contract signing. Often phrased as “we assign the best available tester based on engagement requirements.” Translation: you find out who runs your engagement after you have paid. The lead tester’s name should be in the SOW.
The team is presented in aggregate (“we have a team of 50 certified pentesters”) with no specification of who runs yours. You are not buying access to the team. You are buying the time of specific testers. Volume claims hide the senior-junior ratio and the actual seniority of the person on your engagement.
Junior-only delivery with a senior name on the proposal. A common pattern: the senior pentester is the firm’s marketing face, attends discovery calls, and is named in the proposal. Junior pentesters with 6 to 18 months of experience run the actual engagement. The senior reviews the report at the end. The senior does not have time to find the business logic flaws that only senior judgment catches. If the proposal names a senior tester, get in writing that the senior personally runs the engagement.
Claimed credentials without proof. Ask for the certification number. Verify on the issuing body’s public registry. OSCP holders are listed by name in the Offensive Security verification page. CompTIA PenTest+ holders can be verified through CompTIA’s certification verification tool. If the vendor cannot provide the certification number, the certification likely does not exist.
“We have CISSPs and CEHs on the team.” CISSP and CEH are not pentest credentials. CISSP is a management-level information security credential. CEH is a theoretical knowledge exam. Neither requires demonstrating hands-on exploitation skill. A team that lists CISSP and CEH heavily and OSCP not at all is not staffed for manual penetration testing.
Decision rule
If the lead pentester is not named in the SOW with verifiable credentials, do not sign. If the firm structure is junior-heavy with senior names used for marketing only, ask explicitly whether the senior personally runs your engagement and get the answer in writing. If the answer is no, the engagement is not what you thought you were buying.
Question 3: How do you handle business logic and authorization bypass testing?
This is the question that separates manual pentesting from scanner-with-a-report. Scanners do not test business logic. They cannot. Business logic flaws are unique to your application and require the tester to understand what your product does before they can identify what should not be possible.
What a good answer looks like
The vendor describes manual testing as the core of the engagement, with tool-assisted reconnaissance and bulk testing as a supporting layer. They give specific examples of business logic flaws they have found in previous engagements (sanitized to protect client identities): an IDOR (Insecure Direct Object Reference) where changing a numeric ID in the URL exposed another tenant’s data, a multi-step workflow bypass where skipping step 2 let users access step 3 without paying, a role-based access control flaw where a “viewer” role could access an “admin” endpoint by changing the HTTP method from GET to POST, a refund endpoint that could be called multiple times to refund the same charge repeatedly.
They describe an authorization matrix approach for role-based testing. For an application with three user roles (admin, manager, viewer), they test every endpoint with each role’s credentials to verify that the access control enforces the documented permissions.
They mention reading the product before testing. They look at the user-facing documentation, the API documentation if any, the marketing pages that describe what the product does, and the onboarding flow. This builds the mental model that lets them probe for business logic flaws.
Red flags
Heavy emphasis on scanner output as the primary deliverable. “Our scanner catches over 5,000 vulnerability types” is a feature of the scanner, not a feature of the vendor.
No specific business logic examples when asked. A vendor who actively tests for business logic flaws can describe several recent examples. A vendor whose answer is “we cover OWASP Top 10 including A01 Broken Access Control” is reciting a list, not demonstrating capability.
“We use Burp Suite Pro” as the answer. Burp Suite is the standard manual testing proxy. Using Burp is necessary but not sufficient. The question is what the tester does with Burp, not which tool they own a license for.
The methodology day-by-day breakdown allocates minimal time to manual business logic testing. If a 7-day engagement allocates 4 days to “automated scanning and review” and 1 day to “business logic and authorization,” the manual coverage is shallow. Manual testing should be the dominant time investment.
No discussion of authorization matrix or role-based testing approach for applications with multiple user roles. Multi-tenant SaaS applications with role-based access control require explicit authorization testing across the role matrix. A vendor who does not raise this when your application has multiple user roles is not planning to test it.
Decision rule
Ask for two or three sanitized examples of business logic findings from recent engagements. If the vendor cannot produce them, the vendor probably does not find them.
Question 4: What does your report include, and will it survive enterprise customer and auditor review?
The report is the deliverable. Everything else (the kickoff call, the testing, the daily standups if any) is the process that produces the report. The report is what your enterprise customer’s security team will read, what your auditor will reference, and what your investor’s technical advisor will assess. If the report does not pass those audiences, the engagement was a failure regardless of how good the testing was.
What a good answer looks like
The vendor describes the report structure:
- Executive summary (1 to 3 pages). Written for a non-technical reader. Summarizes overall security posture, count of findings by severity, key risk areas, and the highest-priority remediations.
- Scope statement. Lists exactly what was tested (URLs, IP ranges, API endpoints, application components) and exactly what was not tested (out-of-scope items, test accounts used, environments excluded). This is what auditors look for first.
- Methodology. Names the framework version. Describes the testing approach in enough detail that a technical reader understands what coverage was achieved.
- Findings detail. Each finding includes: title, severity (Critical, High, Medium, Low, Informational) with rationale, affected component, description, reproduction steps with exact HTTP requests and responses, business impact in plain language, remediation guidance specific to your codebase, references to CWE or OWASP categories.
- Risk ratings. CVSS where appropriate, but also qualitative ratings with rationale because CVSS alone does not capture business context.
- Remediation guidance. Specific to your stack. “Use parameterized queries” is generic. “In your Express.js handler at routes/users.js line 47, replace the string concatenation in the SQL query with a parameterized statement using the pg library’s query parameters” is specific.
- Retest section. Either included in the initial report draft or appended after retest. Confirms which findings were verified as fixed, which remain open, and any new findings discovered during retest.
- SOC 2 and ISO 27001 control mapping (if relevant). Findings mapped to the specific controls in the audit framework, so the report can be handed to the auditor as evidence with minimal additional work.
The vendor also confirms that the report has passed enterprise security questionnaires and audit reviews previously. Ideally they can name (with permission) one or two enterprise customer types whose security teams accepted reports as evidence.
Red flags
Report = scanner output plus a cover page. Twenty-three findings, all from the scanner, all with generic CVE descriptions, no reproduction steps beyond the scanner’s URL, no business impact, no remediation specific to your code. This is the most common failure mode at the lower end of the market.
No remediation guidance. “Contact your developer for remediation” is not remediation guidance. The pentester should provide specific guidance, often including code-level suggestions for the type of fix.
No retest section in the report structure. Means retest is either not included or treated as a separate engagement with separate pricing.
“Audit-ready” claim without specifics. Ask which audits, which auditors, and whether previous reports have been accepted as evidence in SOC 2 or ISO 27001 audits. Vague claims are marketing language.
Severity ratings without rationale. “High” with no explanation of why it is High versus Critical or Medium leaves the reader unable to evaluate the rating. Severity should be defensible.
Decision rule
Read the methodology section of the sample report in full. Read at least three of the detailed findings. Ask whether the report has been accepted in SOC 2 or ISO 27001 audits previously. If you do not understand the report, your auditor and your enterprise customer’s security team will not either.
Question 5: What happens after the report? Retest and remediation support.
The engagement does not end at report delivery. Your developers fix the findings. The fixes need to be verified. Questions come up during remediation. A vendor whose process ends at report delivery has not actually solved your problem.
What a good answer looks like
The vendor describes the post-report process:
Retest. The vendor retests after your developers fix the findings. One full retest is standard. Some vendors include two retest rounds (one full retest, plus a sanity check 15 days later). Retest produces an updated report confirming which findings are now resolved, which remain open, and any new findings introduced by the fixes.
Remediation guidance. The report’s per-finding remediation guidance is specific to your stack. The vendor remains available for clarification questions during the remediation window (usually 30 days post-report). Specific questions like “we are considering using a JWT library instead of session cookies for the auth fix, does that change the threat model?” should get a direct answer.
Post-engagement Q&A. A 30-minute call after the report delivery to walk through findings, answer questions, and align on priorities. Continued access for written clarifications during the remediation window.
Reference point. The Cybersecify Startup Plan (INR 74,999) includes one full retest within 30 days. The Growth Plan (INR 1,79,999) adds a second sanity retest 15 days after the full retest, to verify final fixes hold. Both plans include remediation guidance specific to your stack and post-engagement Q&A access. Details on the pricing page.
Red flags
Retest billed separately and expensively. Retest priced at 30 to 50 percent of the engagement fee turns the remediation cycle into a budget problem. You will be tempted to skip retest. Skipping retest leaves you unable to verify that fixes actually worked, which is the whole point of the remediation cycle.
No remediation guidance. “Refer to OWASP guidelines for remediation” is not guidance. It is a deflection.
Engagement ends at report delivery. No retest, no Q&A, no follow-up. Further help requires a new SOW. Common at firms running pentest as a high-volume factory model.
Retest scope limited to “verify the specific fix you implemented.” A real retest also checks that the fix did not introduce new issues, and that the underlying vulnerability is genuinely closed (not just hidden from the specific reproduction steps).
Decision rule
Confirm retest is included in the engagement price. Confirm at least one full retest within 30 days. Confirm continued availability for remediation questions during the fix window. If any of these are missing or billed separately at scanner prices, the engagement is incomplete.
3 questions to AVOID asking (signals you do not know the space)
These questions get asked frequently by first-time pentest buyers and signal to the vendor that you can be sold on the wrong things.
“Are you CERT-In empanelled?”
CERT-In empanelment is required only for specific use cases: government departments, public sector undertakings, banks, NBFCs, payment processors, certain critical infrastructure operators, and stock market intermediaries. For most private SaaS startups, including those selling to enterprise customers in India and globally, CERT-In empanelment is not a requirement. Asking for it when you do not need it filters out qualified vendors and increases your cost by 2 to 4 times. The detailed treatment is in the upcoming sibling article When you do not need a CERT-In empanelled pentest vendor.
The right question is: does my buyer (auditor, enterprise customer, regulator) specifically require CERT-In empanelment? If yes, filter on it. If no or unclear, do not filter on it.
“What CVE coverage do you have?”
CVEs are public, scanner-detectable vulnerabilities in known software components. Coverage of CVEs is a feature of the scanner, not the pentester. The actual value of a pentest is the business logic, authorization, and chained attack findings that scanners cannot detect. Asking about CVE coverage signals you want a scanner, which sets you up for a vendor whose value proposition is “we run lots of scanners,” which is exactly the failure mode in Question 3.
The right question is: how do you test for the vulnerabilities that scanners cannot detect?
“How fast can you finish?”
A non-trivial SaaS application takes 7 to 10 days of focused manual testing per scope. Anything significantly shorter usually means undersized scope or pass-through testing. Vendors who answer “we can do it in 3 days” are signaling they do not plan to do real manual testing. Treat speed as a yellow flag, not a green one.
The right question is: how many days of senior tester time will my engagement get, and what does the day-by-day plan look like?
India-specific buyer context
Pricing reality
The current India pentest pricing landscape for a Seed to Series B SaaS startup engagement (single-scope, 7-day delivery):
| Vendor type | Price range (INR) | Typical delivery |
|---|---|---|
| Low-end / scanner-with-report | 30,000 to 50,000 | Automated scan + cover page, no manual testing of consequence |
| Boutique founder-led | 75,000 to 1,80,000 | Manual testing led, senior pentester runs engagement, audit-acceptable report |
| Mid-market | 1,50,000 to 3,00,000 | Mixed senior + junior, varies by firm. Some are excellent, some are scanner factories with better packaging |
| CERT-In empanelled | 2,00,000 to 5,00,000 | Often includes empanelment compliance value for regulated buyers, premium pricing |
| Large enterprise (global firms) | 5,00,000 to 25,00,000+ | Enterprise scope, multiple testers, formal processes, often slower delivery cycles |
The lowest tier (INR 30K to 50K) almost always delivers a scanner export. The boutique founder-led tier (INR 75K to 1.8L) is where you find quality at SaaS startup budgets. Above INR 3L for a single-scope SaaS app, you are either buying empanelment-required compliance or paying for a brand premium.
Audit expectations
Indian SaaS startups commonly face these audit triggers, and the report needs to meet each one:
- SOC 2 (Type 1 and Type 2). The auditor expects evidence of independent pentest testing within the audit period. The report should include scope, methodology, findings, and remediation evidence. Most SOC 2 auditors will accept a quality boutique pentest report. Some will additionally ask for retest evidence to confirm critical findings were fixed.
- ISO 27001. Similar expectations to SOC 2. The auditor expects pentest evidence as part of the A.12.6.1 management of technical vulnerabilities and A.14.2.8 system security testing controls. Control mapping in the report makes the auditor’s job easier.
- DPDP Act compliance preparation. Especially for Significant Data Fiduciaries, independent audit evidence including pentest reports is part of demonstrating reasonable security practices. The DPDP rules are still being finalized; treat pentest reports as part of the audit-readiness file.
- RBI cyber audit. For payments, fintech, NBFCs, and banks. Often requires CERT-In empanelled vendor for the formal audit. Pentest reports for non-RBI purposes (customer audits, SOC 2) can come from non-empanelled vendors.
- Customer security questionnaires. Enterprise customers from financial services, healthcare, and government sectors send detailed security questionnaires. They typically ask for: most recent pentest report (or executive summary), pentest vendor name and credentials, frequency of testing, and remediation evidence for any critical or high findings.
Why the cheapest quote is usually a trap
The math:
- Cheapest quote (INR 40K), saves you INR 50K vs the boutique quote (INR 90K).
- Cheapest quote delivers a scanner report.
- Your enterprise customer’s security team rejects it. You lose the deal, or you delay the deal by 6 to 8 weeks while you procure a real pentest. Estimated lost deal value: INR 10 lakh to 1 crore depending on deal size.
- Or: your SOC 2 auditor flags the report as insufficient. You commission a second pentest. Total cost: INR 40K (wasted) + INR 90K (the real one) = INR 1.3L. Plus the audit delay.
- Or: the access control bug that the scanner missed gets exploited. Cost depends on the breach impact, but typically runs from INR 10L to INR 5 crore including notification, remediation, customer churn, regulatory fines, and brand damage.
The cheapest quote is rarely the cheapest outcome. The downside cases dwarf the price difference.
What Cybersecify says to each question
Concrete answers, in the same format you should expect from any vendor you evaluate.
Question 1 (methodology and sample report). We follow OWASP Web Security Testing Guide v5.0 for web applications, OWASP API Security Top 10 (2023) for APIs, and OWASP Mobile Application Security Testing Guide for mobile. PTES as the general framework for scoping, reconnaissance, and reporting. Our sample report is publicly available at cybersecify.com/sample-report/ without needing to ask. Methodology section is two pages and describes the day-by-day approach. The detailed methodology page explains the framework choices.
Question 2 (who tests and credentials). Rathnakara GN, Co-founder and CHO, personally leads every engagement. Credentials: OSCP, CompTIA PenTest+, M.Sc Cyber Security. No handoff to junior staff. Verified on the Offensive Security and CompTIA registries (we share certification numbers on request). Founder accountability means the person who scopes the engagement runs it and signs the report.
Question 3 (business logic and authorization). Manual testing is the core of every engagement. Tool-assisted reconnaissance using Burp Suite Pro and supporting tools, manual probing for business logic flaws including IDOR, multi-step workflow bypasses, role-based authorization matrix testing, and chained attack scenarios. Recent sanitized examples available on request. The API pentest methodology post describes the approach when API documentation is incomplete.
Question 4 (report contents and auditor review). Executive summary, scope, methodology, per-finding detail with HTTP request/response reproduction steps, business impact, severity rating with rationale, remediation guidance specific to your stack, retest section, and SOC 2 + ISO 27001 control mapping included in the Growth Plan. Reports have been accepted in SOC 2, ISO 27001, and DPDP-aligned audits, and in enterprise customer security reviews. Sample at /sample-report/.
Question 5 (post-report retest and remediation). Startup Plan (INR 74,999) includes one full retest within 30 days, plus remediation guidance and Q&A access during the fix window. Growth Plan (INR 1,79,999) adds a sanity retest 15 days after the full retest. Both plans include the Brand Protection Snapshot. Growth Plan adds SOC 2 + ISO 27001 audit prep evidence. Full breakdown on the pricing page.
Ready to evaluate? Book a 30-minute call or start with the Security on Demand 4-hour engagement (INR 9,999) if you want a focused diagnostic before committing to a full pentest.
Frequently asked questions
What should I ask a pentest vendor before signing? Ask five questions. What methodology do you follow and can you share a sanitized sample report? Who specifically will run my engagement and what are their credentials? How do you test business logic and authorization flaws beyond what scanners find? What does your report include and will it survive enterprise customer and auditor review? What happens after the report, specifically retest and remediation support? A vendor that cannot answer all five concretely is not a vendor you sign with.
What are red flags in pentest vendor selection? Refusal to share a sanitized sample report citing “client confidentiality” (sanitized samples are industry standard). Methodology section in the sample is one paragraph of boilerplate. Vendor will not name the actual testers who will work your engagement. Reports listed as audit-ready with no specifics. No retest included or retest billed separately at near-engagement cost. Pricing significantly below market (INR 30K to 40K for a 7-day pentest in India) almost always means automated scan with a cover page. Marketing leans heavily on CERT-In empanelment when your business does not need it.
How do I verify pentest vendor credentials? Ask for the lead pentester’s full name and certification numbers in writing before signing the SOW. Verify OSCP on the Offensive Security registry, CompTIA PenTest+ on the CompTIA verification portal, CREST on the CREST member directory. Cross-check their LinkedIn profile lists the same firm and certifications. Ask explicitly whether the lead tester runs the engagement or hands it off to junior staff.
Should I always pick the lowest-cost vendor? No. A bad pentest costs you the engagement fee, your developer time fixing scanner noise, the false sense of security between engagement and the next real test, and the audit failure or breach that the scanner missed. The total downside cost typically runs 5 to 10 times the engagement fee.
What does a real pentest report contain? Executive summary written for a non-technical reader, scope statement, methodology section naming the specific framework version, detailed findings each with reproduction steps and HTTP request/response evidence, business impact in plain language, severity ratings with rationale, remediation guidance specific to your stack, retest section, and SOC 2 or ISO 27001 control mapping if you asked for audit support.
How many days should a pentest take? A single-scope pentest for a non-trivial web app or API takes 7 to 10 calendar days from kickoff to draft report. Two-scope engagements take 10 to 14 days. Anything significantly shorter usually means undersized scope or pass-through testing. Ask the vendor to break down the days: scoping, reconnaissance, active testing, reporting, retest.
Community: Cyber Secify is a Community Partner for BSides Bangalore 2026. Bengaluru’s flagship community-driven cybersecurity conference (July 9, Sheraton Grand). 1200+ attendees, original research, hands-on tracks, women-led sessions. Includes 20% discount for our community.
Related reading
- What is penetration testing? 2026 startup guide (pillar)
- DAST vs pentest: why scanner output is not a security assessment (sibling)
- When you do not need a CERT-In empanelled pentest vendor (sibling)
- What a good pentest report looks like
- How to evaluate a penetration testing firm
- Sample pentest report
- Our methodology
Built for AI-first and API-first SaaS startups. Founder-led from Bengaluru. If you have a pentest decision to make and want a 30-minute walk-through of these questions applied to your specific situation, book a call with the founders or start with Security on Demand (INR 9,999, 4 hours, full refund if you do not continue).