Penetration Testing for Compliance: ISO 27001, PCI-DSS, SOC 2 & DORA

If you're a CISO, compliance officer, or IT director preparing for an audit, there's a question you've probably asked more than once: "Do we actually need a penetration test for this?"

The answer, for virtually every major compliance framework in 2026, is yes — either explicitly or in practice. PCI-DSS spells it out in black and white. ISO 27001 implies it through Annex A controls. SOC 2 auditors expect it as evidence for Trust Services Criteria. DORA mandates advanced threat-led testing for financial entities across the EU. Even HIPAA, which never uses the words "penetration test," has been enforced in ways that make it effectively mandatory.

But here's the problem: meeting the technical bar for a pentest and meeting the compliance bar are two very different things. A technically excellent penetration test can still fail an audit if the scope doesn't align with the framework, the report is missing key sections, or the testing wasn't performed at the right time. We've seen it happen repeatedly.

This guide walks through what each major framework actually requires, how to scope and time your engagements, and how to produce pentest reports that auditors accept without pushback. Whether you're dealing with one framework or juggling several simultaneously, you'll find the specifics you need here.

Why Compliance Frameworks Require Penetration Testing

Before diving into framework-specific requirements, it's worth understanding why regulators and standards bodies insist on penetration testing in the first place. It comes down to three core principles.

1. Vulnerability Scanners Are Not Enough

Automated vulnerability scanners catch known CVEs and common misconfigurations. They do not catch business logic flaws, chained attack paths, authentication bypasses, or the kind of creative exploitation that real attackers use. Compliance frameworks recognize this gap. They want evidence that a skilled human tested your defenses — not just that a tool ran a scan and produced a PDF.

2. Controls Must Be Validated, Not Just Documented

Every compliance framework requires you to implement security controls. But implementing a control and that control actually working under adversarial pressure are two different things. Penetration testing is how you prove that your firewall rules, access controls, segmentation, and encryption actually hold up when someone actively tries to break them. Think of it as the difference between writing a disaster recovery plan and actually running a drill.

3. Continuous Improvement Requires Evidence

Frameworks like ISO 27001 are built around the Plan-Do-Check-Act cycle. SOC 2 Type II evaluates controls over time, not at a snapshot. Penetration testing provides the "Check" evidence — concrete proof that your security posture is being measured, gaps are being identified, and improvements are being made. Without it, your audit narrative has a hole in it.

PCI-DSS Penetration Testing Requirements

Of all compliance frameworks, PCI-DSS is the most prescriptive about penetration testing. There's no ambiguity here — if you process, store, or transmit cardholder data, you need a pentest, and the standard tells you exactly how to do it.

Requirement 11.4: What It Actually Says

PCI-DSS v4.0 Requirement 11.4 mandates that organizations must perform both internal and external penetration testing:

• At least annually
• After any significant infrastructure or application change (new system components, OS upgrades, network topology changes, new firewall rules affecting the CDE)
• Testing must cover the entire cardholder data environment (CDE) and critical systems connected to it
• Both network-layer and application-layer testing are required
• The test must be performed by a qualified internal resource or external third party

Segmentation Testing

If your organization uses network segmentation to reduce the scope of PCI-DSS (and most do), Requirement 11.4.5 requires segmentation penetration testing every six months. This test specifically validates that your segmentation controls are effective — that systems outside the CDE truly cannot reach systems inside it. This is one of the most commonly failed PCI requirements, because organizations set up VLANs and firewall rules but never verify they actually work under adversarial conditions.

What QSAs Look For

Your Qualified Security Assessor (QSA) will evaluate your penetration test against specific criteria:

• Scope alignment: Did the test cover the full CDE, not just a subset?
• Methodology: Was a recognized methodology used (PTES, OWASP, NIST SP 800-115)?
• Exploitation: Did testers attempt to exploit findings, not just identify them?
• Remediation evidence: Were critical and high findings remediated and retested?
• Timing: Was the test conducted within the assessment period?

Common PCI Pentest Failures

• Testing only the web application but not the underlying network infrastructure within the CDE
• Missing segmentation testing or performing it annually instead of semi-annually
• No retesting evidence for critical findings — QSAs need proof that vulnerabilities were fixed
• Using an unqualified tester — PCI-DSS requires demonstrated competence (certifications like OSCP, GPEN, or CREST are expected)
• Testing too late in the audit cycle, leaving no time for remediation

ISO 27001 Penetration Testing

Unlike PCI-DSS, ISO 27001 doesn't explicitly require penetration testing. The words "penetration test" don't appear in the standard. But don't let that fool you — in practice, almost every ISO 27001 certification auditor expects to see one.

The Annex A Controls That Drive It

Several Annex A controls in ISO 27001:2022 create an implicit requirement for penetration testing:

• A.8.8 — Management of technical vulnerabilities: Requires organizations to identify and address technical vulnerabilities in a timely manner. Penetration testing is the most effective way to discover vulnerabilities that scanners miss.
• A.5.36 — Compliance with policies, rules and standards: Requires verification that security controls are implemented correctly. Pentesting validates that controls work as intended.
• A.8.34 — Protection of information systems during audit testing: Acknowledges that audit testing (including technical testing) should be planned and controlled — implying that such testing is expected.

What's Required vs. What's Recommended

Technically, you could achieve ISO 27001 certification without a penetration test if you demonstrate vulnerability management through other means. In reality, this is difficult. Certification bodies like BSI, Bureau Veritas, and DNV GL almost universally expect penetration test evidence as part of the audit. If you show up without one, prepare to justify why — and prepare for the auditor to note it as an observation or minor non-conformity.

Scoping for ISO 27001

ISO 27001 penetration testing should be scoped to cover the systems within your Information Security Management System (ISMS) scope. This is broader than PCI's CDE concept — it includes any systems, networks, and applications that process, store, or transmit information assets covered by your ISMS. For most organizations, this means:

• All customer-facing web applications
• Internal applications handling sensitive data
• External and internal network infrastructure
• Cloud environments within the ISMS boundary
• APIs that connect to ISMS-scoped systems

Evidence Formatting

ISO auditors care about process as much as findings. Your pentest report should include:

• Clear mapping between test scope and ISMS scope
• Methodology reference (PTES, OWASP, NIST)
• Risk ratings using a consistent framework (CVSS preferred)
• Remediation timelines linked to your risk treatment plan
• Evidence of management review (signed-off findings, tracked in your risk register)

SOC 2 Penetration Testing

SOC 2 is the audit framework that most SaaS companies encounter first, usually because a customer or prospect demands it. Like ISO 27001, SOC 2 doesn't explicitly require penetration testing — but try passing a SOC 2 Type II audit without one, and you'll quickly understand why most companies include it.

Trust Services Criteria: CC7.1 and CC7.2

The relevant Trust Services Criteria for penetration testing fall under the Common Criteria (CC) section:

• CC7.1: "The entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities, and susceptibilities to newly discovered vulnerabilities." Penetration testing serves as a detection mechanism that goes beyond automated monitoring.
• CC7.2: "The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events." Pentest findings demonstrate that you're actively looking for security events, not waiting for them to happen.

How Auditors Evaluate Pentest Evidence

SOC 2 auditors (CPAs from firms like Deloitte, KPMG, Schellman, or A-LIGN) evaluate your penetration test as part of the broader control environment. They're looking for:

• Scope coverage: Does the test cover the systems described in your system description?
• Testing period alignment: Was the test performed during the SOC 2 audit period (for Type II)?
• Remediation tracking: Were findings tracked in a ticketing system with assigned owners and deadlines?
• Management response: Did management formally review and respond to the findings?
• Retest evidence: Were critical findings retested after remediation?

Type I vs. Type II: Timing Matters

SOC 2 Type I evaluates controls at a point in time. A single penetration test performed before the audit date is sufficient. SOC 2 Type II evaluates controls over a period (usually 6 or 12 months). Your penetration test should fall within that period, and ideally you should show a pattern of regular testing — not just a single test crammed in at the end. Auditors notice when the pentest date is suspiciously close to the audit period end date.

DORA & Threat-Led Penetration Testing

The Digital Operational Resilience Act (DORA) is the EU's most significant regulatory development for financial sector cybersecurity, and it takes penetration testing to a level that most organizations have never dealt with before.

What DORA Requires

DORA, which became fully applicable in January 2025, applies to virtually all financial entities in the EU — banks, insurance companies, investment firms, payment institutions, crypto-asset service providers, and their critical ICT third-party service providers. Under DORA, these entities must:

• Perform regular ICT security testing as part of their digital operational resilience framework
• Conduct threat-led penetration testing (TLPT) at least every three years for entities identified as significant
• Use independent testers (external, or internal with specific independence requirements)
• Report TLPT results to the relevant financial supervisory authority

TLPT and the TIBER Framework

DORA's threat-led penetration testing requirement builds on the TIBER-EU framework (Threat Intelligence-Based Ethical Red Teaming). TLPT is not a standard penetration test — it's a structured, intelligence-driven red team exercise that simulates the tactics, techniques, and procedures (TTPs) of real threat actors targeting the financial sector. Key differences from standard pentesting:

• Threat intelligence phase: A separate threat intelligence provider produces a targeted threat intelligence report before testing begins
• Red team phase: Testers simulate real-world attack scenarios based on the threat intelligence, targeting critical business functions
• Blue team assessment: The defending team's detection and response capabilities are evaluated
• Scope includes people, processes, and technology — not just systems
• Regulatory oversight: Supervisory authorities may observe or guide the process

Who's Affected

Not every financial entity needs to perform TLPT. The requirement applies to entities identified by competent authorities as significant, which typically includes:

• Systemically important banks and insurers
• Large payment service providers and e-money institutions
• Central securities depositories and central counterparties
• Critical ICT third-party providers serving the financial sector

Even if your organization doesn't fall into the TLPT category, DORA still requires regular penetration testing as part of your ICT security testing program. VulnSkill provides both standard compliance pentesting and threat-led penetration testing (TLPT) aligned with TIBER-EU requirements.

HIPAA Penetration Testing

Here's the thing about HIPAA and penetration testing: the word "penetration test" appears nowhere in the HIPAA Security Rule. And yet, if you're a covered entity or business associate handling protected health information (PHI), skipping penetration testing is increasingly risky.

Why It's Effectively Mandatory

The HIPAA Security Rule requires covered entities to:

• Conduct a risk analysis (45 CFR 164.308(a)(1)(ii)(A))
• Implement a risk management program (45 CFR 164.308(a)(1)(ii)(B))
• Perform periodic technical and non-technical evaluations (45 CFR 164.308(a)(8))

The Office for Civil Rights (OCR), which enforces HIPAA, has increasingly interpreted "technical evaluation" to include penetration testing. In multiple enforcement actions and resolution agreements, OCR has cited the absence of penetration testing as evidence of inadequate risk analysis. The message is clear: while HIPAA doesn't mandate pentesting by name, not doing it creates significant regulatory risk.

OCR Enforcement Trends

Recent OCR settlements have established a pattern. Organizations that suffered breaches and could not demonstrate they had performed penetration testing faced larger fines and more stringent corrective action plans. In several cases, mandatory penetration testing was included as a condition of the resolution agreement — effectively confirming that OCR considers it a standard practice.

Scope for Healthcare

HIPAA penetration testing should cover all systems that create, receive, maintain, or transmit electronic protected health information (ePHI):

• Electronic Health Record (EHR) systems and patient portals
• Medical device networks and IoT devices connected to clinical networks
• Telehealth platforms and remote access infrastructure
• Health information exchanges (HIEs)
• Cloud environments hosting ePHI (AWS, Azure, GCP)
• Business associate integrations and data sharing interfaces

UAE Compliance: NESA & ADHICS

For organizations operating in the United Arab Emirates, compliance penetration testing involves a distinct set of regulatory frameworks that are rapidly maturing. If you serve clients in the UAE or have operations there, understanding these requirements is essential.

NESA IAS (Information Assurance Standards)

The UAE's National Electronic Security Authority (NESA) publishes the Information Assurance Standards, which apply to all government entities and critical information infrastructure operators. NESA IAS includes explicit requirements for:

• Periodic vulnerability assessments and penetration testing of information systems
• Testing of internet-facing and internal systems
• Web application security testing following OWASP methodology
• Remediation verification through retesting
• Testing by qualified providers with recognized certifications

ADHICS (Abu Dhabi Healthcare Information and Cyber Security)

Healthcare organizations in Abu Dhabi must comply with ADHICS, which sets cybersecurity requirements specifically for the healthcare sector. ADHICS mandates regular VAPT assessments and penetration testing of systems handling patient data, with requirements that overlap with both HIPAA and ISO 27001.

DIFC and Central Bank Requirements

The Dubai International Financial Centre (DIFC) Data Protection Law and the Central Bank of the UAE (CBUAE) cyber resilience framework both include provisions that expect or require penetration testing for regulated entities. Financial institutions operating in the UAE should treat penetration testing as mandatory, regardless of whether their specific license category explicitly requires it.

Compliance Pentest Comparison Table

Here's how the major frameworks compare across the dimensions that matter most for planning your penetration testing program:

Use this table to identify which frameworks apply to your organization, then scope your penetration testing engagement to cover the union of their requirements. In many cases, a single well-scoped test can satisfy multiple frameworks simultaneously.

How to Prepare for a Compliance Pentest

The difference between a smooth compliance pentest and a frustrating one usually comes down to preparation. Here's your pre-engagement checklist.

1. Align Scope with the Framework

This is the single most important step. Before you engage a pentest provider, map out exactly which systems fall within your compliance scope:

• PCI-DSS: Document your cardholder data environment. Include network diagrams showing segmentation boundaries.
• ISO 27001: Reference your ISMS scope statement. Ensure the pentest scope matches.
• SOC 2: Align with your system description. The pentest should cover the systems you describe to your auditor.
• DORA: Identify critical business functions and the ICT systems that support them.

2. Gather Documentation

Have the following ready before the pentest kicks off:

• Network architecture diagrams
• Application inventory with URLs, APIs, and IP addresses
• User accounts for each role level (for authenticated testing)
• Previous pentest reports (so testers can verify prior findings are fixed)
• Change log of significant infrastructure or application changes since the last test
• Contact information for technical teams who can assist during testing

3. Time It Right

Timing your pentest incorrectly is one of the most common mistakes. Here's the formula:

• Schedule the pentest 2–4 months before your audit
• Allow 2–4 weeks for the testing itself
• Budget 4–8 weeks for remediation of findings
• Schedule a retest 1–2 weeks before the audit to verify fixes

Working backward from your audit date, this means you should start the pentest engagement process at least 4–5 months before the audit. If you wait until six weeks out, you're going to be scrambling.

4. Define Success Criteria

Agree with your pentest provider on what the final deliverable needs to include for your specific framework. This avoids the scenario where you receive a technically sound report that's missing the executive summary your SOC 2 auditor requires, or the segmentation validation section your QSA needs for PCI-DSS.

5. Brief Your Internal Teams

Make sure your SOC, DevOps, and infrastructure teams know when the pentest is happening. Nothing derails a compliance test faster than your SOC blocking the testers' IP addresses, or an overzealous WAF rule rate-limiting the assessment. Coordinate with your operations team to create testing windows and whitelist rules where appropriate.

Common Compliance Pentest Failures

After years of performing compliance-focused penetration tests, we've seen the same failures repeat across organizations of all sizes. Here are the ones that cause the most audit pain.

1. Wrong Scope

The number one failure. A company orders a web application pentest, but their compliance framework requires network-layer testing too. Or the test covers the production environment but misses the staging environment that also handles real data. If the scope doesn't match the framework's requirements, the test is worthless from a compliance perspective — even if it finds real vulnerabilities.

2. Testing Too Late

Companies that schedule their pentest four weeks before the audit deadline leave no time for remediation. The auditor sees a report full of critical findings with no evidence they were fixed. This is worse than not having a pentest at all — it's documented proof that you know about vulnerabilities and haven't addressed them.

3. Poor Report Formatting

A pentest report that's technically accurate but missing the sections your auditor expects will generate questions, delays, and potentially findings in the audit. Different frameworks have different expectations. PCI QSAs want segmentation validation details. SOC 2 auditors want management response sections. ISO auditors want risk register integration. A generic report template won't cut it.

4. Missing Remediation Evidence

Finding vulnerabilities is only half the story. Auditors want to see that you fixed them. This means you need:

• A remediation tracker showing each finding, its owner, target date, and current status
• Retest results confirming that critical and high findings are resolved
• A documented exception process for any findings you accepted as risk (with management sign-off)

5. No Retesting

You found 12 critical vulnerabilities, you fixed all 12, but you never retested. How does the auditor know the fixes actually work? They don't. Retesting is the remediation evidence that closes the loop. Without it, your audit narrative is incomplete.

6. Using Unqualified Testers

Some auditors will ask about the qualifications of the team that performed the pentest. If you hired the cheapest freelancer on a marketplace and they don't hold recognized certifications (OSCP, GPEN, CREST, CHECK), your auditor may not accept the results. For compliance pentests, tester qualifications matter.

How VulnSkill Delivers Compliance-Ready Reports

Every VulnSkill engagement is designed to produce audit-ready deliverables, not just a list of vulnerabilities. Here's what makes our compliance penetration testing different.

Framework-Mapped Scoping

Before testing begins, we map your engagement scope to the specific requirements of your compliance framework. If you're pursuing PCI-DSS, we validate that the scope covers your full CDE and segmentation boundaries. For ISO 27001, we align with your ISMS scope statement. For SOC 2, we reference your system description. This eliminates the most common compliance failure: scope mismatch.

Dual-Layer Reporting

Every report includes an executive summary written for non-technical stakeholders (your board, your auditor, your compliance committee) and a detailed technical section with CVSS-scored findings, proof-of-concept evidence, and step-by-step remediation guidance. Reports are formatted in the structure that auditors expect, with clear framework cross-references.

Remediation Tracking & Retesting

We don't disappear after delivering the report. Every engagement includes remediation support (guidance for your development team) and one round of retesting to verify fixes. We provide a formal retest letter confirming the status of each finding — the exact document your auditor wants to see.

Multi-Framework Coverage

If you need to satisfy multiple frameworks simultaneously — PCI-DSS and SOC 2, or ISO 27001 and NESA — we scope the engagement to cover the union of requirements and produce a report that maps findings to each applicable framework. One test, multiple compliance checkboxes.

Qualified, Certified Testers

Every VulnSkill tester holds recognized industry certifications (OSCP, GPEN, CREST, CEH) and has demonstrated experience with compliance-focused engagements. When your auditor asks who performed the test, you'll have a clear answer.

Frequently Asked Questions

Related Articles

• How Much Does Penetration Testing Cost in 2026?
• Penetration Testing Report Template + Examples
• VAPT Services in Dubai: Complete Guide
• What Is Penetration Testing? Complete 2026 Guide
• Penetration Testing Checklist: Web, Network & Cloud