Compliance

Penetration testing for SOC 2, PCI DSS, HIPAA, and ISO 27001

Every major framework expects you to test your defenses, but each expects something slightly different, and none of them accept a checkbox. This guide explains what SOC 2, PCI DSS 4.0, HIPAA, and ISO 27001 actually require, and where continuous, autonomous testing fits alongside the human led assessment auditors still ask for.

The Honest Version

What auditors actually expect

The uncomfortable truth most vendors skip: a framework that expects a human led test is not satisfied by automation alone. We say so plainly, because getting this wrong fails an audit.

SOC 2

A test your auditor will accept

SOC 2 does not name penetration testing as a hard requirement, but auditors routinely expect one as evidence that the security controls behind your Trust Services Criteria actually hold. Timing matters: run it before the evidence window, and remediate before the report.

PCI DSS 4.0

A named, explicit requirement

Requirement 11.4 requires internal and external penetration testing at least annually and after significant change, using a recognized methodology such as NIST SP 800-115, with remediation and retesting. It expects a qualified human tester.

HIPAA

Best practice, effectively expected

HIPAA does not name a penetration test, but the Security Rule risk analysis and OCR guidance make regular testing the practical standard for protecting electronic protected health information, and proposed updates would tighten this further.

ISO 27001

Evidence for Annex A controls

ISO 27001 expects technical vulnerability management and evidence that controls work. A penetration test is the common way to demonstrate that the controls in your Statement of Applicability are effective, not just documented.

Where Operator Fits

Continuous evidence between the tests auditors require

Planck Operator does not replace the human led assessment a framework expects. It does something the annual test cannot: it keeps testing as your systems change, and produces a dated, reproducible record of what was found and fixed across the whole period.

That record is exactly the evidence of ongoing diligence auditors increasingly ask for, and it means the annual human engagement starts from a surface that has already been hardened.

  • Standards mapped. Findings map to NIST SP 800-115, the OWASP guides, and CVSS v3.1, the references auditors recognize.
  • Human signed when required. Where a framework needs an accredited human, a certified practitioner reviews and signs the report.
  • Dated and reproducible. Every run leaves an evidence trail you can hand to an assessor.
  • Retest included. Fixes are verified, which is what Requirement 11.4.4 and good practice both expect.
By Framework

Read the detail for your regime

FAQ

Common questions

Does automated or AI penetration testing satisfy compliance on its own?

Not for frameworks that expect human led testing. PCI DSS still expects a qualified human tester, and most SOC 2 auditors want an assessment a person stands behind. Continuous autonomous testing is best used to keep you covered between those engagements and to produce evidence of ongoing diligence, not to replace the human assessment a framework requires.

Which frameworks require a penetration test?

PCI DSS explicitly requires it. SOC 2, HIPAA, and ISO 27001 do not name it as a hard line item, but auditors and risk analyses routinely expect one as evidence of a working security program. In practice, a serious organization in any of these regimes runs regular penetration testing.

How does continuous testing help an audit?

Auditors increasingly want evidence that security is ongoing, not a once a year snapshot. Continuous autonomous testing produces a dated, reproducible record of what was tested and fixed across the period, which strengthens the story you tell an assessor between formal engagements.

Get Started

Get audit ready, and stay that way

Continuous coverage between your formal assessments, with evidence an auditor recognizes.