PCI DSS 4.0
Req 11: Test Security Regularly

PCI DSS 4.0 11.4.1: 11.4.1 Penetration testing methodology defined and implemented

The entity must define, document and implement a penetration testing methodology that includes: industry-accepted testing approaches; coverage of critical systems and of the entire CDE perimeter; tests run from both outside and inside the network; tests validating any scope-reduction and segmentation controls; tests at the application layer that find at least the vulnerability types listed under Requirement 6.2.4; tests at the network layer covering every component supporting network functions plus operating systems; a review of the threats and vulnerabilities the entity met over the past 12 months; a documented approach for assessing and addressing risk from exploitable vulnerabilities and weaknesses the testing finds; and keeping the results of testing and of remediation for a minimum of 12 months. Applicability: internal testing means testing within the CDE and into it from trusted and untrusted internal networks; external testing means testing the exposed outer edge of trusted networks, and of critical systems that are reachable from or connected to public network infrastructure. Objective under the customized approach: a formal methodology exists for thorough technical testing in which a competent manual attacker tries to exploit vulnerabilities and weaknesses through simulated attacks.

Maintained by Gerard BlokdykControl text last updated

What else in your programme already covers this

This control maps to 54 controls across 22 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.

CFTC System Safeguards (17 CFR 37, 38, 39, 49) · 6 controls

ISO 27001:2022 · 5 controls

  • 5.35 Independent review of information security
  • 5.37 Documented operating procedures
  • 8.29 Security testing in development and acceptance
  • 8.34 Protection of information systems during audit testing 
  • 8.8 Management of technical vulnerabilities

ISO 27002:2022 · 5 controls

  • 5.35 Independent review of information security
  • 5.37 Documented operating procedures
  • 8.29 Security testing in development and acceptance
  • 8.34 Protection of information systems during audit testing
  • 8.8 Management of technical vulnerabilities

NIST SP 800-53 Rev 5 · 5 controls

HIPAA Security Rule · 4 controls

NIST SP 800-66 Rev 2 · 4 controls

FedRAMP High · 3 controls

  • CA-8 Penetration Testing
  • CA-8(1) Penetration Testing | Independent Penetration Testing Agent or Team (CA-8(1))
  • CA-8(2) Penetration Testing | Red Team Exercises (CA-8(2))

FedRAMP Moderate · 3 controls

  • CA-8 Penetration Testing
  • CA-8(1) Penetration Testing | Independent Penetration Testing Agent or Team (CA-8(1))
  • CA-8(2) Penetration Testing | Red Team Exercises (CA-8(2))

PTES · 3 controls

  • PTES-1.1 Define and record the scope in writing before testing
  • PTES-1.2 Record the goals and the metrics used to grade risk
  • PTES-3.2 Require a consistent, repeatable threat model tied to the organisation's assets

APRA CPS 234 · 2 controls

  • CPS234-P30 Independence and Skill of Testing Personnel
  • CPS234-P33 Skill of Personnel Providing Control Assurance

CIS Controls v8 · 2 controls

  • CIS-16.13 Conduct Application Penetration Testing
  • CIS-18.1 Establish and Maintain a Penetration Testing Program

NIST SP 800-53A Rev. 5 · 2 controls

  • 53A-3.2.3.2 Depth and Coverage Considerations in Tailoring
  • 53A-D Penetration Testing

AWS Well-Architected Security Pillar · 1 control

Australia Consumer Data Right - Banking (CDR) · 1 control

  • AUCDR-IS-STEP4 Step 4 - Implement a formal controls assessment program

Azure Security Benchmark · 1 control

C5 (Germany) · 1 control

  • C5-OPS-19 Managing Vulnerabilities, Malfunctions and Errors - Penetration Tests

CMMC 2.0 · 1 control

Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1 · 1 control

ISO 27701:2019 · 1 control

  • 6.15.2 Information security reviews

NIST Cybersecurity Framework 2.0 · 1 control

NIST SP 800-172 · 1 control

  • 3.12.1e Penetration Testing by Independent Agents

NIST SP 800-218 · 1 control

Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.

Other controls in Req 11: Test Security Regularly

You are reading one control. How much of PCI DSS 4.0 have you already done?

PCI DSS 4.0 11.4.1 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of PCI DSS 4.0 your existing evidence covers. Hold ISO 27001:2022 and 139 of 280 PCI DSS 4.0 controls already carry evidence.

If you hold ISO 27001:202249.6% covered · 141 gapsIf you hold FedRAMP Moderate49.3% covered · 142 gapsIf you hold NIST SP 800-53 Rev 547.5% covered · 147 gapsIf you hold ISO 27002:202243.2% covered · 159 gapsIf you hold CIS Controls v838.2% covered · 173 gapsIf you hold Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.136.4% covered · 178 gaps

Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 415 were rejected on the ISO 27001:2022 pair alone.

See the released pairs, $299 eachBrowse the graph free

Query this from an agent

The graph holds this control, the 54 it maps to, and the evidence behind each claim, over MCP and REST.

MCP endpointAll PCI DSS 4.0 controls