SOC 2 Penetration Test: What You Actually Buy in 2026

You buy a defined number of scopes, a fixed number of testing days, a report, and a retest. That is the whole product, and every other difference between vendors is a variation on those four. A scope is one testable system with its own authorization logic, so a web application and the API behind it are two scopes rather than one. Testing days are what the tester spends inside your systems. The report is what your auditor reads, and it needs a scope statement, findings with severity and reproduction steps, and a mapping from each finding to the Trust Services Criteria it evidences. The retest is what closes Critical and High findings before an auditor sees them. At Cybersecify the SOC 2 answer is the Growth Pentest at INR 1,79,999 plus taxes: two scopes, ten business days, SOC 2 and ISO 27001 evidence mapping, a Letter of Attestation from the lead tester, twelve founder-led consulting hours, and one free retest.

Published Indian pricing for a SOC 2-usable pentest sits between roughly INR 50,000 and INR 3,00,000 for the common startup scopes, and the spread is mostly about how much of the work is manual. Below about INR 1,00,000 you are usually buying scanner output with a cover page, which auditors frequently reject because it shows no evidence of a qualified human testing business logic. Cybersecify publishes two prices and does not quote outside them for standard scopes: Startup Pentest at INR 74,999 for one scope over five business days, and Growth Pentest at INR 1,79,999 for two scopes over ten business days. Growth is the SOC 2 plan because it is the one carrying the Trust Services Criteria mapping and the Letter of Attestation. A team in Berlin or San Francisco pays what a team in Bengaluru pays for the same scope.

Growth is the SOC 2 plan, and the difference is not the number of scopes. The Startup Pentest at INR 74,999 covers one scope over five business days with a full technical report, CVSS severity per finding, and one free retest, which is a real penetration test by any standard. What it does not carry is the SOC 2 and ISO 27001 evidence mapping or the Letter of Attestation, and those two items are what an auditor and an enterprise reviewer actually read first. There is also a scoping reality: most SaaS companies present a web application and an API as separate attack surfaces with separate authorization logic, so one scope rarely covers the boundary named in a SOC 2 system description. If your system description genuinely names one system, ask us and we will say so.

No. The AICPA does not require a penetration test for SOC 2, for Type 1 or Type 2. This matters commercially because several vendors sell the test as mandatory. What is true is that auditors commonly accept a pentest as evidence for CC7.1 and CC7.2, and that arriving at a Type 2 without one is frequently flagged as a gap. The practical consequence is that your auditor, not the AICPA, sets the bar, so ask them in writing what they accept before you buy anything. Ask three questions specifically: whether scanner output is acceptable, how recent the report must be, and whether testing by your own engineering team satisfies independence. The answers differ between audit firms more than most buyers expect.

Testing is the short part. One scope is five business days and two scopes are ten, with report writing inside that window rather than after it. Scopes run sequentially by default, so each additional scope adds five business days. Parallel testing is something you can request on the Growth plan from the third scope onward, and it is an option rather than a guarantee. What actually sets your date is everything around the testing: the quote, the NDA, the statement of work, the proforma invoice, the fifty percent advance, and access verification, which is the step engagements most often stall on. Then your own remediation cycle, then the retest. Six to eight weeks from first contact to a complete evidence package is the realistic plan, and booking eight to ten weeks before your audit is the safe version of that.

Four things, and the rest is supporting material. A scope statement naming exactly what was tested, so coverage can be checked against your SOC 2 system description. Findings with severity, reproduction steps and business impact, which is what evidences CC7.1. A mapping from each finding to the Trust Services Criteria it speaks to, which is what stops your auditor doing that translation themselves and getting it wrong. And a retest report confirming which findings are closed, which is what keeps an open Critical from becoming a reported control deficiency. Our published sample report shows all four in the shape we deliver them, so you can judge the deliverable before a scoping call rather than after a purchase order.

CC7.1 and CC7.2 directly, plus several others when the matching testing is in scope. CC7.1 covers vulnerability detection and is the primary home for a pentest report. CC7.2 covers anomaly monitoring. CC6.1 is supported when authentication and authorization testing is in scope, CC6.3 when the test covers role-based access and least privilege, which is where IDOR findings land. CC8.1 is supported by the retest, because a verified fix is change management evidence. CC4.1 covers ongoing and separate evaluations, and an independent third-party test is a separate evaluation by definition. Map each finding to the specific criterion in the report rather than asserting coverage in a summary paragraph, because the mapping is the part the auditor uses.

For SOC 2, almost never. Auditors generally expect an independent third party, and testing by the team that built and operates the systems does not satisfy the independence expectation behind CC7.1. This is worth separating from the PCI DSS position, where v4.0.1 does permit a qualified internal resource but still requires organizational independence of the tester, which most in-house teams fail on the second condition rather than the first. There is also a practical problem separate from the compliance one. Your own team knows the intended design, and a penetration test is largely about finding the gap between intended design and actual configuration. Internal scanning is useful evidence alongside an annual third-party test, never as a replacement for it.

An open Critical or High finding at audit time becomes a control deficiency your auditor has to report, which is the outcome the retest exists to prevent. Three routes out. Close them before evidence submission and have the retest confirm it, which is why our retest triggers as soon as your fixes are in rather than on a fixed calendar date. Document a formal risk acceptance signed by management for anything you genuinely cannot fix inside the window. Or show a documented remediation plan with a target date the auditor can monitor. The first is the only one that leaves you with a clean evidence package, and it is the reason we tell buyers to book eight to ten weeks out rather than two.

It is included in both plans, it is not a separate purchase, and it is not conditional on anything. The timing has two halves that both matter. One month from delivery of the v1.0 report is the outer bound, not a waiting period, and we retest sooner when your fixes are in sooner. The retest itself takes one to three business days. The deliverable is a v2.0 report, meaning a full report that supersedes v1.0 with updated status columns and fresh per-finding evidence of the fixed state, rather than an addendum stapled to the original. That distinction matters to an auditor, because an addendum asks them to reconcile two documents while a v2.0 is one document that stands on its own.

No. SOC 2 is an AICPA attestation standard and has no relationship to CERT-In empanelment, which is an Indian government panel relevant to specific regulated categories such as certain RBI, SEBI and Critical Information Infrastructure engagements. We are not CERT-In empanelled and we do not claim to be. If your buyer or regulator names CERT-In empanelment as a requirement, that requirement is real and you should meet it, and it is a separate question from SOC 2. The broader pattern is worth knowing, because it recurs across frameworks: buyers are frequently told an accreditation is mandatory when the standard's own text names a qualification and an independence condition instead.

A licensed CPA firm, and that is not us. This is the single most useful boundary for a first-time buyer to hold. A SOC 2 report is an attestation issued by an independent licensed CPA firm after an examination. A penetration test vendor produces one piece of evidence that the CPA firm relies on. Anybody selling you SOC 2 certification directly is either reselling an audit firm or describing something that is not SOC 2. What we produce is the pentest report, the Trust Services Criteria mapping, the retest verification and the Letter of Attestation, formatted so the audit firm can use them without translation. Choosing the audit firm is a separate purchase and a separate decision.

Five things, and gathering them is usually the slowest part of the engagement. A written scope naming the applications, domains and environments to be tested, matching the boundary in your SOC 2 system description. Working test accounts at every privilege level that exists in the product, because authorization testing is impossible without at least two roles to compare. A test environment that mirrors production, or written authorization to test production with agreed rate limits and a change freeze window. A named technical contact reachable during testing hours who can confirm quickly whether something we are seeing is expected. And a written out-of-scope list, including any fragile integration that must not be touched. Access verification is a named step in our engagement sequence for exactly this reason.

Additional scopes are priced per scope and add testing days. On the Startup Pentest a second scope is INR 44,999 and adds five business days, and Startup caps at two scopes. On the Growth Pentest each additional scope is INR 74,999 and also adds five business days, with no cap, although five or more scopes moves to a custom scoping proposal rather than a plan. Scopes run sequentially by default. Parallel testing is a Growth-only option you can request from the third scope onward, which means scopes three and four run together, so a four-scope engagement can land in fifteen business days instead of twenty. It is a request we accommodate rather than a guarantee, and it changes nothing at three scopes because three is fifteen business days either way.