Compliance is the most common reason organisations buy a penetration test. But "we need a pentest for the audit" hides a lot of nuance: each framework expects different scope, frequency and evidence. This guide summarises what major frameworks expect so you can scope a test that satisfies your auditor the first time.
PCI DSS v4.0
PCI DSS is the most explicit framework about penetration testing. Requirement 11.4 calls for a defined penetration testing methodology and for internal and external penetration testing at least once every 12 months and after any significant infrastructure or application change. Exploitable vulnerabilities must be corrected and retested. Where segmentation is used to reduce PCI scope, segmentation controls must also be tested — at least annually for merchants and more frequently (every six months) for service providers. Testing must be performed by a qualified internal resource or qualified external third party with organisational independence.
SOC 2
The AICPA Trust Services Criteria do not mandate penetration testing by name. However, criteria around risk assessment, monitoring and vulnerability management (for example CC4.1 and CC7.1) are commonly evidenced with an annual third-party penetration test, and most SOC 2 auditors and enterprise customers expect one. Scope typically covers the in-scope production application, APIs and supporting cloud infrastructure.
ISO/IEC 27001:2022
ISO 27001 requires organisations to manage technical vulnerabilities (Annex A control 8.8) and to perform security testing in development and acceptance (control 8.29). Penetration testing is the usual way to evidence these controls for internet-facing systems. Frequency is risk-based, but annual testing plus testing after major change is the norm auditors expect.
HIPAA
The HIPAA Security Rule requires regular technical and non-technical evaluations of security safeguards and a thorough risk analysis. While it does not name penetration testing explicitly, it is widely used to evidence these evaluations for systems storing electronic protected health information (ePHI), and proposed updates to the Security Rule have discussed making regular testing more explicit.
GDPR and India's DPDP Act
GDPR Article 32 requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures". India's Digital Personal Data Protection Act, 2023 obliges data fiduciaries to take reasonable security safeguards to prevent personal data breaches. Penetration testing is a standard way to demonstrate both.
Indian financial regulators: RBI, SEBI, IRDAI and CERT-In
- RBI cyber security frameworks and IT governance directions expect regulated entities (banks, NBFCs, payment system operators) to conduct periodic VAPT, especially for internet-facing and critical systems.
- SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF) sets VAPT and audit expectations for market intermediaries, scaled by entity category.
- IRDAI information and cyber security guidelines require periodic assessments for insurers.
- CERT-In maintains a list of empanelled auditing organisations; some government and regulated engagements require an empanelled auditor.
Quick reference
| Framework | Pentest explicitly required? | Typical frequency | Typical scope |
|---|---|---|---|
| PCI DSS v4.0 | Yes (Req. 11.4) | 12 months + after significant change | CDE internal/external, segmentation, apps |
| SOC 2 | Not by name; expected | Annual | Production app, API, cloud |
| ISO 27001:2022 | Not by name; evidences 8.8 / 8.29 | Risk-based, usually annual | ISMS-scoped systems |
| HIPAA | Not by name; evidences evaluations | Annual is common | Systems handling ePHI |
| GDPR / DPDP | Not by name; "regular testing" | Risk-based | Systems processing personal data |
| RBI / SEBI / IRDAI | Yes, VAPT expected | Per circular / entity category | Critical and internet-facing systems |
How to scope a compliance pentest auditors accept
- Share the relevant framework and your auditor's expectations with the testing firm up front.
- Ensure the in-scope system boundary matches your audit boundary.
- Require a documented methodology section and a clear statement of scope and limitations.
- Include a retest and an updated report showing remediation status.
- Request an attestation letter you can share with customers.
See our compliance & audit readiness services, or get a compliance pentest quote.