PCI DSS 4.0 Penetration Testing: What's New and How to Prepare

Key Takeaways

• PCI DSS 4.0's penetration testing rules (Requirement 11.4) became fully mandatory on March 31, 2025. They add stricter paperwork. They widen scope to cover critical systems tied to the cardholder data environment (CDE). They also give multi-tenant service providers a new duty to support customer testing.
• You must now build, write down, and follow your own penetration testing method. It has to cover network-layer and application-layer testing. You must also fix every flaw found, not just the critical and high-risk ones, using a risk-based plan.
• New client-side rules (6.4.3 and 11.6.1) call for full tracking and control of payment page scripts. That is a big jump in scope, aimed at modern threats like Magecart and e-skimming attacks.

The Payment Card Industry Data Security Standard (PCI DSS) just got its biggest update in over a decade. PCI DSS 4.0 came out in March 2022. It has been fully enforced since March 31, 2025. If you store, process, or send cardholder data, penetration testing is one of the areas that changed most.

These are not small tweaks. The bar for proof and rigor is much higher than it was under the old standard.

The stakes are high. Credit card fraud losses in the United States alone are set to top $12.5 billion by the end of 2025. The average data breach cost $4.88 million in 2024, and $9.36 million for U.S. firms.

Payment data played a part in 9% of all breaches in 2024. In retail and e-commerce, 32% of breaches were tied to payment data compromises.

PCI DSS 4.0 aims at threats that older rules missed. Client-side attacks top that list. If you take payment cards, you need to know what changed and how to meet it.

This guide walks through the new PCI DSS 4.0 penetration testing rules. It covers the technical mandates and the practical steps to get compliant and stay that way.

Understanding PCI DSS 4.0: The Compliance Timeline and Context

The Evolution to Version 4.0

PCI DSS 4.0 is the first major rewrite since version 3.2.1. It adds 64 new requirements across three rollout phases. The Payment Card Industry Security Standards Council (PCI SSC) built these updates for a faster-moving threat landscape. Attacks on payment systems have grown far more advanced.

The rollout came in stages. PCI DSS 4.0 took effect on March 31, 2024. At that point you had to start moving off version 3.2.1. But the biggest changes, including the new pen testing rules, stayed "future-dated" best practices until March 31, 2025. On that date, 51 once-optional requirements became mandatory for every assessment.

If your Report on Compliance (ROC) was issued before the March 2025 deadline, assessors often marked these items "Not Applicable". That grace period is over. Every firm seeking PCI DSS compliance must now meet the full penetration testing framework.

Why Penetration Testing Requirements Were Enhanced

The wider penetration testing rules answer real shifts in how attacks work. Server-side defenses still matter. But they no longer stop modern attacks on their own. Criminals now go after the client side.

They target JavaScript and other scripts that run in a shopper's browser during checkout. Magecart attacks show this shift. They inject bad code into payment pages. That code grabs cardholder data straight from the browser, so server-side defenses never fire.

DataDome's 2024 Global Bot Security Report found that 65% of websites are still open to even basic attacks. That gap is exactly why version 4.0 now asks for broader testing.

The new standard is clear that a pen test cannot be a box-ticking drill. Tests must copy real attack paths. That includes attackers who already got in through phishing, stolen logins, or other means.

The New Penetration Testing Framework: Requirement 11.4 Explained

Requirement 11.4.1: Methodology Documentation

The biggest process change in PCI DSS 4.0 is simple. You must define, write down, and follow your own penetration testing methodology. Version 3.2.1 was vague about who owned that method. Now it is yours.

Requirement 11.4.1 spells out what your method must cover:

• An industry-accepted approach, drawn from a recognized framework.
• The whole cardholder data environment (CDE) perimeter, plus all critical systems.
• Application-layer testing that covers, at minimum, the flaws listed in Requirement 6.2.4.
• Network-layer testing across every component that supports network functions.
• A review of threats and flaws seen in the past 12 months.

The PCI SSC points to four frameworks:

• NIST SP 800-115. That is the National Institute of Standards and Technology's Technical Guide to Information Security Testing and Assessment.
• The OWASP Testing Guide.
• The Penetration Testing Execution Standard (PTES).
• The Open Source Security Testing Methodology Manual (OSSTMM).

Any of these four can serve as your base.

Broad scoping matters. Your testers cannot just hit the obvious targets. They must work through every system that could affect the security of cardholder data.

The Requirement 6.2.4 flaws include injection attacks such as SQL, LDAP, and XPath injection. They also cover cross-site scripting (XSS), attacks on crypto, business logic bugs, and broken access controls.

Network-layer work covers operating systems, firewalls, switches, routers, and any other gear that could open a path to cardholder data.

The 12-month threat review keeps your method current. Your testing shifts as the threat landscape shifts, instead of going stale against new attack paths.

Many firms outsource penetration testing. That does not move the method duty to the vendor. Your tester can advise and suggest frameworks. You still own a written method that fits your own setup and risk profile.

Working with experienced cybersecurity advisory services can help you build and record a method that meets these rules.

Requirement 11.4.2 and 11.4.3: Internal and External Testing

PCI DSS 4.0 still calls for both internal and external penetration testing. It is now much clearer on how each one runs and who may run it.

Internal testing (Requirement 11.4.2) must follow your written method. Run it at least once every 12 months. Run it again after any major change to infrastructure or apps.

A qualified in-house person or an outside firm may do the work. The tester must be organizationally independent. They do not have to be a Qualified Security Assessor (QSA) or an Approved Scanning Vendor (ASV).

PCI DSS 4.0 does not name required certs for in-house testers. Assessors judge them on certs, experience, method, and tools. So if you test in-house, be ready to show your testers' skill with records and proof.

External testing (Requirement 11.4.3) mirrors the internal rules. It aims at your internet-facing edge. The standard calls this "testing the exposed external perimeter of trusted networks". It targets systems anyone can reach from public networks.

The split between the two views matters. External tests copy an attacker with no foothold. Internal tests assume someone already got in. You need both views. Real breaches often start with one way in, such as phishing, then pivot inside toward payment systems.

To get the most from your budget, network penetration testing services that pair the outside and inside views give you the fullest picture.

Requirement 11.4.4: Remediation and Retesting

Requirement 11.4.4 changes daily work the most. You must fix every exploitable flaw and weak spot a pen test finds. Then you must test again to prove the fix worked.

That retest step closes an old gap. Firms used to get a report, patch some findings, and never check the result. The retest can focus on the flaws from the first test. You do not have to redo the whole environment.

Version 4.0 also brings a risk-based order of work. Older versions only forced fixes for high-risk and critical flaws found by internal scans. Now you must handle lower-risk flaws too, guided by targeted risk analysis. So you have to weigh and record your risk call on every finding, not just the worst ones.

In practice, medium and low findings can no longer sit for years while only the critical ones get fixed. Either fix them, or write up an analysis showing how you will clear them on a risk-based schedule.

Requirement 11.4.5: Segmentation Testing

Network segmentation is a common way to shrink PCI DSS scope. Wall off the CDE from the rest of your network and fewer systems fall under the standard. That only holds if the segmentation controls really work.

Requirement 11.4.5 calls for penetration testing of segmentation controls at least once every 12 months. Test again after any change to those controls or methods. The test must cover every segmentation control in use. It must prove that out-of-scope systems are truly cut off from the CDE.

PCI DSS 4.0 adds one key point. Tests must now prove isolation of out-of-scope systems and of "systems with differing security levels". Version 3.2.1 never said that outright.

Good segmentation is not just PCI versus non-PCI. It means proper walls between systems of different sensitivity across your whole setup.

If you lean on segmentation to cut scope, a weak test hurts. A failed segmentation test can drag your whole network back into scope. That drives up both cost and effort fast.

Requirement 11.4.6 and 11.4.7: Service Provider Requirements

PCI DSS 4.0 adds new duties aimed at service providers. Those running multi-tenant setups face the most change.

Requirement 11.4.6 applies to service providers only. It calls for biannual proof of logical separation controls through penetration testing. Multi-tenant providers must run these extra tests twice a year to show that tenants stay apart. The higher rate makes sense: one break in logical separation can expose many customers at once.

Requirement 11.4.7 settles an old fight. Many CDEs now sit in third-party cloud infrastructure. Some cloud providers used to block customers and their testers from probing shared systems. PCI DSS 4.0 ends that ambiguity.

Since March 31, 2025, multi-tenant service providers must do one of two things. They can let customers run external pen tests directly. Or they can run the tests and hand customers passing results.

They may redact some sensitive detail to protect their own gear or other tenants. But the right to validate security by testing is now beyond doubt.

So cloud customers may have someone pen test their own assets inside someone else's cloud. If you host payment processing in the cloud, review your service agreements. Make sure your provider is ready to support this rule.

Client-Side Security: Requirements 6.4.3 and 11.6.1

The Rise of Client-Side Attacks

Two of the biggest additions in PCI DSS 4.0 target client-side security. Older versions of the standard barely touched it. Requirements 6.4.3 and 11.6.1 answer a wave of client-side attacks that have exposed millions of payment cards.

Client-side attacks, such as Magecart-style skimming, abuse JavaScript and other scripts that run in a shopper's browser at checkout. They can grab cardholder data before it ever reaches your servers. That bypasses nearly every classic control.

Each third-party script on a payment page widens the target. Modern sites load dozens of them.

Version 4.0 states it plainly: "scripts loaded and executed on the payment page can undergo changes without an entity's knowledge." That is why the new script control and change detection rules exist.

Requirement 6.4.3: Payment Page Script Management

Requirement 6.4.3 covers every script that loads and runs in a shopper's browser on a payment page. You must manage them through a written process. Four things are required:

• Authorize each script before it may run. Confirm that it is needed and that a named person approved it.
• Keep a list of every script on your payment pages, with its name, version, and purpose.
• Write a short reason why each script on the list is needed.
• Use a method to assure the integrity of each script.

A script list tells you exactly what code runs at checkout. It also makes rogue additions easy to spot fast.

The written reason forces a hard look at each script. Marketing tags, analytics tools, and other third-party code can no longer pile up on payment pages unchallenged.

Integrity checks prove a script has not changed since you approved it. That is a key defense against attacks that edit a real script to steal cardholder data.

The hard part is seeing what actually runs. Modern web apps load scripts on the fly. Third-party scripts can pull in fourth-party scripts you never chose.

It helps to work with application penetration testing services that check client-side controls directly.

Requirement 11.6.1: Change and Tamper Detection

Requirement 11.6.1 backs up the script rules with detection and alerts. You must run a change- and tamper-detection tool. It has to check the HTTP headers you receive and the payment page content sent to shoppers' browsers.

The tool must alert your staff when it spots a change no one approved. Alerts must fire at least weekly, or more often if your risk analysis says so. Many firms now use continuous monitoring that flags changes in real time instead of weekly manual checks.

The standard calls out security-impacting HTTP headers by name. Content-Security-Policy is a prime example, since it limits which scripts may run. If an attacker edits that header, they can inject bad code without tripping other controls.

Embedded payment pages need care. Version 4.0.1 clarified that merchants own the scripts on their own web page, the parent page. They do not own scripts inside an iframe that holds a processor's payment page. That falls to the payment processor.

Even so, merchants should still limit and vet what can load in the iframe. Content-Security-Policy headers with the frame-src directive do that job.

Documentation and Evidence Requirements

What Your Assessor Will Expect

PCI DSS 4.0 leans on written proof far more than older versions. For penetration testing, you need a full evidence pack ready for your assessor.

Your written penetration testing methodology must be on hand. It should map to an industry-accepted framework and cover every required test area. You cannot draft it the week before an audit. It has to match what you really do, run after run.

Pen test reports must be kept and ready to review. The standard sets a floor of 12 months. Legal or contract terms may demand longer. Each report should give:

• The scope of the test.
• The method used.
• Every flaw found, described in detail.
• Risk and impact ratings.
• Fix advice.
• Retest results proving the fixes held.

Some assessors ask for the exact date and time each flaw was found and exploited. They may want the same detail for when it was marked resolved after a retest. Build that into your testing and reports from day one. It saves a lot of work at audit time.

Fix evidence must show that every flaw found was handled in your risk-based order. Include the risk call made on each finding and the schedule you applied.

Targeted Risk Analysis

Version 4.0 introduces targeted risk analysis (TRA). A TRA lets you tune certain control frequencies and methods to your own risk picture. For pen testing, a TRA helps set fix timelines for lower-risk flaws. It can also shape how often you test.

A solid TRA names the risks under review. It lists the factors weighed, such as asset criticality, threat likelihood, and potential impact. It states the conclusions and the approach approved on that basis.

If you use a TRA to justify longer fix timelines or a given test approach, be ready to defend it to an assessor.

Some 4.0 rules allow TRA-based frequencies. The cadence of change detection checks under 11.6.1 is one. Finish and record those analyses. Then make sure your monitoring runs on the intervals you set.

Preparing Your Organization for Compliance

Assessing Your Current State

Before you add controls, measure your current penetration testing practice against PCI DSS 4.0. Ask yourself:

• Do you have a written penetration testing methodology that meets Requirement 11.4.1?
• Does your scope cover the full CDE perimeter, all critical systems, and the client-side parts of payment pages?
• Does your fix process handle every finding, not just critical and high, with a recorded risk call?
• Are segmentation controls tested at the new frequency?
• Does your segmentation testing prove isolation of systems with differing security levels?
• If you use the cloud, does your provider support external penetration testing under Requirement 11.4.7?

If you have not built client-side controls for payment pages yet, start by finding out what scripts run at checkout. You cannot manage a risk you cannot see. A full script list is the base for both 6.4.3 and 11.6.1.

Building a Compliant Penetration Testing Program

A PCI DSS 4.0 penetration testing program rests on five parts.

First, write or refresh your method. Starting from scratch? Pick an industry-accepted framework such as NIST SP 800-115 or the OWASP Testing Guide, then tailor it to your setup. Show how it meets each element of 11.4.1, including scoping steps, test techniques, and report standards.

Second, get the scope right. Work with your own teams or your test vendor to map every system that belongs in a pen test. Include the obvious CDE parts. Also include support systems that touch cardholder data security: login systems, network gear, logging and monitoring platforms, and the client-side parts of payment pages.

Third, set up fix and retest steps. Define how findings get triaged, assigned, tracked, and proven fixed. Bake the risk call into that flow so your priorities are recorded and easy to defend.

Fourth, put client-side controls in place. For payment pages, that may mean tools that list scripts, watch for changes, enforce approval, and check integrity. Build it or buy it. Either way, cover both 6.4.3 and 11.6.1 in full.

Fifth, plan your timing. Annual testing is the floor. If your setup changes often, test more. Test after major changes to infrastructure or apps as well. Define what counts as a "significant change" in your world, and make sure it triggers a test.

Selecting a Qualified Testing Partner

If you outsource penetration testing, your choice of partner shapes both your compliance and your security.

The PCI SSC recommends weighing specific penetration testing certifications that prove tester skill. Useful ones include:

• CREST.
• OSCP (Offensive Security Certified Professional).
• OSCE (Offensive Security Certified Expert).
• CISSP (Certified Information Systems Security Professional).
• CEH (Certified Ethical Hacker).
• GSNA (GIAC Systems and Network Auditor).

Certs are only a start. Ask how much PCI DSS work a vendor has done. Ask about years of PCI-specific experience, the types and sizes of setups they have tested, and how well they know the 4.0 changes.

The best testing relationships work like partnerships, not one-off buys. Look for a firm that grasps your business, fits your operating limits, grows with your security maturity, and teaches as it tests. vCISO services can steer your overall testing strategy and tie pen testing into your wider security program.

Common Compliance Pitfalls to Avoid

A few mistakes trip up firms moving to PCI DSS 4.0 penetration testing.

• Treating a pen test as a box to tick. That leads to shallow work that meets the letter of the rule and misses real flaws. Teams that test to improve security get better results.
• Writing the method after the fact. Even a thorough test creates a gap if the method was not written first. Assessors expect a method that predates the test.
• Skipping client-side security. This is the most common gap in the move to 4.0. Requirements 6.4.3 and 11.6.1 are brand new duties, and many firms have not tackled them yet.
• Half-done fixes. Getting a report, patching some findings, and filing it away leaves you exposed. It also breaks the retest rule in 11.4.4.
• Thin records. Keep full records of your method, reports, fixes, and retests for at least 12 months. Keep them longer if your audit cycle or the law calls for it.

The Future of PCI DSS Penetration Testing

Continuous Testing Models

The industry is shifting toward continuous penetration testing instead of one-off snapshots. PCI DSS 4.0 sets annual testing as the floor. Leading teams go further:

• Automated tools running non-stop against external assets.
• Monthly or quarterly manual tests of high-risk parts.
• Full assessments once or twice a year.
• Immediate tests after any major change.

This fits how things really work. Setups change every week and new flaws land every day. Annual testing alone can leave you exposed for months at a time.

AI and Automation in Testing

Artificial intelligence (AI) is showing up in more penetration testing tools and methods. AI-driven discovery can spot complex patterns a human might miss. Automated attack platforms keep watch between manual tests.

Still, human judgment cannot be replaced. Testers bring creative thinking and business context. Requirement 11.4.1 leans on manual skill for that reason. Tools help, but they cannot chain flaws together or catch business logic bugs the way a skilled tester can.

Regulatory Convergence

PCI DSS penetration testing rules increasingly line up with other frameworks. HIPAA is moving toward mandatory annual penetration testing for healthcare organizations. The EU's Digital Operational Resilience Act (DORA), updated SWIFT security rules, and new SEC cybersecurity rules all expect pen testing too.

If several frameworks apply to you, one PCI DSS pen test can often serve more than one of them. Just make sure the scope and method meet each framework's own mandates. Working with compliance-focused cybersecurity advisors helps you map that overlap fast.

Schedule a Consultation

PCI DSS 4.0's penetration testing rules are both a compliance duty and a chance to get safer. Wider scope, more paperwork, and new client-side rules all take real planning.

Do not wait for your next audit to find gaps in your penetration testing program. Contact Essendis today to talk through your PCI DSS 4.0 needs. Our certified team can help you write a compliant method, run thorough tests, and build a program that lasts. The goal is simple: protect your customers' cardholder data and meet the standard.

FAQ: PCI DSS 4.0 Penetration Testing

Q1: What are the key changes to penetration testing in PCI DSS 4.0?

A: The headline change is that you must define, write down, and follow your own penetration testing method (Requirement 11.4.1). That method has to cover industry-accepted approaches. It must scope the full CDE and all critical systems. It must include application-layer and network-layer testing. And it must review threats and flaws from the past 12 months.

The standard also widens your fix duty. You must handle every flaw found through a risk-based approach, not just critical and high-severity findings. New client-side rules (6.4.3 and 11.6.1) call for script control and change detection on payment pages. And Requirement 11.4.7 now makes multi-tenant service providers support their customers' external testing, which settles an old cloud dispute.

Q2: How often must penetration testing be performed under PCI DSS 4.0?

A: At least once a year, and again after any major change to the CDE or related critical systems. If you use network segmentation to cut scope, segmentation controls must also be tested yearly and after any change to segmentation methods.

Service providers face extra rules. Multi-tenant service providers must test twice a year (biannual) to prove logical separation between tenants. You may want to test more often than the floor based on your own risk. Many mature teams test quarterly or run continuous testing.

Q3: What is the difference between internal and external penetration testing under PCI DSS?

A: External testing copies an attack from outside your network. It targets systems and services anyone can reach from the internet, such as your edge defenses, public web apps, and external network services. It answers one question: "What could an attacker with no prior access accomplish from the outside?"

Internal testing copies an attack from inside. It assumes someone already broke through the edge, or that the threat is an insider. It shows how well your internal controls limit damage and block the path to cardholder data. PCI DSS asks for both, because real breaches often start with one way in, such as phishing, and then move sideways to payment systems.

Q4: What qualifications do penetration testers need for PCI DSS compliance?

A: PCI DSS 4.0 does not name required certs. It asks that the work be done by a qualified in-house person or an outside firm, with organizational independence from the systems under test. Assessors judge testers on certs, experience, method, and tools.

The PCI SSC suggests looking for known certs such as CREST, OSCP, OSCE, CISSP, CEH, or GSNA. Real PCI DSS testing work counts just as much. So does a grasp of how payment systems are built. So does the skill to find business logic flaws, not just technical ones. Proven skill beats a badge with no practice behind it.

Q5: What are Requirements 6.4.3 and 11.6.1, and why do they matter for penetration testing?

A: Both cover client-side security for payment pages, which older PCI DSS versions did not spell out. Requirement 6.4.3 says every script on a payment page must be authorized, listed with a written reason, and checked for integrity. Requirement 11.6.1 asks for tools that detect and alert on changes no one approved, both in payment page content and in security-impacting HTTP headers.

They matter because they widen what a pen test has to cover. Testers must now judge whether your controls stop and spot Magecart-style attacks and other client-side threats. A test should prove that your script list process works, that approval controls hold, that integrity checks catch tampering, and that change alerts fire. Teams that skipped these controls have a real compliance gap.

Q6: How should vulnerabilities found during penetration testing be handled?

A: Under Requirement 11.4.4, you must fix every exploitable flaw and weak spot a pen test finds, in line with your own risk assessment. Then you must test again to prove the fix worked. Older versions focused mostly on critical and high-risk findings, so this is a real change.

You must write down a risk-based order of work. Fix critical flaws at once, then set fair timelines for lower-risk items based on targeted risk analysis. The proof step means you cannot just close a finding on paper. A retest has to show the fix held. That retest can focus on the flaws found, not the whole environment.

Q7: Do penetration testing requirements apply if we use a payment processor's hosted payment page?

A: If shoppers get sent fully to a third-party payment processor's own site (not an iframe), Requirements 6.4.3 and 11.6.1 may not apply to you. They become the processor's job. You still own the rest, though, including how you manage that processor and how you track their PCI DSS compliance under Requirement 12.8.

If you embed the processor's page in an iframe on your site, 6.4.3 and 11.6.1 apply to your parent page. The processor still owns the scripts inside its iframe. Best practice is to add Content-Security-Policy headers with frame-src directives to limit what can load there. The core penetration testing rules (11.4.1 through 11.4.5) still apply to your whole CDE, whatever payment method you use.

Q8: What documentation must be maintained for PCI DSS penetration testing compliance?

A: You need a few types of records. First, a written penetration testing method that meets every element of Requirement 11.4.1, including industry-accepted approaches, scoping steps, and risk assessment methods. Second, full pen test reports with scope, method, findings, risk ratings, and fix advice. Keep those reports for at least 12 months.

You also need fix records showing how each finding was handled, plus the risk calls behind your order of work. Retest records must prove each fix held. If you use targeted risk analysis, record the method, the factors weighed, and the conclusions. For client-side security, keep script lists with written reasons, plus records of your change alert setup and the responses to those alerts.

Q9: Can penetration testing disrupt our payment processing operations?

A: Not when it is run by skilled testers under clear rules of engagement. Good firms work closely with your IT team. They test during quiet hours where they can. They avoid anything that could crash a system without written approval.

Black box work, such as scanning, probing, and testing logins, rarely touches normal service. It mirrors what real attackers do every day. Internal and gray box work goes deeper and may add log entries or test data. Even so, professional testers use non-destructive methods and steer clear of production impact without coordination. For mission-critical payment systems, test against a staging setup that mirrors production. That removes the risk and still gives you real security proof.

Q10: How do we know if our penetration testing program meets PCI DSS 4.0 requirements?

A: Measure it against section 11.4 point by point. Check that you have a written method covering industry-accepted approaches, full scoping, application-layer and network-layer testing, and the threat review. Confirm that internal and external tests run at least yearly, plus extra tests after major changes.

Review your fix process. Every finding needs a recorded risk call, not just the critical and high ones, and a retest to prove the fix. If you use segmentation, check that those controls are tested yearly across all isolation methods. For payment pages, confirm that 6.4.3 and 11.6.1 controls are live and that testing proves they work.

If you are unsure, bring in a qualified assessor or compliance advisor for a gap check before your formal PCI DSS audit. Finding gaps early gives you time to fix them, instead of hearing about them during the audit.