Auditor asks for a rewrite
A generic report does not mention SOC 2 criteria, PCI requirements, or HIPAA safeguards. Your auditor cannot use it as evidence.
Your auditor expects a current pentest. Here is one written in their language.
Compliance penetration testing scoped to SOC 2, ISO 27001:2022, PCI DSS v4.0.1, HIPAA, and GLBA — every finding mapped to the controls your audit cares about, ready without rework.
What is at stake
A pentest without control mapping creates rework — or worse, a finding.
Stalled SOC 2 or certification
Missing pentest evidence is a common reason surveillance audits slip — pushing your audit window and the deals that depend on it.
Customer security reviews block deals
Enterprise buyers ask for a current pentest. A report not tied to a recognized framework holds up contracts.
How we help — frameworks we map to
One engagement. Every framework your audit cares about.
If you carry two or three frameworks at once, we map a single set of findings to all of them. Click through for framework-specific scope and methodology.
SOC 2 Type II →
Findings mapped to the Common Criteria and your opted-in trust-service categories. Annual cadence.
ISO 27001:2022 →
Findings mapped to Annex A 8.8, 8.29, and 8.34 against your Statement of Applicability. Aligns with surveillance audits.
PCI DSS v4.0.1 →
External and internal testing per Requirement 11.4, plus segmentation testing per 11.4.5 (and 11.4.6 for service providers).
HIPAA →
Technical safeguard testing aligned to the Security Rule. Scope covers ePHI flows and Business Associate boundaries.
GLBA / FTC Safeguards Rule →
Annual penetration testing under 16 CFR § 314.4(d)(2) for non-bank financial institutions. Mapped to the Safeguards Rule sections.
NIST CSF and 800-53
Findings cross-walked to NIST CSF functions and 800-53 control families on request — common alongside FedRAMP work.
How an engagement works
Four steps from scoping call to audit-ready report.
- 01
Scoping call
We confirm which frameworks apply, map surfaces, and align to your audit window.
- 02
Manual testing
Senior testers work across in-scope surfaces. No automated-only shortcuts.
- 03
Mapped report
Findings with control mapping, scope statement, and evidence — in the language your auditor expects.
- 04
Retest and reissue
After fixes we retest and reissue so your auditor sees post-fix state.
Audit window coming up?
A quick scoping call gives you a fixed scope, price, and a date that fits your audit calendar.
Get a straight answer What is in the report
Three things auditors look for, in plain places.
Control mapping
Every finding tied to the relevant SOC 2 / ISO / PCI / HIPAA control.
Scope statement
Explicit description of what was tested, what was excluded, and why.
Retest evidence
Documentation of which findings were retested and the post-fix state.
Typical scenarios
Three patterns we see most often.
First-time SOC 2
Getting ready for a first SOC 2 audit and pentest is required evidence.
Annual surveillance
You hold a SOC 2 or ISO 27001 certificate and need current pentest evidence before the next surveillance review.
Multi-framework alignment
You operate under two or three frameworks (SOC 2 + ISO, SOC 2 + PCI) and need one report that covers them all.
Adjacent engagements
Compliance pentests pair naturally with these.
Web application testing →
The app surface most audits care about first.
API testing →
Add API surface to the audit-aligned scope.
Network and cloud testing →
External and internal network testing for PCI 11.4 and 800-53.
Authenticated testing →
Role-matrix coverage for SOC 2 access-control criteria.
Further reading
Background from our team.
SOC 2 Penetration Testing Requirements Explained →
What SOC 2 Type II auditors expect and how to scope a pentest that satisfies the trust services criteria.
PCI DSS v4: New Penetration Testing Requirements →
Updated Requirement 11.4 testing expectations, segmentation testing, and the customized approach.
FAQ
Compliance pentest — common questions
Will the report satisfy our auditor?
Yes. Reports include a control-mapping section that ties each finding to the language your auditor expects — SOC 2 trust criteria, ISO Annex A controls, PCI DSS requirements, HIPAA safeguards. Customers use these as audit evidence without rework.
Can you sequence around our audit window?
Yes. Tell us your audit field-work date on the scoping call and we sequence testing, reporting, and the retest so the version your auditor sees reflects post-fix state.
Do you cover PCI DSS segmentation testing?
Yes. Segmentation testing per PCI DSS 11.4.5 is in scope when payment-handling and out-of-scope environments share infrastructure. We document boundary controls and test that they actually contain.
How does this differ from a "regular" pentest?
The testing is the same; the report is tuned for an audit. We add control mapping, cross-walks, and the language auditors expect. If you do not need that framing, a standard web app or API engagement is usually a better fit.
Can the same engagement cover multiple frameworks?
Yes. Most customers are aligned to two or three frameworks at once (SOC 2 + ISO, or SOC 2 + PCI). We map each finding to all applicable frameworks in a single report.
Want a credible answer when a customer, auditor, or your board asks how secure you are?
A quick scoping call with the senior tester who would run your engagement. No slides, no pitch — we look at what you have, tell you what we would test first, and give you a fixed scope, price, and date.