Penetration Testing for Compliance

Learn about pen testing for PCI DSS, HIPAA, SOC 2, ISO 27001, CMMC, FedRAMP, NYDFS, GDPR, FTC Safeguards Rule, and much more, through the Frequently Asked Questions (FAQs) below. Please schedule a consultation if you are looking for Penetration Testing for compliance or regulatory requirements or to comply with a global security standard..

Which compliance frameworks require penetration testing?

Penetration testing is required or strongly mandated by a significant number of major compliance frameworks. PCI DSS (Payment Card Industry Data Security Standard) explicitly requires annual external and internal penetration testing under Requirement 11.4. HIPAA’s Security Rule at 45 CFR 164.308(a)(8) requires periodic technical security evaluations, and a proposed rule update published January 6, 2025, expected to be finalized in 2026, would make annual penetration testing explicitly mandatory. SOC 2 (System and Organization Controls 2) includes penetration testing as an expected component of demonstrating the Availability and Security trust service criteria. ISO/IEC 27001:2022 requires penetration testing as part of operational controls under Clause 8.8. CMMC 2.0 (Cybersecurity Maturity Model Certification) Level 2 requires penetration testing under control CA.L2-3.169. FedRAMP requires penetration testing as part of its security assessment and authorization process. NIST SP 800-53 includes CA-8 (Penetration Testing) as a security control. NYDFS 23 NYCRR 500 requires annual penetration testing for covered financial entities.

Does PCI DSS require penetration testing and how often?

PCI DSS (Payment Card Industry Data Security Standard) version 4.0, which became fully effective on March 31, 2024, explicitly requires penetration testing under Requirement 11.4. The standard mandates penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. Requirement 11.4.1 requires the use of a penetration testing methodology that aligns with industry-accepted practices such as PTES or NIST SP 800-115. Requirement 11.4.2 requires external penetration testing by a qualified internal resource or a qualified external third party, and specifies that the tester must be organizationally independent. Requirement 11.4.3 requires internal penetration testing. Requirement 11.4.4 requires that exploitable vulnerabilities and security weaknesses found during penetration testing be corrected, with testing repeated to verify corrections. For service providers, PCI DSS 4.0 Requirement 11.4.7 requires penetration testing of segmentation controls used to isolate the cardholder data environment.

Does HIPAA require penetration testing?

HIPAA does not explicitly use the term “penetration testing,” but the HIPAA Security Rule at 45 CFR 164.308(a)(8) requires covered entities and business associates to perform periodic technical and non-technical evaluations in response to environmental or operational changes. The U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR) has consistently identified penetration testing as the best practice for fulfilling this requirement, particularly in the context of the risk analysis required under 45 CFR 164.308(a)(1)(ii)(A). On January 6, 2025, HHS published a Notice of Proposed Rulemaking (NPRM) that would make annual penetration testing an explicit, mandatory requirement for all covered entities and business associates that create, receive, maintain, or transmit ePHI. The proposed rule attracted significant industry feedback, a regulatory freeze was issued by the Trump administration in early 2025, and the final rule is now expected to be issued in 2026. Organizations subject to HIPAA should not wait for finalization, penetration testing has been an expected best practice for HIPAA compliance for over a decade.

Does HITRUST require penetration testing?

HITRUST (Health Information Trust Alliance), through its HITRUST CSF (Common Security Framework), explicitly requires penetration testing as a component of achieving and maintaining HITRUST certification. The HITRUST CSF, which aligns with HIPAA, NIST, ISO 27001, PCI DSS, and other frameworks, includes penetration testing requirements under Control Category 09.ab (Monitoring System Use) and related vulnerability management controls. HITRUST r2 (Validated Assessment) engagements require organizations to demonstrate that penetration testing has been conducted by qualified resources against systems within the assessment scope. The frequency and scope of required testing vary depending on the organization’s HITRUST implementation level. Because HITRUST CSF certification is widely used in healthcare, health technology, and health information exchange environments as a demonstration of comprehensive security and compliance, penetration testing is a foundational requirement for any organization seeking or maintaining HITRUST status.

Does SOC 2 require penetration testing?

SOC 2 (System and Organization Controls 2), developed by the American Institute of Certified Public Accountants (AICPA), does not include a rigid, prescriptive penetration testing requirement in the way PCI DSS does, but penetration testing is expected and practically necessary to demonstrate the effectiveness of controls under the Security and Availability Trust Service Criteria. Common Criteria CC7.1 requires organizations to use detection and monitoring procedures to identify vulnerabilities, and CC4.1 requires ongoing risk monitoring. SOC 2 auditors, CPAs performing the attestation, consistently expect to see evidence of penetration testing as part of evaluating these criteria. For a SOC 2 Type II report, which covers a defined period (typically 6 to 12 months) rather than a point-in-time snapshot, penetration testing conducted during the audit period is strong evidence of a functioning security program. Most organizations pursuing SOC 2 Type II certification conduct annual penetration testing as a standard practice.

Does ISO 27001 require penetration testing?

ISO/IEC 27001:2022, the international standard for information security management systems (ISMS), includes penetration testing as a specific control requirement. Annex A Control 8.8, “Management of Technical Vulnerabilities,” and Clause 8.8 of the standard’s operational requirements both require organizations to plan, implement, and maintain processes for assessing technical vulnerabilities, with penetration testing being the recognized industry practice for satisfying this requirement. The ISO 27001:2022 transition deadline of October 31, 2025, has now passed: all ISO 27001:2013 certifications have expired, and ISO/IEC 27001:2022 is the only valid version as of November 2025. Organizations certified under the 2022 standard must demonstrate adherence to the updated vulnerability management controls, including penetration testing, during their certification audits. ISO 27001 certification auditors expect to see evidence of penetration testing when reviewing an organization’s vulnerability management program.

Does CMMC require penetration testing?

CMMC (Cybersecurity Maturity Model Certification), the Department of Defense’s (DoD) cybersecurity certification framework for defense contractors handling Controlled Unclassified Information (CUI), requires penetration testing at Level 2 and above. CMMC Level 2 includes 110 security practices derived from NIST SP 800-171, and the penetration testing requirement is captured under practice CA. L2-3.169, which requires organizations to periodically assess the security controls in organizational systems to determine if the controls are effective in their application. The DoD’s interpretation of this control includes penetration testing as the expected technical validation mechanism. Level 3 CMMC, which covers organizations working on the most sensitive DoD programs and aligns with NIST SP 800-172, requires government-led assessments that include penetration testing components.

Does FedRAMP require penetration testing?

FedRAMP (Federal Risk and Authorization Management Program), the U.S. government’s authorization framework for cloud service providers (CSPs) offering services to federal agencies, explicitly requires penetration testing as a condition of achieving and maintaining FedRAMP authorization. Under the FedRAMP Security Assessment Framework, CSPs are required to conduct annual penetration testing of their FedRAMP-authorized cloud environment, and those results must be submitted to their authorizing agency and the FedRAMP Program Management Office (PMO). The penetration testing must be performed by a FedRAMP-recognized Third Party Assessment Organization (3PAO) that is accredited by the American Association for Laboratory Accreditation (A2LA). FedRAMP penetration testing requirements align with NIST SP 800-115 methodology and must cover the full authorization boundary of the cloud service offering. Organizations seeking FedRAMP authorization, or working with CSPs who hold FedRAMP authorization, should understand these testing obligations and timeline requirements.

Does FISMA require penetration testing?

FISMA (Federal Information Security Modernization Act of 2014), the primary cybersecurity law governing federal government information systems, requires federal agencies to conduct periodic assessments of the security controls protecting federal information systems, and penetration testing is a recognized and expected method of conducting those technical assessments. FISMA requirements are implemented through NIST SP 800-53, which includes Control CA-8 (Penetration Testing) as a control applicable to federal systems at all impact levels (Low, Moderate, and High). NIST SP 800-115 provides the technical guidance for conducting FISMA-compliant penetration tests. Federal agencies are required to conduct penetration testing as part of their security assessment and authorization (SA&A) processes, and federal contractors handling federal information systems, including those subject to FedRAMP, inherit penetration testing requirements through their contracts and system authorization obligations. FISMA compliance is overseen by the Office of Management and Budget (OMB) and the Cybersecurity and Infrastructure Security Agency (CISA).

Does StateRAMP require penetration testing?

StateRAMP (State Risk and Authorization Management Program) is the state and local government equivalent of FedRAMP, a framework that helps state governments verify the security of cloud services used by state agencies. StateRAMP explicitly requires penetration testing for cloud service providers (CSPs) seeking StateRAMP authorization, mirroring FedRAMP’s approach. CSPs must conduct annual penetration testing of their StateRAMP-authorized environment, submit the results as part of their StateRAMP authorization package, and maintain ongoing penetration testing as a condition of continued authorization. StateRAMP uses a tiered authorization model (Ready, Provisional, Authorized) and testing requirements scale with the data sensitivity level of the cloud service. As of 2025, more than 30 U.S. states have adopted StateRAMP or are actively evaluating it as a procurement requirement, making StateRAMP compliance increasingly relevant for SaaS and cloud service companies serving government clients.

Does NIST 800-53 or NIST 800-171 require penetration testing?

NIST SP 800-53 (Security and Privacy Controls for Information Systems and Organizations) includes Control CA-8, “Penetration Testing,” which explicitly requires organizations to employ penetration testing on organizational systems or system components. The frequency, scope, and rigor of testing are specified based on the system’s impact level. NIST SP 800-171 (Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations), which applies to contractors handling Controlled Unclassified Information (CUI), includes the requirement under Control 3.12.1 to periodically assess the security controls to determine if the controls are effective, with penetration testing being the accepted technical mechanism for satisfying this requirement. NIST 800-171 is the foundation of CMMC 2.0 Level 2, making penetration testing critical for defense contractors. Both documents are published by the National Institute of Standards and Technology and are freely available at csrc.nist.gov.

Does the SEC cybersecurity disclosure rule require penetration testing?

The SEC (Securities and Exchange Commission) cybersecurity disclosure rules, finalized in August 2023 and fully effective for large accelerated filers as of February 26, 2024, do not explicitly mandate penetration testing by name, but they create strong practical requirements that make penetration testing necessary for compliance. Under Regulation S-K Item 106, public companies must disclose their cybersecurity risk management processes, including how they assess, identify, and manage material cybersecurity risks, and must confirm the qualifications and oversight of personnel involved. Companies that do not conduct penetration testing will struggle to demonstrate a credible, proactive cybersecurity risk management program in their disclosures. The rules also require material cybersecurity incident disclosure within four business days of determining materiality. Penetration testing supports SEC compliance by identifying vulnerabilities before they become incidents and by providing documented evidence of a functioning security risk management program.

Does GDPR require penetration testing?

GDPR (General Data Protection Regulation), which applies to any organization that processes personal data of EU residents, does not explicitly mention penetration testing, but Article 32 of the GDPR requires organizations to implement “appropriate technical and organisational measures” to ensure a level of security appropriate to the risk, including “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.” European Data Protection Authorities and cybersecurity legal practitioners broadly interpret this requirement as mandating penetration testing as the standard mechanism for technical security validation. GDPR violations can result in fines of up to €20 million or 4 percent of global annual revenue, whichever is higher. Organizations that experience a data breach and cannot demonstrate they regularly tested the effectiveness of their security controls face increased regulatory scrutiny and enforcement risk.

Does NYDFS (23 NYCRR 500) require penetration testing?

NYDFS 23 NYCRR 500, the New York Department of Financial Services cybersecurity regulation applicable to financial services companies licensed in New York State, explicitly requires annual penetration testing. Section 500.05 mandates that covered entities conduct annual penetration testing of their information systems based on relevant identified risks, and biannual vulnerability assessments (automated scanning) of those systems. The November 2023 amendments to 23 NYCRR 500, which introduced tiered requirements based on company size, maintained the annual penetration testing requirement for all covered entities except those qualifying as “limited” covered entities based on employee count and revenue thresholds. Covered entities under NYDFS 23 NYCRR 500 include banks, insurance companies, and other financial services firms regulated by the New York Department of Financial Services. Penetration testing results must be retained as part of the covered entity’s documented cybersecurity program.

Does the FTC Safeguards Rule require penetration testing?

The FTC Safeguards Rule (16 C.F.R. Part 314), which took full effect for non-banking financial institutions on June 9, 2023, requires covered financial institutions, including auto dealerships, mortgage companies, payday lenders, tax preparers, and other non-banking financial services firms, to implement a written information security program that includes penetration testing. Specifically, the rule requires annual penetration testing conducted by a qualified professional, or, alternatively, continuous monitoring with vulnerability assessments every six months. The FTC Safeguards Rule applies to financial institutions defined under the Gramm-Leach-Bliley Act (GLBA) that are not subject to the jurisdiction of other federal banking regulators. Non-compliance with the FTC Safeguards Rule can result in FTC enforcement action, civil penalties, and required remediation under a consent order. The FTC has stated that penetration testing is a fundamental expectation for demonstrating a reasonable and appropriate information security program under the Safeguards Rule.

What is the difference between a compliance pen test and a true security pen test?

A compliance penetration test is conducted primarily to satisfy the explicit requirements of a regulatory framework, such as PCI DSS, HIPAA, or SOC 2, and its scope, frequency, and methodology are shaped by what the regulation requires rather than by the organization’s specific threat landscape. A true security penetration test is designed around the organization’s actual risk profile, critical assets, likely threat actors, and security objectives, it goes beyond the minimum required and focuses on finding the vulnerabilities that matter most for the specific organization. In practice, compliance tests often represent the floor of security testing, not the ceiling. A PCI DSS-required penetration test that only tests cardholder data environment systems may satisfy the standard but leave the rest of the organization’s infrastructure unassessed. Organizations that treat compliance testing as their only security testing may have a false sense of assurance, the goal should be to design tests that satisfy compliance requirements while also genuinely addressing security risk.

Can a penetration test satisfy multiple compliance requirements at the same time?

A single penetration test engagement can satisfy multiple compliance requirements simultaneously when the scope, methodology, and documentation are designed to address each framework’s specific mandates. For example, an organization subject to both PCI DSS and SOC 2 can design an engagement that covers the cardholder data environment (satisfying PCI DSS Requirement 11.4), the full production infrastructure and application stack (addressing SOC 2 Common Criteria), and uses a methodology aligned with PTES or NIST SP 800-115 (satisfying the methodology requirements of both frameworks). The penetration test report should map findings and methodology to each relevant compliance requirement. Organizations should confirm with their specific auditors, a QSA for PCI DSS, a CPA firm for SOC 2, what specific evidence they require, since some auditors have expectations about report format, tester qualifications, or scope that may require adjustments.

What documentation do auditors typically require from a penetration test?

Auditors reviewing penetration testing evidence typically require a combination of documentation that confirms the test was conducted properly, covered the required scope, identified vulnerabilities, and that those vulnerabilities were remediated. Standard documentation requirements include the signed scope agreement or statement of work confirming the testing scope and timeline, the full penetration test report including all findings and their severity ratings, evidence of the tester’s qualifications (certifications, firm accreditation), documentation of any critical vulnerabilities found and their remediation status, and retest results confirming that remediation was completed. For PCI DSS specifically, the QSA will review the full report and confirm that the testing methodology aligns with Requirement 11.4.1 standards. For SOC 2, the auditor will review the report as evidence supporting the Security trust service criteria. For FedRAMP, the 3PAO submits the full penetration test report as part of the security assessment package. Organizations should retain penetration test documentation for a minimum of three years, or longer if required by applicable regulations.

Explore Blogs, Webinars and other Resources

Trusted by Reputed Companies

Accreditations and Associations

* Disclaimer: This list of accreditations is held by our team of employees and consultants.

What Our Clients Say

We used databrackets (formerly EHR 2.0) in our small medical practice for our risk analysis assessment to be in compliance with meaningful use. Their response was fast, the final report is detailed but simple and easy to follow. They were always available to answer our questions.

E. Compres

Pulmonary and Sleep Center of the Valley

I never miss the opportunity to learn something new …that’s why I am always registering to all free seminars offered on the web. databrackets (formerly EHR 2.0) happened to be the friendliest, comprehensive and up-to- date source of HIPAA Privacy and Security updates.

Alexandra V.

Community Healthcare Network

Today’s presentation was great! Thank you for sending the slides. My only feedback is that it would be fabulous to have the slides ahead of time so I could print them and take notes on the slides.Thanks for your time and knowledge today!

T.B., PM

Community Health Network

Particularly interesting was the flow chart on Administrative Simplification. I utilize all of the Security subcategories you list under the Security tile and appreciate knowing that I am hitting all of the relevant topics during my employee training.

Jessica B.

JD, CHC

I have re-worked our original risk assessment….We are using databrackets' (formerly EHR 2.0) Meaningful Use Security Risk Analysis Toolkit and it meets our needs. It was easy to use and I believe that it very beneficial to our meeting meaningful use.

Bill Curtis

Neurosurgical Associates Of Texarkana, TX

Information (webinars) presented by databrackets (formerly EHR 2.0) highlights some of today’s most demanding healthcare topics. The webinars help to direct those operating in today’s rapidly changing environment in the right direction.

Candace M.

Privacy and Security Officer, Springhill Medical Center

Our Growing List of Credentials

0 +

Assessments

0 +

Clients

0 +

Assessment Libraries

0 +

Years of Experience

0 +

No. of Staff Trained

0 +

HIPAA

0 +

SOC 2 Readiness

0 +

Pen Testing

0 +

ISO 27001 Certifications

0 +

Dollars Saved in Compliance Penalties