The cyber security landscape continues to evolve. Attackers are constantly finding ways around security best-practices. So, defences that were airtight just a few months ago might now be your biggest vulnerabilities.
That’s why the Payment Card Industry Security Standards Council (PCI SSC) constantly refreshes the Payment Card Industry Data Security Standards (PCI DSS).
As we look ahead to 2026, PCI DSS has introduced several key changes that every organisation accepting card payments should be across. Understanding these requirements will be crucial to maintaining PCI DSS compliance, and your overall security posture, in 2026.
Targeted Risk Analysis (Requirement 11.3.1)
PCI DSS v4 introduces a more intentional approach to risk management. Wherever the PCI council doesn’t mandate how often you must perform certain controls, such as scans or patch reviews, you must now justify your chosen frequency through a targeted risk analysis (TRA). This analysis must follow a consistent methodology and involve the teams responsible for operating and securing the environment. You must then document the outcome in a manner that clearly explains why the chosen approach is suitable and how it aligns with the requirement’s intent. QSAs will expect evidence of the process, not just the final decision. Without a TRA, you’ll have no choice but to adopt an industry-standard approach, which can be more frequent (and costly) than your environment actually needs.
Enhanced Multi-Factor Authentication (MFA) (Requirement 8.4)
A password alone is not enough anymore. MFA is now required for all access into the cardholder data environment (CDE), not just remote access. This includes administrative access and cloud-based management consoles. This change closes a significant access loophole. Achieving compliance requires a full understanding of how users reach the CDE and ensuring MFA is enforced consistently across all pathways. This reflects a significant shift in the cyber threat landscape. Previously, remote access was the easiest pathway to the CDE. Now, through advanced tactics such as credential theft from phishing, it’s just as simple for attackers to get into an internal network. These expanded MFA requirements reflect that reality, enforcing consistent access controls across your entire environment.
Managing Service Provider Responsibilities (Requirement 12.8.5)
The standard now demands greater oversight of third-party payment service providers. Relying solely on a provider’s Attestation of Compliance is no longer sufficient. Under the changes, your organisation must have a formal process for regularly reviewing each provider’s PCI scope, their assigned responsibilities, and their ongoing compliance status. The standard makes your responsibility clear: you’re ultimately responsible for ensuring your service providers remain PCI DSS compliant, and you’re expected to monitor and enforce their ongoing compliance. ****This includes maintaining an agreed approach for addressing any gaps or failures. The change reflects a broader industry trend: outsourcing payments to third-party service providers does not outsource your accountability.
Logging and Alerting Enhancements (Requirement 10)
Under PCI DSS v4.0, your logging obligations are now far more rigorous. It’s no longer enough to simply generate logs across your CDE. You now need to show that those logs are actively reviewed, correlated and acted on through a clearly defined monitoring and escalation process. To meet the detection performance expected under v4.0, you will need automated alerting. And for most environments, that means implementing centralised log management or a Security Information and Event Management. The standard is shifting the focus from collecting logs to using them. In 2026, assessors will be looking for evidence that you can detect and respond to abnormal activity in a timely and consistent way.
Password Security Controls (Requirements 8.3.6–8.3.10)
Password standards have been updated to reflect modern authentication practices. PCI DSS now requires a minimum length of 12 characters for all user accounts and 15 for service providers, along with controls preventing the reuse of recent passwords. To remain compliant, you’ll need to update your password policy, enforce the new requirements in your systems, and verify they’re being followed across the organisation.
Evolving the Use of Compensating Controls (Requirement 1.1)
Compensating controls are still permitted under PCI DSS v4.0, but the expectations around them are now significantly higher. A compensating control is an alternative security measure used when your organisation can’t meet a specific requirement, designed to provide the same level of security the requirement expects. For example, if an old critical system can’t support MFA, you may strictly limit access to it and monitor its access logs every hour. If you plan to rely on a compensating control, you’ll need to provide a clear justification, demonstrate how it meets the underlying security objective, and have it formally approved by your QSA. You’ll also need to review the control annually to confirm it remains appropriate and effective. The standard’s intent is clear: compensating controls must produce real security outcomes. They can no longer function as convenient alternatives to requirements you find difficult to meet.
New Ecommerce Security Requirements (Requirements 6.4.3 and 11.6.1)
PCI DSS v4.0 introduces two e-commerce requirements that fundamentally change how you need to secure your website. This is particularly important if you use iframes to outsource your payment page. While that approach helps reduce PCI scope, it doesn’t remove your exposure. Your own website remains a high-value target, and attackers increasingly focus on these referring pages to inject malicious scripts.
Under v4.0, you must ensure your referring payment pages comply with Requirements 6.4.3 and 11.6.1, even if you never handle cardholder data directly. This aligns with how modern e-skimming attacks work. Threat actors rarely compromise the hosted payment provider. Instead, they inject JavaScript into the merchant’s site and collect payment data before it reaches the legitimate processor.
Requirement 6.4.3 is about visibility and control. You need to know every script running on your site, why it exists, and whether it has been authorised. This includes managing the risk of third-party scripts that silently load additional components. The goal is to eliminate unnecessary code and prevent anything from running in the customer’s browser that you can’t verify.
Requirement 11.6.1 builds on this by expecting real-time detection of unauthorised changes. You must be able to identify when a script is modified, when a new one appears, or when critical elements, such as page headers, change unexpectedly. Doing this reliably generally requires tooling that continuously monitors page integrity and alerts your team the moment tampering occurs.
If you’d like a deeper breakdown of what these requirements mean in practice, read the full analysis here:
Protect Your Organisation from eSkimming: Updated PCI DSS Requirements
No More Cutting Corners: PCI DSS Assessment Planning in 2026
PCI DSS v4.0 raises the bar for assessment readiness. If you’re planning for an assessment in 2026, you’ll need to plan earlier and more intentionally than you might have done in the past. The technical requirements have evolved, but the biggest shift is operational. the PCI SSC now expects clearer scoping, stronger documentation, and greater organisational alignment. That means securing the necessary budget, resourcing, and stakeholder buy-in well before the assessment window opens.
Several areas will demand more attention. Data flow diagrams must be accurate and up to date, reflecting how cardholder data actually moves through your environment. Service provider oversight must be well-documented, with evidence of ongoing review and clarity regarding shared responsibilities. Scoping will also carry more weight. Assessors will expect you to demonstrate how the scope was determined, who was involved, and how it’s maintained throughout the year.
Reporting itself will take longer under v4.0. Requirements such as targeted risk analyses, expanded logging expectations, and new ecommerce controls add complexity that needs to be addressed long before the assessor arrives. Ultimately, the organisations that fare best in 2026 will be those that treat PCI as an ongoing program, not an annual checkpoint.
If you’re unsure how these changes apply to your environment or what level of preparation is required, it’s worth speaking to a specialist. An expert PCI DSS consultant can walk you through the implications of v4.0 and help you build a realistic plan to strengthen your security controls, so you can meet these new requirements for the year ahead. The assessment methodology hasn’t changed dramatically in terms of process, but the expectations around evidence, ownership, and operational maturity have. Being proactive now will save considerable effort later.
If you’d like tailored guidance around PCI DSS v4.0 and preparing for an assessment in 2026, Stratica can help. Stratica is uniquely positioned as both a QSA and a PFI. This dual certification gives us visibility into compliance gaps before they become incidents, and insights into incident patterns that help inform more accurate assessments. To find out more about how partnering with us can streamline your PCI DSS assessments, and stop data breaches before they happen, get in touch with us or book a security review.