Penetration Testing for Compliance: SOC 2, ISO 27001, PCI DSS, HIPAA

Penetration testing compliance: what your framework actually requires

SOC 2 doesn't technically require a penetration test. But try passing an audit without one.

That's the reality most CTOs and CISOs run into. The frameworks are written in careful, hedged language. "Risk-based testing." "Ongoing evaluation of controls." "Technical safeguards." But when your auditor sits down and reviews your evidence, the first thing they ask for is your pentest report.

Compliance is one of the most common reasons companies buy their first pentest. And one of the most common reasons they get it wrong — buying whatever's cheapest, or whatever a vendor claims meets the requirement, without understanding what the framework actually expects.

This post covers exactly that. What each major framework requires, what auditors actually look for, and how to make sure your pentest actually satisfies the standard.

Why compliance frameworks don't just say "get a pentest"

The frameworks are written to be technology-neutral and future-proof. PCI DSS can't say "hire Company X to run Burp Suite," because security testing methods evolve.

So instead they write things like: "implement a penetration testing methodology" or "perform technical testing to validate security controls." Which is accurate — but leaves a lot of room for interpretation.

The practical interpretation — the one auditors and certifying bodies apply — almost always means: annual manual penetration testing by a qualified third party, with documented findings and evidence of remediation.

There are differences between frameworks. Some are explicit (PCI DSS), some are implicit (SOC 2), some are newer and still evolving (HIPAA's proposed changes). Here's what you actually need to know about each one.

SOC 2: the implicit requirement that auditors treat as mandatory

SOC 2 is built around Trust Services Criteria (TSC). The one most relevant to penetration testing is CC4.1, which requires that you "select, develop, and perform ongoing and/or separate evaluations" to confirm your security controls are working.

There's no sentence in the SOC 2 framework that says "you must have a penetration test." But in practice, for a SOC 2 Type II audit, a penetration test is the most commonly accepted and expected form of evidence that CC4.1 is satisfied.

A few things auditors want to see:

The test happened within the audit period. If your SOC 2 audit covers a 12-month window and your pentest is from 18 months ago, it won't satisfy the period under review.

It was performed by an independent third party. Your internal security team testing your own systems doesn't meet the independence expectation, especially for Type II.

Findings were actually remediated. The report isn't enough. Auditors want to see evidence of fixes — a retest report, tickets closed, configuration changes documented.

It mapped to your SOC 2 system boundary. A generic web app test doesn't cover your SOC 2 environment if your in-scope systems are a mix of cloud infrastructure, internal services, and APIs. The test has to match what you're auditing.

Automated scanners alone won't pass. Auditors increasingly understand the difference between a vulnerability scan and a manual pentest — and they'll ask.

CC4.1 calls for "ongoing or separate evaluations" of control effectiveness. For most auditors, a penetration test is the clearest evidence you can provide that your controls hold up under adversarial conditions.

PCI DSS: the most prescriptive framework of all

PCI DSS (Payment Card Industry Data Security Standard) is the most explicit about penetration testing. If you store, process, or transmit cardholder data, this applies to you.

With v4.0 now fully enforced as of March 2025, the requirements got more specific. Requirement 11.4 covers the full scope of what's expected.

What's required:

• External penetration testing: annually and after any significant change to your infrastructure
• Internal penetration testing: annually and after significant changes
• Segmentation testing: if you use network segmentation to limit your cardholder data environment (CDE) scope, you must validate that segmentation annually — and every six months if you're a service provider
• Application-layer testing: the test must cover your application layer, not just network infrastructure

Who can do it:

PCI DSS allows internal testing — but the tester must be organizationally independent from the systems they're testing. Most organizations use a third party to avoid the conflict of interest and to get a qualified tester with relevant certifications (OSCP, CREST, or equivalent).

What the report needs to include:

The days of a thin PDF with a few screenshots are over. PCI DSS v4.0 expects the report to document scope (specific IPs, hostnames, URLs), methodology, test dates, findings with severity ratings, and evidence of retest for remediated findings.

If your segmentation controls are found to be inadequate during testing, you'll need to reassess your CDE scope — which can significantly expand what you need to protect and report on.

As we covered in our penetration testing cost guide, PCI-scoped engagements tend to run higher than standard web app tests, because the scope requirements and documentation standards are more demanding.

ISO 27001: risk-based, but annual is the norm

ISO 27001 takes a risk-based approach to most controls, and penetration testing is no different. The standard doesn't say "pentest annually." It says you need to assess and address technical vulnerabilities as part of your ISMS (Information Security Management System).

Annex A controls most relevant to pentesting:

• A.8.8 (formerly A.12.6.1): Management of technical vulnerabilities
• A.8.29: Security testing in development and acceptance
• A.5.37: Documented operating procedures for security activities

An annual pentest is the accepted standard for satisfying these controls during your Stage 2 audit. Auditors look for it as evidence that your vulnerability management process has teeth — that you're not just running automated scans and calling it done.

ISO 27001 also expects you to feed pentest findings back into your risk register. A finding that's documented but never added to your risk treatment plan is a gap auditors will flag.

For initial certification vs. surveillance audits:

For your first ISO 27001 certification, you want a clean pentest report (or one where high and critical findings are demonstrably remediated) before your Stage 2 audit. For annual surveillance audits, you'll need to show that testing continued and findings were addressed.

The flexibility of ISO's risk-based approach can be useful if your environment has genuinely low risk — but in practice, any organization handling sensitive data that goes into an audit without a recent pentest is asking for a finding.

HIPAA: changing requirements, changing stakes

HIPAA (Health Insurance Portability and Accountability Act) has historically been the most ambiguous of these frameworks when it comes to penetration testing. The Security Rule requires covered entities and business associates to conduct a risk analysis — but never explicitly says "pentest."

That's changing.

HHS proposed rule updates that would make annual penetration testing mandatory for covered entities and business associates handling PHI (Protected Health Information). As of 2026, this is still in regulatory process, but the direction is clear: expect an explicit requirement in the near term.

Even under current rules, the case for pentesting is strong. A few things to know:

OCR (Office for Civil Rights) enforcement actions repeatedly cite inadequate risk analysis as a root cause of breaches. A pentest is the most credible way to demonstrate you assessed your technical attack surface.

Business associates are in scope. If you're a SaaS company, an EHR vendor, or any technology provider handling PHI, HIPAA applies to you through your BAA (Business Associate Agreement). Your customers' compliance depends partly on your security posture.

Breach costs make the math obvious. The average HIPAA settlement runs into the millions. A pentest costs a fraction of that — and provides documented evidence that you took reasonable technical precautions.

Framework comparison: what each one actually requires

How to scope a compliance pentest correctly

A pentest "for compliance" is only useful if it actually covers what your framework is auditing. This is where a lot of organizations trip up — they get a test that's technically real pentesting, but it doesn't map to the right scope.

A few principles:

Match the test to your audit boundary. Your SOC 2 system boundary defines what's in scope for your audit. Your pentest should test those systems — not a random sample of your environment.

Include your full attack surface. Most modern environments include external web apps, APIs, cloud infrastructure, and internal networks. A compliance pentest should cover all four layers, or explicitly document why certain layers are out of scope.

Get methodology documentation. Auditors want to see what methodology was used — OWASP, NIST SP 800-115, PTES (Penetration Testing Execution Standard), or equivalent. "We tested your systems" isn't enough.

Plan for retests. When you find critical or high findings — and you will — build in time and budget for a retest before your audit window closes. You need the retest report to show remediation.

Don't wait until the last minute. Running a pentest six weeks before your audit gives you almost no time to fix anything meaningful. Most organizations should test at least 90 days before their audit, leaving room for remediation and retest.

For more on what to look for in a pentest provider and how to avoid common mistakes, see our guide on choosing a penetration testing company.

One test, multiple frameworks

If you're subject to multiple frameworks — say, SOC 2 and ISO 27001, or PCI DSS and HIPAA — you don't necessarily need a separate pentest for each.

A well-scoped, comprehensive pentest can often satisfy the requirements of multiple frameworks simultaneously, as long as the scope covers the relevant environments and the report is documented in a way that maps to each framework's evidence requirements.

Work with your pentest provider upfront to confirm the scope covers what each audit needs. It's a simple conversation that can save you the cost of running multiple separate engagements.

---

Trying to figure out which frameworks apply to you and what your pentest needs to cover? Book a free consultation with our team and we'll walk you through what a compliance pentest engagement looks like for your stack.