Peak Security
Back to home
Compliance / SOC 2

SOC 2 penetration testing, with proof your auditor can read.

Auditors and enterprise customers ask for an independent penetration test. We test your app and APIs, prove every finding, and retest after you fix. You get one clean packet for the audit.

What SOC 2 asks for.

SOC 2 does not prescribe a test. Auditors still expect evidence that you evaluate your controls, and a penetration test is the standard way to show it.

CC4.1

The criterion whose points of focus name penetration testing as a separate evaluation of your controls.

12 mo

The interval auditors and customer security reviews usually expect between tests.

Type II

Covers a review period, so the test date, the fixes, and the retest all matter.

The AICPA Trust Services Criteria ask you to evaluate whether your controls are present and working. Under CC4.1, penetration testing is one of the named ways to do that. Access controls (CC6) and vulnerability management (CC7) are where findings usually land.

Your auditor will look for an independent tester, a documented scope and method, findings with evidence, and proof that you fixed what mattered. The map shows how our report lines up.

SOC 2What we testEvidence
CC4.1Independent app + API penetration testcovered
CC6.1Roles, permissions, tenant isolationcovered
CC6.6Internet-facing endpoints and authcovered
CC7.1Findings tracked from discovery to fixcovered
CC8.1Retest after remediation changesretest

What we test.

We focus on the application layer, where most real breaches of customer data start: accounts, permissions, and the APIs behind the interface.

Tenant isolation

Can one customer read or change another customer's records by changing an ID, a header, or an organization switch?

Accounts and sessions

Sign-in, password reset, invitations, MFA, and whether access really ends when a user is removed.

APIs behind the interface

Endpoints that accept record IDs, return hidden fields, or skip the checks the UI enforces.

Admin and sensitive actions

Exports, billing, approvals, deletion, and anything a lower role should never reach.

From scoping call to evidence file.

One engagement produces the report your auditor reads and the retest that shows the fixes worked.

  1. 01
    Scope

    We map the systems in your audit scope to what we test, and agree on accounts, limits, and dates.

    30-minute call
  2. 02
    Test

    Agents and researchers work the agreed apps and APIs. A human reproduces every finding.

    Test accounts only
  3. 03
    Report

    Methodology, scope, dates, and per-finding evidence with a fix your engineers can apply.

    Auditor-ready
  4. 04
    Retest

    After you fix, we retest the same paths and record the result for your evidence file.

    Closes the loop

Questions teams ask first.

Does SOC 2 require a penetration test?
Not by name. The criteria ask you to evaluate your controls, and most auditors and enterprise customers expect an independent penetration test as that evidence. Ask your auditor what they expect for your scope.
Will the report work for our auditor?
The report states the scope, dates, method, each finding with evidence and severity, and the retest result. Those are the items auditors check. Share our sample report with them before the test if you want to confirm.
Will you touch production customer data?
No. We use dedicated test accounts and agree on off-limits actions before testing starts.
We also get customer security questionnaires. Does this help?
Yes. A recent third-party test with fixes retested answers the penetration-testing questions on most questionnaires, and you can share a summary instead of the full report.

Get your test on the calendar.

Tell us your audit window and what is in scope. We will tell you what to test first and what the report needs to show.