Audit-ready penetration testing for SaaS companies under a SOC 2 Type I or Type II examination. Senior testers, control-mapped findings, retest included, fixed-price engagements scoped on a call.
A 30-minute scoping call with the senior tester who will lead your engagement. No sales engineer in between.
The system boundary your auditor is examining defines what we test. For a typical Series A SaaS, that means four areas — scoped explicitly before testing starts, with anything out of scope documented in the engagement letter.
The product itself, both unauthenticated and authenticated, tested the way a paying customer would use it. Same depth as our standalone web application penetration testing service.
REST and GraphQL endpoints scoped separately from the web UI. Modern SaaS APIs carry more authorization risk than the UI in front of them. See our dedicated API penetration testing service for the same coverage scoped on its own.
The AWS, GCP, or Azure environment your product runs in. Read-only configuration review scoped against the SOC 2 system boundary.
Included only when your SOC 2 system boundary covers corporate or shared infrastructure. For SaaS-only boundaries with no employee-network dependency, this is usually out of scope.
SOC 2 does not name penetration testing in a single mandatory line item. What the AICPA does is recognize penetration testing as one of several evaluation types an organization may use to demonstrate that its internal controls are present and functioning. Our reports are structured so each finding is tagged to the relevant Common Criteria control, which removes the cross-walk work your team would otherwise do during audit fieldwork.
The mapping below covers the five Trust Services Criteria where penetration test evidence is most commonly cited. The report addresses additional supporting criteria where engagement scope allows.
| Trust Services Criteria | What it requires (plain English) | What our report provides |
|---|---|---|
| CC4.1 Ongoing evaluations of internal controls | Your auditor expects independent testing that confirms your controls actually work — not just policies on paper. AICPA explicitly names penetration testing as one of these evaluations. | Independent third-party penetration test with dated executive summary, scope statement, and tester credentials — formatted for direct inclusion in your SOC 2 audit package. |
| CC6.1 Logical access controls | You restrict access to data and systems using authentication, authorization, and segmentation. Your auditor expects evidence those controls hold up under attack. | Authenticated testing of login flows, session management, privilege escalation paths, and tenant isolation — findings mapped per CC6.1 expectation. |
| CC6.6 Protection against external threats | Your internet-facing systems are protected from outside attack and monitored for attempts. Your auditor expects evidence the perimeter actually defends. | External penetration testing of all in-scope public assets with findings on boundary protection, MFA enforcement, and whether your monitoring detected the test. |
| CC7.1 Vulnerability identification | You have procedures to find new vulnerabilities and misconfigurations on a regular basis and after significant changes. Your auditor expects evidence those procedures work. | Vulnerability and misconfiguration findings with CVE and CWE references plus business-logic flaws that automated scanners miss — severity-ranked using CVSS v3.1. |
| CC4.2 Communication of deficiencies | When deficiencies are found, you communicate them to the right people for remediation and track corrective action. | Severity-ranked findings with named owners, remediation guidance, and a retest appendix documenting which findings have been closed — ready for your remediation tracker. |
Mapping based on AICPA TSP Section 100, 2017 Trust Services Criteria (with March 2020 updates). A penetration test contributes evidence under these criteria; it does not replace auditor judgment or substitute for the full set of controls a SOC 2 examination requires.
A four-step engagement that runs in roughly three to five weeks for a typical Series A SaaS scope. Each step has a named owner and a defined deliverable.
We lock the system boundary, attack surface, testing windows, and rules of engagement against your auditor’s expectations before any testing starts.
Manual testing led by a senior tester. Automated tooling is used for breadth (port scanning, dependency analysis, known-CVE checks) — not for the testing itself. We work against the OWASP Testing Guide, OWASP ASVS, PTES, and NIST SP 800-115.
Every finding is validated, severity-ranked using CVSS v3.1 with environmental adjustment, written for both the auditor and the engineer who has to fix it, and reviewed by a second senior before delivery.
One round of remediation verification is included in every engagement at no additional cost. Retest results are appended to the original report so your auditor sees both the original finding and its closure in a single document.
The report your auditor reads is the same report your engineering team uses to remediate and the same report your GTM team uses to clear customer security questionnaires. We write it once, with all three readers in mind.
We do not publish a price list and we do not quote pentests by the page-load. Every engagement is scoped on a call, against the system boundary your auditor is actually examining, and quoted as a fixed price with no per-finding or per-day variability after signature.
Three patterns cover most Series A SaaS engagements:
A typical first-year SOC 2 pentest for a SaaS with one product surface, light API exposure, and a straightforward cloud footprint. Roughly two to three weeks of testing, four to five weeks end-to-end including reporting and retest.
The most common Series A SOC 2 Type II scope. A real API surface, AWS or GCP footprint, multiple user roles, and tenant isolation that needs to be validated. Roughly three to four weeks of testing, five to six weeks end-to-end.
Multi-product, multi-environment, internal and external testing, with optional social engineering. Quoted on a per-engagement basis after a scoping call.
Scope-change requests during an engagement are handled by written addendum, never verbal. If you find a new attack surface mid-test that you want covered, we tell you the additional days required and the additional cost before any work happens. You decide.
No. The AICPA Trust Services Criteria do not mandate penetration testing in a single dedicated line item. However, auditors treat a current third-party penetration test as the expected evidence under Common Criteria CC4.1 (ongoing evaluations) and CC7.1 (vulnerability identification) — in our experience, every SOC 2 Type II audit we have supported has expected one. For depth, see our blog post on SOC 2 penetration testing requirements.
The report is formatted for direct inclusion in your audit package, with each finding tagged to the relevant Common Criteria control, an attestation letter on our letterhead, and a methodology section auditors look for. Acceptance ultimately depends on your auditor’s evaluation of scope, methodology, and independence — but the structural work is done so they are evaluating the evidence, not the format.
The scope itself is usually the same — the system boundary your auditor is examining does not change between Type I and Type II. What changes is timing. For Type I, we run the test once and produce a point-in-time report; for Type II, the audit period requires evidence of ongoing evaluation, which usually means an annual pentest plus continuous vulnerability scanning between tests. For most first audits, teams start with Type I in year one and graduate to Type II in year two — but if you have an enterprise customer demanding Type II first, the scoping call covers that path too.
For a typical Series A SaaS scope, three to five weeks end-to-end. That covers scoping (3 to 5 business days), testing (10 to 20 business days depending on attack surface), drafting and senior review (5 to 7 business days), and the retest window scheduled around your remediation timeline.
Yes — one round of remediation verification is included in every engagement at no additional cost, with results appended to the original report. If a finding is not fully remediated by the retest date, we mark it Open or Partially Remediated with notes rather than failing it silently. Additional retest rounds, if you need them, are quoted separately.
Yes. Our reports include an attestation letter and executive summary that drop into trust-center workflows without modification. We do not have a paid integration with any compliance platform, which means we receive no referral fees and have no incentive to recommend one platform over another.
No. The pre-audit-cycle scoping call is one of the most useful conversations we have, because it surfaces system-boundary and remediation timing decisions before they get baked into your auditor’s letter of engagement. We can run the test now to find issues early (useful if you’re still in SOC 2 readiness or SOC 2 Type II prep), or scope the engagement now and run it later in your audit window. If you’re earlier still — at the SOC 2 gap assessment stage — we can also point you to auditor partners we have worked with.
Both. The report is yours to share with auditors, prospects, customers, and partners under the same NDA terms you use for your SOC 2 report. Most teams share a redacted executive summary in early sales conversations and the full report under signed mutual NDA during procurement.
Senior staff. Every engagement is led by a tester with OSCP, OSWE, GPEN, or GWAPT credentials and years of relevant experience, with a second senior brought in where breadth requires it. We do not staff engagements with junior testers running automated scans, and we do not subcontract work offshore — the senior who runs your scoping call is the senior who runs your test.
A vulnerability scan is automated, runs against known signatures, and finds known issues. A penetration test is manual, runs against your specific application’s logic, and finds the issues a scanner misses — authentication bypass paths, broken authorization, business logic flaws, chained exploit sequences. Auditors typically treat scans as supplementary evidence under CC7.1; penetration test results typically carry weight as primary evidence because they demonstrate controls were challenged, not just inventoried.
Fixed price. We quote the engagement after the scoping call and the price does not change for the duration of the engagement. If you ask us to extend scope mid-test, we tell you the additional days and cost in writing before any new work starts, and you decide whether to proceed. No per-finding fees, no per-day rate creep, no surprise change orders.
A 30-minute call with a senior tester. No sales engineer in between. We will walk through your system boundary, your auditor’s expectations, and the testing timeline that fits your audit window.
Penetration testing under signed agreement only. Senior testers, OSCP / OSWE / GPEN / GWAPT credentialed. Reports structured to AICPA Trust Services Criteria mapping.