Chapter 40: Security Compliance and Governance

"Compliance is the floor, not the ceiling. It tells you the minimum you must do, not everything you should do." --- Bruce Schneier

In September 2013, a penetration testing firm conducted a PCI DSS assessment of Target Corporation and found the company to be compliant. Three months later, attackers compromised Target's payment systems and stole 40 million credit card numbers and 70 million customer records. The breach cost Target over $300 million in settlements, legal fees, and remediation costs. It remains one of the most instructive examples of the gap between compliance and security.

This chapter explores the compliance and governance landscape that shapes penetration testing engagements. Understanding these frameworks is not optional for professional pentesters: they determine what you test, how you test it, what you report, and how your findings are used. More importantly, understanding the limitations of compliance frameworks helps you deliver testing that goes beyond checkbox security and actually improves your clients' security posture.

We will cover the major frameworks --- PCI DSS, HIPAA, SOC 2, ISO 27001 --- and the risk management standards that provide the analytical foundation for security programs. We will examine how penetration testing fits into the broader Governance, Risk, and Compliance (GRC) picture, and we will navigate the rapidly evolving international regulatory landscape, including GDPR's implications for security testing, the EU's NIS2 Directive, and the Digital Operational Resilience Act (DORA) that is reshaping financial sector security testing across Europe.

40.1 Compliance Frameworks: PCI DSS, HIPAA, SOC 2, ISO 27001

Four compliance frameworks drive the majority of commercial penetration testing engagements. Each has different origins, different requirements, and different implications for how you conduct testing.

40.1.1 PCI DSS (Payment Card Industry Data Security Standard)

Origin and Purpose: PCI DSS was created by the five major credit card brands (Visa, Mastercard, American Express, Discover, JCB) through the PCI Security Standards Council (PCI SSC). It mandates security controls for any organization that stores, processes, or transmits cardholder data. Unlike government regulations, PCI DSS is a contractual obligation enforced through the payment brands' relationships with acquiring banks.

Structure: PCI DSS version 4.0, effective March 2024 with new requirements fully enforced by March 2025, is organized into six objectives and twelve requirements:

Penetration Testing in PCI DSS: Requirement 11.4 mandates penetration testing. As we covered in detail in Chapter 38 (Section 38.5), PCI DSS requires: - Annual internal and external penetration testing - Testing after significant changes to the CDE - Network-layer and application-layer testing - Segmentation validation (every six months for service providers) - Testing methodology based on industry standards

Validation Levels: PCI DSS validation requirements depend on the organization's transaction volume:

MedSecure Context: MedSecure processes approximately 50,000 patient co-payment transactions annually, placing them at PCI Level 4. However, because they also handle healthcare data, their security testing must address both PCI DSS and HIPAA requirements simultaneously. During our engagement, we structured the testing to satisfy both frameworks: PCI DSS segmentation testing for the payment VLAN, and HIPAA-relevant testing for systems containing PHI.

40.1.2 HIPAA (Health Insurance Portability and Accountability Act)

Origin and Purpose: HIPAA is a US federal law enacted in 1996, with the Security Rule (effective 2005) and the HITECH Act (2009) adding specific security requirements. HIPAA applies to covered entities (healthcare providers, health plans, healthcare clearinghouses) and their business associates.

The Security Rule: The HIPAA Security Rule requires covered entities to implement administrative, physical, and technical safeguards to protect electronic protected health information (ePHI). Unlike PCI DSS, HIPAA does not prescribe specific technologies or testing frequencies --- it requires organizations to conduct a risk analysis and implement reasonable and appropriate safeguards.

Relevant Safeguards for Penetration Testers:

HIPAA and Penetration Testing: HIPAA does not explicitly mandate penetration testing. However, the HHS Office for Civil Rights (OCR) has repeatedly stated that risk analysis should include technical testing, and many healthcare organizations interpret this as requiring periodic penetration testing. After high-profile breaches (Anthem in 2015, Premera Blue Cross in 2015), OCR guidance increasingly emphasized technical security assessment.

HIPAA Enforcement: HIPAA violations can result in penalties ranging from $100 to $50,000 per violation (per record), with annual caps up to $1.5 million per violation category. In severe cases, criminal penalties apply. The largest HIPAA settlements have exceeded $16 million.

40.1.3 SOC 2 (System and Organization Controls 2)

Origin and Purpose: SOC 2 is a framework developed by the American Institute of Certified Public Accountants (AICPA) for service organizations. It evaluates an organization's controls relevant to five trust service criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. SOC 2 has become the de facto compliance standard for SaaS companies and technology service providers.

SOC 2 Report Types:

Penetration Testing in SOC 2: SOC 2 does not explicitly require penetration testing, but the Security trust service criterion (CC7.1) requires organizations to identify and manage security threats and vulnerabilities. Penetration testing is one of the most commonly cited controls for demonstrating this criterion. CPA firms performing SOC 2 audits will typically: - Review penetration test reports as evidence - Evaluate whether testing scope is appropriate - Assess whether identified vulnerabilities were remediated - Consider the testing methodology and frequency

SOC 2 Penetration Testing Best Practices: - Conduct testing at least annually - Include both internal and external testing - Test all components of the in-scope system - Demonstrate that findings were tracked to remediation - Show that testing methodology aligns with recognized standards

ShopStack Context: As a SaaS e-commerce platform, ShopStack's customers routinely request SOC 2 Type II reports before signing contracts. ShopStack's SOC 2 scope includes their AWS infrastructure, Node.js API, React frontend, and PostgreSQL databases. Our penetration testing engagement was specifically designed to generate evidence for ShopStack's SOC 2 audit, covering the CC7.1 (Vulnerability Management) and CC6.1 (Access Control) trust service criteria.

40.1.4 ISO 27001 (Information Security Management System)

Origin and Purpose: ISO 27001 is an international standard published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). It specifies requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). Unlike the US-centric frameworks above, ISO 27001 is used worldwide and is the most common information security certification globally.

Structure: ISO 27001:2022 (the current version) contains: - Clauses 4-10: Management system requirements (context, leadership, planning, support, operation, performance evaluation, improvement) - Annex A: 93 security controls organized into four themes (Organizational, People, Physical, Technological)

Penetration Testing in ISO 27001: Annex A control 8.8 (Management of technical vulnerabilities) requires organizations to manage technical vulnerabilities in a timely manner. The supporting guidance in ISO 27002 explicitly recommends penetration testing as a method for identifying vulnerabilities. Additionally:

• Clause 9.1 requires performance evaluation, including monitoring and measurement of the ISMS --- penetration testing provides objective measurement
• A.8.8 requires that vulnerabilities are identified and assessed for risk
• A.5.35 (previously A.18.2.3) requires independent review of information security, which penetration testing supports

Certification Process: Organizations achieve ISO 27001 certification through a two-stage external audit: - Stage 1: Documentation review (policies, procedures, risk assessment) - Stage 2: Evidence review and operational audit

Certification auditors (from accredited certification bodies like BSI, Bureau Veritas, or TUV) will review penetration test reports as evidence of effective vulnerability management and security monitoring.

40.1.5 Comparing Frameworks: A Practical Reference

For penetration testers who work across multiple frameworks, this comparison highlights the key differences that affect how you scope, execute, and report testing:

Key Insight for Testers: When a client is subject to multiple frameworks (common for healthcare organizations that handle payments, or technology companies with multiple compliance requirements), a single well-scoped penetration test can satisfy multiple frameworks simultaneously. The key is designing the scope, methodology, and reporting to address each framework's specific requirements. This is more efficient and cost-effective for the client than conducting separate tests for each framework.

40.1.6 Compliance as a Moving Target

Compliance frameworks are not static. They evolve in response to new threats, technologies, and regulatory philosophies:

PCI DSS Evolution: - Version 1.0 (2004): Basic security requirements - Version 2.0 (2010): Enhanced scoping guidance, more specific testing requirements - Version 3.0 (2013): Penetration testing methodology requirements formalized - Version 3.2.1 (2018): MFA requirements expanded, penetration testing guidance updated - Version 4.0 (2022): Customized approach introduced, enhanced authentication, risk-based testing frequency

HIPAA Evolution: - Original Security Rule (2003): Administrative, physical, and technical safeguards - HITECH Act (2009): Breach notification requirements, increased penalties - Omnibus Rule (2013): Business associate liability, enhanced enforcement - 2023 NPRM: Proposed updates including specific security testing requirements

ISO 27001 Evolution: - 2005 edition: 133 controls in 11 domains - 2013 revision: 114 controls in 14 domains - 2022 revision: 93 controls in 4 themes, new controls for cloud, threat intelligence, data masking

For penetration testers, tracking framework evolution is important because: - New requirements create new testing demands - Updated frameworks may change scope definitions - Clients may need testing against both old and new versions during transition periods - Staying current differentiates you from competitors who test against outdated standards

40.2 Security Testing Requirements in Regulations

Beyond the four major frameworks, numerous regulations either mandate or strongly imply security testing requirements. Understanding these requirements helps pentesters position their services effectively and ensures testing meets regulatory expectations.

40.2.1 Financial Services Regulations

GLBA (Gramm-Leach-Bliley Act): US federal law requiring financial institutions to explain their information-sharing practices and safeguard sensitive data. The Safeguards Rule (updated 2023) requires penetration testing and vulnerability assessments for financial institutions.

FFIEC IT Examination Handbook: The Federal Financial Institutions Examination Council publishes guidance that US bank examiners use. The Information Security booklet explicitly recommends penetration testing as part of an institution's information security program.

NY DFS Cybersecurity Regulation (23 NYCRR 500): New York State's Department of Financial Services requires covered entities to conduct annual penetration testing and bi-annual vulnerability assessments. This regulation is notable for its prescriptive technical requirements, including: - Annual penetration testing of information systems - Bi-annual vulnerability assessments - Continuous monitoring or periodic penetration testing for material changes - Specific requirements for the qualifications of the testing team

40.2.2 Healthcare Regulations

HIPAA (covered in 40.1.2)

HITECH Act: Extended HIPAA's breach notification requirements and increased penalties. Indirectly drives penetration testing by making breach consequences more severe.

FDA Cybersecurity Guidance: For medical device manufacturers, the FDA has published guidance on cybersecurity in medical devices that recommends security testing throughout the device lifecycle. This creates penetration testing opportunities in the medical device industry.

40.2.3 Defense and Government Regulations

CMMC (Cybersecurity Maturity Model Certification): The US Department of Defense requires contractors handling Controlled Unclassified Information (CUI) to achieve CMMC certification. CMMC Level 2 (Advanced) maps to NIST SP 800-171 and includes vulnerability scanning and assessment requirements.

FedRAMP: Cloud service providers seeking to work with US federal agencies must achieve FedRAMP authorization. The assessment process includes penetration testing conducted by a Third-Party Assessment Organization (3PAO).

FISMA (Federal Information Security Modernization Act): Requires US federal agencies to implement information security programs. Penetration testing is part of the ongoing assessment and authorization process for federal information systems.

40.2.4 Cross-Industry Requirements

State Data Breach Laws: All 50 US states have data breach notification laws. While they do not mandate penetration testing, the threat of breach notification (and associated costs) drives organizations to conduct testing proactively.

Cyber Insurance: Increasingly, cyber insurance underwriters require penetration testing as a condition of coverage. Insurance questionnaires frequently ask: - When was the last penetration test conducted? - What methodology was used? - Were critical findings remediated? - Is testing conducted by an independent third party?

Professional Tip: When meeting with prospective clients, ask about their regulatory environment early. Understanding which regulations apply helps you scope the engagement appropriately, reference the right standards in your proposal, and structure your report to provide evidence the client needs for their compliance obligations.

40.3 Risk Management Frameworks (NIST CSF, CIS Controls)

Compliance frameworks tell organizations what they must do. Risk management frameworks help organizations decide what they should do. Understanding these frameworks helps penetration testers align their work with the client's broader security strategy.

40.3.1 NIST Cybersecurity Framework (CSF) 2.0

The National Institute of Standards and Technology published the Cybersecurity Framework (CSF) in 2014, updated to version 2.0 in February 2024. While initially targeted at critical infrastructure, CSF has become the most widely adopted security framework in the United States across all industries.

CSF 2.0 Core Functions:

CSF 2.0 expanded from five to six core functions:

How Penetration Testing Maps to CSF:

Penetration testing touches multiple CSF functions:

• IDENTIFY (ID.RA): Risk Assessment --- Penetration testing identifies vulnerabilities and threats that inform risk assessments
• PROTECT (PR.AC, PR.DS, PR.IP): Access Control, Data Security, Information Protection --- Testing validates that protective controls work as intended
• DETECT (DE.CM, DE.DP): Security Continuous Monitoring, Detection Processes --- Testing evaluates whether the organization can detect attack activities
• RESPOND (RS.AN): Analysis --- Penetration testing results feed incident response capability development

CSF Tiers: CSF defines four implementation tiers that describe the degree to which an organization's cybersecurity risk management practices exhibit the characteristics defined in the framework:

40.3.2 CIS Controls (Center for Internet Security)

The CIS Controls (formerly the SANS Top 20, now CIS Critical Security Controls v8.1) provide a prioritized set of actions that organizations should take to defend against the most common cyber attacks. They are explicitly prioritized --- organizations should implement them in order.

CIS Controls v8.1 --- Security Testing-Related Controls:

CIS Control 18 in Detail: Control 18 specifically addresses penetration testing with the following sub-controls:

• 18.1: Establish and maintain a penetration testing program
• 18.2: Perform periodic external penetration tests (at least annually)
• 18.3: Remediate penetration test findings
• 18.4: Validate security measures after penetration tests
• 18.5: Perform periodic internal penetration tests (at least annually)

Implementation Groups: CIS organizes controls into three Implementation Groups (IGs) based on organizational resources and risk:

40.3.3 NIST SP 800-53 and the Risk Management Framework

NIST Special Publication 800-53 provides a catalog of security and privacy controls for federal information systems. While primarily aimed at US government, many private sector organizations adopt 800-53 controls.

Relevant Control Families for Penetration Testing:

• CA (Assessment, Authorization, and Monitoring): CA-8 specifically requires penetration testing
• RA (Risk Assessment): RA-5 requires vulnerability scanning; RA-3 requires risk assessment
• SI (System and Information Integrity): SI-2 requires flaw remediation

The Risk Management Framework (RMF): NIST's RMF (described in SP 800-37) provides a structured process for integrating security into the system development life cycle:

1. Categorize the information system
2. Select security controls
3. Implement security controls
4. Assess security controls (penetration testing fits here)
5. Authorize the information system
6. Monitor security controls continuously

40.3.4 Risk Quantification: FAIR Model

The Factor Analysis of Information Risk (FAIR) model provides a quantitative approach to risk analysis that is increasingly used alongside penetration testing results.

How FAIR Works: FAIR decomposes risk into two primary factors: - Loss Event Frequency (LEF): How often a loss event is likely to occur - Loss Magnitude (LM): How much loss is likely to result

Each factor is further decomposed: - LEF = Threat Event Frequency x Vulnerability (probability of success) - LM = Primary Loss + Secondary Loss

Integrating Pentest Results with FAIR: Penetration testing results can directly inform FAIR analysis: - Demonstrated exploitation success rates inform the Vulnerability factor - Evidence of existing attacks or attempted attacks informs Threat Event Frequency - Demonstrated access to sensitive data informs Loss Magnitude (data exposure scope) - Segmentation testing results inform the probability of threat actors reaching critical assets

Example: MedSecure F-001 FAIR Analysis:

This quantitative analysis gives leadership a financial basis for risk-based decision making that complements the CVSS-based severity ratings in the pentest report.

40.4 Security Program Maturity Models

Maturity models help organizations understand where they stand and where they need to go. For penetration testers, understanding maturity models helps calibrate recommendations and expectations.

40.4.1 The Capability Maturity Model Integration (CMMI) Approach

Most security maturity models follow the CMMI five-level structure:

40.4.2 BSIMM (Building Security In Maturity Model)

BSIMM measures software security initiatives across organizations. Version 14 analyzed data from over 130 organizations. BSIMM organizes activities into twelve practices across four domains:

BSIMM's penetration testing practice tracks three levels: - PT1: Use external penetration testers - PT2: Conduct internal penetration testing - PT3: Use penetration testing to inform security requirements and software development

40.4.3 Assessing Client Maturity

When you arrive at a new client, quickly assess their security maturity. This calibrates your testing approach, your recommendations, and your expectations for remediation:

Indicators of Low Maturity (Level 1-2): - This is their first penetration test - No vulnerability management program exists - Patching is ad hoc - No security policies or they are outdated - Security team is one person (or zero) - "Compliance" is viewed as the goal, not as a baseline

Indicators of Medium Maturity (Level 3): - Regular penetration testing cycle (annual or more frequent) - Vulnerability management program with SLAs for remediation - Security policies exist and are reviewed regularly - Dedicated security team - Risk-based approach to security decisions

Indicators of High Maturity (Level 4-5): - Continuous testing program (pentesting, red teaming, bug bounty) - Metrics-driven security program with dashboards and trend analysis - Security integrated into development pipeline (DevSecOps) - Threat intelligence program informs testing priorities - Regular purple team exercises

Calibrating Recommendations: If you find a SQL injection at a Level 1 client, your recommendation needs to explain what parameterized queries are and why they matter. At a Level 4 client, you can recommend integrating SAST/DAST into their CI/CD pipeline and assume they know what you mean. The same finding, two very different remediation approaches.

40.4.4 Security Testing Maturity Model

Specifically for penetration testing programs, we can define a more granular maturity model that helps organizations understand where they are and where they should be:

Level 1: Ad Hoc Testing - Penetration tests are conducted only when triggered by an incident or compliance requirement - No regular testing cadence - Testing firm selected based on lowest price - Findings are addressed reactively (if at all) - No tracking of remediation status - Reports are filed and forgotten

Level 2: Periodic Testing - Annual penetration test conducted for compliance purposes - Standard scope (external network, basic web application) - Testing firm selected based on qualifications and price - Findings tracked in a spreadsheet - Some findings remediated before next annual test - Results reported to IT management

Level 3: Structured Testing Program - Regular testing cadence (annual pentest + quarterly vulnerability scans) - Scope includes internal network, Active Directory, web applications - Testing methodology documented and aligned with standards (PTES, OWASP) - Findings tracked in vulnerability management platform with SLAs - Remediation verified through retesting - Results reported to CISO and risk committee - Year-over-year trend analysis

Level 4: Integrated Testing Program - Continuous testing: pentests, red team exercises, bug bounty, automated DAST/SAST - Scope includes cloud infrastructure, APIs, mobile, supply chain - Testing integrated with SDLC (security testing in CI/CD pipeline) - Findings integrated with GRC platform and risk register - Metrics-driven: mean time to remediation, findings trend, testing coverage - Results drive security strategy and budget decisions - Purple team exercises bridge offensive and defensive functions

Level 5: Adaptive Security Testing - Threat intelligence-led testing (TIBER, CBEST, custom threat scenarios) - Continuous automated testing supplemented by expert manual testing - Security testing drives architectural decisions and system design - Predictive analytics: using historical data to anticipate future risk areas - Security testing is embedded in organizational culture, not just IT - External testing validated by internal red team and vice versa - Industry-leading practices shared through community contribution

Assessing Your Client: When you begin an engagement, quickly assess which level the client operates at. This informs not just how you test, but how you write your report and what you recommend. Recommending Level 5 practices to a Level 1 organization creates frustration; recommending Level 2 practices to a Level 4 organization wastes their time. Meet the client where they are and recommend the next level up.

40.5 Governance, Risk, and Compliance (GRC) Integration

GRC is the integrated approach to managing governance (setting policies and ensuring accountability), risk management (identifying and mitigating risks), and compliance (meeting regulatory requirements). Penetration testing is a key input to the GRC function.

40.5.1 How Pentest Results Feed GRC

Penetration testing results flow into multiple GRC processes:

Risk Register Updates: Each pentest finding becomes a risk entry in the organization's risk register. The risk register typically includes: - Risk description (the vulnerability) - Likelihood of exploitation - Impact if exploited - Current controls (what mitigates the risk) - Residual risk (risk remaining after controls) - Risk owner (who is responsible for addressing it) - Treatment plan (remediate, accept, transfer, avoid)

Compliance Evidence: Pentest reports serve as evidence for multiple compliance requirements: - PCI DSS Requirement 11.4 (penetration testing) - SOC 2 CC7.1 (vulnerability management) - ISO 27001 A.8.8 (technical vulnerability management) - HIPAA Security Rule risk analysis

Board Reporting: GRC teams distill penetration testing results into board-level security metrics: - Number and severity of findings - Trend over time (are we improving?) - Mean time to remediation - Percentage of findings remediated within SLA - Risk score trend

40.5.2 GRC Platforms and Integration

Modern GRC platforms (ServiceNow GRC, Archer, OneTrust, LogicGate) automate the integration of penetration testing results into the broader GRC program. As a pentester, you may be asked to:

• Import findings directly into the client's GRC platform
• Map findings to specific control frameworks (PCI DSS, NIST CSF)
• Provide machine-readable output (CSV, JSON, XML) for automated import
• Track findings through remediation and retest cycles within the platform

40.5.3 The Three Lines of Defense Model

Many organizations use the three lines of defense model for risk management:

External penetration testers typically work with the second line (security/risk teams) but report findings to the first line (system owners) for remediation. Internal audit (third line) may commission their own independent penetration tests to validate the second line's security program.

40.5.4 Risk Acceptance and Exception Management

Not every pentest finding will be remediated. Some findings may be accepted as residual risk because: - The cost of remediation exceeds the risk (rare, but it happens) - The system is scheduled for decommission - Compensating controls sufficiently mitigate the risk - The business function requires the current configuration

When a client chooses to accept a risk, the decision should be: - Documented formally (risk acceptance form) - Approved by an appropriate authority (typically risk owner + CISO or CIO) - Time-limited (reviewed annually at minimum) - Monitored for changes in the threat landscape

Professional Tip: If a client tells you to change a finding's severity because they "don't agree with the rating," politely decline. Your risk rating is your professional assessment. They are welcome to document their risk acceptance decision, but your report should reflect the actual risk as you assessed it. Compromising your ratings undermines your credibility and your value.

40.6 International Regulations (GDPR, NIS2, DORA)

The regulatory landscape is increasingly global. Even US-based pentesters frequently encounter international regulations, especially when testing for multinational clients or organizations with European customers.

40.6.1 GDPR (General Data Protection Regulation)

The EU's General Data Protection Regulation (effective May 2018) is the world's most comprehensive data protection law. While primarily focused on data privacy, GDPR has significant implications for security testing.

GDPR Security Requirements: Article 32 requires data controllers and processors to implement "appropriate technical and organisational measures" to ensure security, including: - Pseudonymization and encryption of personal data - Ability to ensure ongoing confidentiality, integrity, availability, and resilience - Ability to restore data in a timely manner - A process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures

That last bullet point --- regularly testing and evaluating security measures --- directly supports penetration testing. GDPR does not prescribe specific testing frequencies or methodologies, but regulators expect organizations to demonstrate that they regularly test their security posture.

GDPR Implications for Pentesters:

Data Processing During Testing: When you conduct a penetration test, you may access personal data protected by GDPR. This creates several obligations: - You are acting as a data processor on behalf of the client (data controller) - A Data Processing Agreement (DPA) should be in place before testing begins - You must implement appropriate security measures for any personal data you access - You must delete personal data after the engagement (data minimization) - You must report any personal data breaches (even those discovered during testing)

Cross-Border Testing: If you are testing systems that process EU personal data from outside the EU, additional considerations apply: - Ensure lawful basis for data transfer (Standard Contractual Clauses, adequacy decisions) - Document the data processing activities in your engagement documentation - Be prepared to demonstrate GDPR compliance to supervisory authorities

GDPR Penalties: Administrative fines up to 4% of annual global turnover or 20 million euros (whichever is higher). The largest GDPR fines have exceeded 1.2 billion euros (Meta, 2023).

40.6.2 NIS2 Directive (Network and Information Security Directive 2)

The EU's NIS2 Directive (effective October 2024, with member states required to transpose by October 2024) significantly expands the scope and requirements of the original NIS Directive.

Who Does NIS2 Apply To?

NIS2 applies to "essential" and "important" entities in specified sectors:

Essential Entities (stricter requirements): - Energy (electricity, oil, gas, hydrogen) - Transport (air, rail, water, road) - Banking and financial market infrastructure - Health (hospitals, laboratories, pharmaceuticals) - Drinking water and wastewater - Digital infrastructure (DNS, TLD registries, cloud, data centers) - Public administration - Space

Important Entities: - Postal and courier services - Waste management - Chemical manufacturing - Food production and distribution - Manufacturing (medical devices, electronics, vehicles) - Digital providers (online marketplaces, search engines, social networks) - Research organizations

NIS2 Security Testing Requirements:

Article 21 requires entities to implement cybersecurity risk-management measures including: - Risk analysis and information system security policies - Incident handling and reporting - Business continuity and crisis management - Supply chain security - Security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure - Policies and procedures to assess the effectiveness of cybersecurity risk-management measures

That last point directly implies penetration testing. NIS2 also requires: - Cybersecurity awareness training - Encryption and multi-factor authentication policies - Incident reporting to national CSIRTs within 24 hours (early warning) and 72 hours (full notification)

NIS2 Enforcement: Member states must establish supervisory authorities with the power to: - Conduct audits and inspections - Request evidence of compliance - Issue binding instructions for remediation - Impose administrative fines up to 10 million euros or 2% of worldwide annual turnover for essential entities

40.6.3 DORA (Digital Operational Resilience Act)

DORA (Regulation (EU) 2022/2554, effective January 17, 2025) is the EU's regulation specifically targeting the financial sector's digital operational resilience.

Why DORA Matters for Pentesters:

DORA is the most prescriptive EU regulation regarding penetration testing. It requires:

ICT Risk Management (Article 6-16): Financial entities must establish and maintain an ICT risk management framework that includes: - ICT systems identification and documentation - Protection and prevention measures - Detection mechanisms - Response and recovery procedures - Learning and evolving from incidents

Digital Operational Resilience Testing (Article 24-27): DORA requires three levels of testing:

1. Basic Testing (All entities): - Vulnerability assessments and scans - Open-source analyses - Network security assessments - Gap analyses - Physical security reviews - Software composition analyses - Source code reviews (where applicable)

2. Advanced Testing (Significant entities): - Threat-Led Penetration Testing (TLPT) at least every three years - TLPT must follow the TIBER-EU framework - Testing must be conducted by qualified, independent testers - CREST accreditation or equivalent is expected

3. Third-Party Testing: - Testing of critical ICT third-party service providers - Pooled testing arrangements for shared infrastructure

DORA TLPT Requirements (Article 26): Threat-Led Penetration Testing under DORA must: - Cover several or all critical functions of the financial entity - Be performed on live production systems - Be based on threat intelligence specific to the entity - Use qualified threat intelligence providers and red team testers - Include a red team phase, a threat intelligence phase, and a closure phase - Be overseen by the financial entity's management body - Results must be shared with the relevant competent authority

Market Impact: DORA has created enormous demand for CREST-accredited penetration testing firms in Europe. Financial institutions that previously relied on basic annual pentests must now implement sophisticated threat-led testing programs. For penetration testers, DORA represents both a significant market opportunity and a quality bar: if you want to work in European financial sector security testing, CREST accreditation (or equivalent) is effectively mandatory.

40.6.4 The Relationship Between Data Protection and Security Testing

A nuanced challenge arises when data protection regulations intersect with security testing activities. Penetration testers must understand this intersection to avoid creating compliance problems while solving security problems.

GDPR and Penetration Testing --- Detailed Considerations:

Lawful Basis for Testing: When penetration testing involves accessing personal data, there must be a lawful basis under GDPR Article 6. The most common bases are: - Legitimate interests (Article 6(1)(f)): The organization's legitimate interest in testing its security. A legitimate interest assessment (LIA) should document that the testing is necessary, proportionate, and that data subject rights are considered. - Legal obligation (Article 6(1)(c)): If the testing is required by regulation (e.g., NIS2, DORA), the legal obligation basis applies.

Data Minimization During Testing: GDPR Article 5(1)(c) requires data minimization. When penetration testers access databases containing personal data: - Extract only the minimum data necessary to prove the vulnerability (e.g., three redacted records, not the entire database) - Redact or pseudonymize personal data in evidence screenshots - Do not retain personal data beyond the engagement - Document what data was accessed and why in the engagement records

Data Breach Notification: If a penetration tester accidentally causes a data breach (e.g., unintentionally exposing personal data through a testing error), the organization may be required to notify the supervisory authority within 72 hours (Article 33). The Rules of Engagement should address this scenario explicitly.

Cross-Border Considerations: Testing from one country against systems in another raises data transfer questions. If the testing team is outside the EU but accesses personal data on EU servers, the engagement agreement should include Standard Contractual Clauses (SCCs) or rely on an adequacy decision (for countries deemed adequate by the EU Commission).

Employee Data: Penetration tests that include social engineering (phishing simulations) access employee personal data. Some EU member states have employee consultation requirements that must be addressed before conducting social engineering tests. Works councils in Germany, for example, may need to be informed before phishing tests are conducted.

40.6.5 Mapping Pentest Findings to Multiple Frameworks

One of the most valuable services a penetration tester can provide is mapping each finding to the specific compliance frameworks that apply to the client. This transforms a generic vulnerability report into a compliance evidence document.

Creating a Multi-Framework Mapping Table:

For each finding, create a cross-reference table that maps to every applicable framework:

Benefits of Multi-Framework Mapping: - The client's compliance team can immediately identify which audit requirements each finding affects - Demonstrates the penetration tester's understanding of the regulatory landscape - Helps the client prioritize remediation: a finding that affects three frameworks simultaneously is more urgent than one that affects only one - Reduces the compliance team's workload: they do not need to independently map each finding - Creates a reusable template that can be updated for future assessments

Building the Mapping: Developing accurate multi-framework mappings requires familiarity with each framework's control structure. Useful cross-reference resources include: - NIST's SP 800-53 control mapping to ISO 27001 and NIST CSF - The Cloud Security Alliance's Cloud Controls Matrix (CCM), which maps to multiple frameworks - The Secure Controls Framework (SCF), which provides mappings across 100+ regulatory frameworks - PCI SSC's published mapping between PCI DSS 4.0 and ISO 27001

Professional Tip: Create a master mapping spreadsheet for the frameworks you encounter most frequently. Over time, this becomes an invaluable reference that allows you to quickly map new finding types to relevant compliance requirements. Some GRC platforms (like Drata, Vanta, or OneTrust) automate portions of this mapping.

Compliance-Specific Reporting Sections:

Consider adding a dedicated compliance mapping appendix to your report. For each applicable framework, include: - A summary of which controls were tested (and which were not) - A finding-by-control mapping showing which findings affect which controls - An assessment of the organization's compliance posture based on testing results - Specific recommendations for addressing compliance gaps

This appendix transforms a penetration testing report from a technical document into a compliance asset that the client's audit team can use directly with their QSA, external auditor, or certification body.

40.6.6 Evidence Preservation for Compliance Audits

Penetration testing evidence must be preserved in a manner that satisfies auditor requirements. Poor evidence handling can undermine an otherwise excellent testing engagement.

Evidence Chain of Custody: Maintain a documented chain of custody for all evidence: - Timestamp every screenshot, command output, and log file at the moment of capture - Use a consistent file naming convention (e.g., F001-001-sqli-boolean.png, F001-002-sqli-data-extraction.png) - Calculate and record cryptographic hashes (SHA-256) of evidence files - Store evidence in a write-once repository during the engagement - Document who captured the evidence, when, and under what circumstances

Evidence Retention: Different frameworks have different retention requirements:

What Auditors Look For in Evidence: When auditors review penetration testing evidence, they evaluate: - Completeness: Is there evidence for every finding in the report? - Authenticity: Could the evidence have been fabricated or altered? (Timestamps and hashes help here) - Relevance: Does the evidence directly support the finding as described? - Contemporaneity: Was the evidence captured during the documented testing window? - Clarity: Can the auditor understand the evidence without the tester's verbal explanation?

Secure Evidence Storage: Evidence from penetration tests contains sensitive information (vulnerability details, potentially accessible data, attack paths). Store it securely: - Encrypted at rest (AES-256 or equivalent) - Access-controlled (only authorized personnel) - Backed up according to the firm's data protection policy - Destroyed according to the engagement agreement and applicable retention requirements - Segregated by client (no cross-contamination between engagement evidence)

MedSecure Example: For the MedSecure engagement, all evidence was stored in an encrypted volume on the testing firm's evidence server. SHA-256 hashes of all evidence files were recorded in the engagement log at the time of capture. The engagement agreement specified 12-month retention (aligned with PCI DSS requirements), after which all evidence would be securely destroyed. When MedSecure's QSA requested the penetration testing evidence six months later, the firm provided the original evidence files along with the hash verification log, allowing the QSA to confirm that the evidence had not been modified since capture.

40.6.7 Other International Regulations

Australia --- Security of Critical Infrastructure Act (SOCI Act): Requires critical infrastructure entities to adopt and maintain a critical infrastructure risk management program, including cybersecurity measures and reporting obligations.

Singapore --- Cybersecurity Act: Designates Critical Information Infrastructure (CII) and requires owners to conduct cybersecurity audits and risk assessments. The Cyber Security Agency (CSA) publishes sector-specific codes of practice.

Japan --- Act on Protection of Personal Information (APPI): Requires businesses handling personal information to implement security control measures, including regular assessment of security practices.

Brazil --- LGPD (Lei Geral de Proteção de Dados): Brazil's general data protection law, modeled on GDPR, requires appropriate security measures including regular security assessments.

Middle East --- NESA (National Electronic Security Authority, UAE): The UAE's cybersecurity regulatory framework includes requirements for regular security testing of critical infrastructure.

40.6.8 Compliance-Driven Testing Methodologies

Different compliance frameworks impose different testing requirements, and understanding these differences allows penetration testers to design engagements that satisfy multiple frameworks efficiently.

PCI DSS 4.0 Penetration Testing Methodology Requirements: PCI DSS is the most prescriptive framework regarding how penetration testing should be conducted. Requirement 11.4 specifies: - Testing must follow an industry-accepted methodology (PTES, OWASP, NIST SP 800-115, CREST) - Testing must cover the entire CDE perimeter and critical systems - Testing must include both network-layer and application-layer tests - Testing from both inside and outside the network is required - Testing must include segmentation validation (if segmentation is used to reduce scope) - Testing must be performed by a qualified internal or external resource with organizational independence

HIPAA Security Testing Considerations: HIPAA does not prescribe a specific testing methodology, but the Security Rule's risk analysis requirement (164.308(a)(1)(ii)(A)) and technical safeguard evaluation requirement (164.308(a)(8)) create implicit testing expectations: - Testing should cover all systems that create, receive, maintain, or transmit ePHI - Testing should evaluate access controls (164.312(a)(1)), audit controls (164.312(b)), integrity controls (164.312(c)(1)), and transmission security (164.312(e)(1)) - Social engineering testing is particularly relevant because HIPAA's workforce training requirements (164.308(a)(5)) should protect against phishing attacks - Medical device testing may require coordination with the device manufacturer and compliance with FDA premarket cybersecurity guidance

SOC 2 Testing Alignment: SOC 2 examinations evaluate controls against Trust Services Criteria. Penetration testing supports multiple criteria: - CC6.1 (logical and physical access controls): test access control effectiveness - CC6.6 (security of system boundaries): test network segmentation and perimeter defenses - CC7.1 (vulnerability identification): demonstrate vulnerability assessment capability - CC7.2 (anomaly detection): test whether the organization detects penetration testing activities

A valuable practice is to structure the penetration testing report with explicit SOC 2 criteria references, allowing the CPA firm conducting the SOC 2 examination to easily map testing results to the relevant criteria.

ISO 27001 Audit Support: ISO 27001:2022 addresses technical vulnerability management in control A.8.8 and security testing in A.8.34 (protection of information systems during audit testing). When conducting tests that will support ISO 27001 certification: - Document that the testing was conducted by qualified, independent testers - Ensure the testing scope aligns with the ISMS scope - Provide evidence that findings feed into the organization's risk assessment process - Demonstrate that findings are tracked through the organization's corrective action process

Designing Multi-Framework Engagements: When a client is subject to multiple frameworks, design the engagement to satisfy the most stringent requirements across all applicable frameworks. For MedSecure, which is subject to HIPAA, PCI DSS, and cyber insurance requirements: - Use PCI DSS requirements as the baseline (they are the most prescriptive) - Extend the scope to include ePHI systems not in the CDE (for HIPAA) - Include the full perimeter per the cyber insurance policy requirements - Produce a single report with framework-specific mapping sections - Schedule testing to meet the most frequent required cadence

This integrated approach costs the client approximately 30-40% less than separate framework-specific engagements and provides better coverage because the tester examines the entire environment holistically rather than through separate compliance lenses.

40.6.9 The Compliance Convergence Trend

A significant trend in the regulatory landscape is the convergence of requirements across frameworks and jurisdictions. This convergence creates both opportunities and challenges for penetration testers:

What Is Converging: - Security testing requirements: Nearly all modern frameworks now require or recommend regular security testing - Risk-based approaches: Frameworks are shifting from prescriptive controls to risk-based requirements - Incident reporting: Timelines are converging around 72 hours for initial notification - Third-party risk management: Supply chain security requirements are appearing in virtually every framework - Board-level accountability: Personal liability for management is expanding globally

What Remains Different: - Scope definitions: Each framework defines its scope differently (CDE for PCI, ePHI for HIPAA, critical functions for DORA) - Enforcement mechanisms: Some are enforced through fines (GDPR), others through contractual consequences (PCI DSS), others through market consequences (SOC 2) - Specific technical requirements: PCI DSS is prescriptive about encryption standards; HIPAA is principles-based - Geographic applicability: EU regulations affect EU operations; US regulations affect US operations; but multinational organizations face all of them simultaneously

Implications for Penetration Testers: The convergence trend means that a well-designed penetration testing program can satisfy multiple frameworks simultaneously. However, the remaining differences require careful attention to: - Scope alignment (ensuring the testing scope covers all applicable framework requirements) - Reporting format (some frameworks require specific report structures or evidence formats) - Tester qualifications (some frameworks require specific certifications or accreditations) - Testing frequency (the most frequent requirement should drive the testing cadence)

MedSecure Multi-Framework Example: MedSecure is subject to HIPAA (healthcare data), PCI DSS (payment processing), and their cyber insurance policy requires annual penetration testing. Rather than conducting three separate tests, we designed a single engagement that covered all requirements. The scope included the CDE (PCI DSS), ePHI systems (HIPAA), and the full external/internal perimeter (cyber insurance). The report was structured with a single executive summary but separate compliance mapping sections for each framework. Total cost: approximately 60% of what three separate engagements would have cost, with better coverage due to the integrated approach.

40.6.10 Preparing for Regulatory Audits

Penetration testers can help clients prepare for regulatory audits by understanding what auditors look for:

PCI DSS QSA Assessment: The QSA will review: - Is the testing methodology documented and based on an industry-accepted approach? - Does the scope cover the entire CDE and connected systems? - Were both internal and external tests conducted? - Was segmentation validated? - Were application-layer tests conducted against OWASP Top 10? - Were findings remediated and retested?

SOC 2 Audit: The CPA firm will review: - Does penetration testing evidence support the Security trust service criterion (CC7.1)? - Were tests conducted by qualified, independent testers? - Were findings tracked to remediation? - Is there a regular testing cadence?

ISO 27001 Certification Audit: The certification body will review: - Does the organization conduct regular technical vulnerability assessments (A.8.8)? - Are the results of security testing used to improve the ISMS? - Is there an independent review of information security (A.5.35)?

HIPAA OCR Investigation: If investigating a breach, OCR will review: - Was a risk analysis conducted (and was penetration testing part of it)? - Were identified risks addressed through safeguards? - Were appropriate technical safeguards implemented (access controls, audit controls, encryption)?

For each audit type, structure your report to directly support the evidence requirements. This might mean including a compliance mapping section that explicitly references the framework requirements your testing addressed.

40.7 Chapter Summary

Security compliance and governance form the business context for nearly every penetration testing engagement. Understanding these frameworks is not just about meeting minimum requirements --- it is about delivering testing that creates maximum value for your clients within their specific regulatory environment.

Key Concepts Reviewed

Compliance Frameworks: - PCI DSS mandates annual penetration testing for organizations handling cardholder data, with specific requirements for scope, methodology, and segmentation validation - HIPAA requires risk analysis and appropriate safeguards for ePHI, with penetration testing as a recommended practice - SOC 2 uses pentest reports as evidence for the Security trust service criterion - ISO 27001 requires technical vulnerability management and independent security review, supported by penetration testing

Regulatory Landscape: - Financial services regulations (GLBA, FFIEC, NY DFS) have become increasingly prescriptive about security testing - Healthcare regulations (HIPAA, HITECH, FDA) drive testing in the healthcare and medical device sectors - Government regulations (CMMC, FedRAMP, FISMA) require testing for contractors and service providers - Cyber insurance underwriters increasingly require penetration testing evidence

Risk Management: - NIST CSF 2.0 provides six core functions (Govern, Identify, Protect, Detect, Respond, Recover) for organizing security programs - CIS Controls offer a prioritized implementation path, with Control 18 specifically addressing penetration testing - NIST SP 800-53 provides detailed security controls used in government and increasingly in the private sector

Security Maturity: - Maturity models help calibrate testing approach and recommendations - Low-maturity organizations need basic testing and foundational recommendations - High-maturity organizations benefit from continuous testing, red teaming, and metrics-driven approaches

GRC Integration: - Pentest results feed risk registers, compliance evidence, and board reporting - GRC platforms automate findings tracking and remediation management - The three lines of defense model clarifies roles and responsibilities - Risk acceptance decisions must be formally documented and time-limited

International Regulations: - GDPR Article 32 requires regular testing of security measures; pentesters must handle personal data as data processors - NIS2 expands security requirements across essential and important entities in the EU - DORA mandates threat-led penetration testing (TLPT) for significant financial entities using TIBER-EU methodology - Global regulations are converging on requirements for regular security testing

What's Next

In Chapter 41, we will explore career paths and continuous learning in ethical hacking. Whether you want to become a senior penetration tester, a red team lead, a security consultant, or an independent researcher, understanding the certification landscape, skill-building resources, and professional community will help you build a successful and fulfilling career.

Blue Team Perspective: Compliance frameworks give you leverage to secure budget for security improvements. When you need to justify a security investment to leadership, map the request to a specific compliance requirement. "We need a WAF" is a weak argument. "PCI DSS Requirement 6.4.2 requires us to deploy a web application firewall for public-facing applications, and our last pentest demonstrated why" is a much stronger one.

Try It in Your Lab: Pick one compliance framework and map your home lab testing activities against it. If you chose PCI DSS, pretend your lab has a "payment network" segment and test the segmentation between it and your "corporate" network. This exercise develops your ability to think in compliance terms while performing technical testing.