Common PCI Audit Failures: 12 Findings and How to Avoid Them

Most PCI audit failures come down to evidence, not technology: the control existed, but the organisation cannot show that it operated across the whole assessment period. The other big causes are an incomplete scope and the v4.0.1 requirements that became mandatory on 31 March 2025, such as MFA for all non-console access into the cardholder data environment, authenticated internal scanning, targeted risk analyses and payment page script controls. Every one of them can be avoided if you find it early.

This article sets out the PCI compliance failures that come up again and again in assessments, why each one fails, and what to do about it before your assessor arrives.

Key takeaways

• Most failures are evidence failures: the control existed, but there is no record that it ran.
• An incorrect scope undermines everything else, so confirm it formally every year.
• Several requirements that became mandatory in March 2025 are now frequent findings.
• Responsibilities shared with service providers must be documented, not assumed.
• A gap analysis months before fieldwork is the cheapest way to find problems in time.

What are the most common PCI audit failures?

These twelve come up again and again in PCI DSS v4.0.1 assessments, across merchants and service providers alike. The table gives the requirement behind each one and the fix; the sections below explain why they fail.

How does an assessor decide a requirement has failed?

Each requirement is marked in place, not in place, not applicable or not tested. There are no “minor” findings that can be waved through. If a requirement is not in place and there is no valid compensating control, the Report on Compliance cannot conclude that you are compliant. Our guide to PCI DSS compensating controls explains when one is valid.

Assessors also look for evidence across the period, not just on the day. A firewall rule review done once, the week before the audit, does not show that reviews happen every six months as Requirement 1.2.7 expects.

Why do scoping failures sink so many audits?

Because every other finding depends on scope. Requirement 12.5.2 asks you to document and confirm scope at least every 12 months and after significant change, but many organisations start the assessment with a data flow diagram that no longer reflects reality. A new payment integration, a cloud migration or a new call recording platform has quietly expanded the cardholder data environment (CDE).

Connected systems are the other trap. Jump hosts, Active Directory, logging servers and patch management tools are in scope even if they never touch card data. And if you cannot show you have searched for stray card data, and removed or secured what you found, your scope is not credible. Our PCI DSS scoping guide covers how to define and reduce scope properly, and our free PCI compliance check gives a quick first view of where you stand.

Which technical controls fail most often?

• Network security controls. Rules allowing “any” source or destination that were meant to be temporary, and diagrams that do not match the configuration. A firewall configuration review shows whether your Requirement 1 evidence will stand up.
• MFA. Since March 2025, 8.4.2 covers all non-console access into the CDE. Application administrators, database users and support staff still logging in with a password alone are a regular finding. Requirement 8.5.1 also sets how MFA must be configured, including resistance to replay attacks.
• Vulnerability management. A missed quarter cannot be recovered afterwards. Lower-risk vulnerabilities must also be addressed on a timeline set by your targeted risk analysis (11.3.1.1), not ignored.
• Penetration testing. Tests that miss part of the CDE boundary, skip the application layer or lack a documented methodology. PCI DSS penetration testing should be scoped to the whole of Requirement 11.4, including segmentation.
• Logging and anti-phishing. Automated audit log review (10.4.1.1) and controls to detect and protect staff against phishing (5.4.1) are relatively new and often only partly implemented.

Which v4.0.1 requirements are catching organisations out?

The requirements that became mandatory on 31 March 2025 are now assessed like any other, and several have become frequent findings. The ones to check first are targeted risk analyses (12.3.1), MFA for all non-console access into the CDE (8.4.2), authenticated internal scanning (11.3.1.2), automated log review (10.4.1.1), and payment page scripts (6.4.3 and 11.6.1). Check too the documented roles and responsibilities that v4.0 added at the start of each requirement (1.1.2, 2.1.2 and so on); these applied as soon as v4.0 replaced v3.2.1, and assessors still find them missing. Our PCI DSS 4.0.1 changes guide lists them all.

What governance failures do assessors find?

• Policies that do not match reality. Generic templates describing processes nobody follows are easy to spot. If nobody can say who owns quarterly access reviews, that is a finding.
• Untested incident response. Requirement 12.10.2 requires a review and test at least every 12 months. A tabletop exercise is acceptable if it is recorded and its actions tracked.
• Assumed provider coverage. Requirement 12.8 needs a list of service providers, written agreements, annual monitoring of their compliance status and a record of which requirements each manages (12.8.5). Assuming a compliant cloud or payment provider “covers” you is a common and avoidable failure.
• Training gaps. Requirement 12.6 expects awareness training that covers phishing and social engineering, with completion records for everyone in scope.

What happens if you fail a PCI audit?

The assessor does not impose penalties; your acquirer and the card brands do. You cannot claim compliance while any requirement is not in place, and your acquirer may ask for a remediation plan with dates. Continued non-compliance can lead to monthly non-compliance fees, higher transaction charges and, in serious cases, withdrawal of card acceptance. Our guide to PCI compliance cost explains how non-compliance fees work and how to stop paying them.

Do SAQ merchants fail for the same reasons?

Mostly, yes. Unless a QSA validates it, nobody tests a Self-Assessment Questionnaire before you sign it, so the same gaps surface later: when your acquirer queries the SAQ, or when a forensic investigator compares what you signed with what was in place after a breach. Out-of-date scope, missing provider AOCs, unjustified “Not Applicable” answers and missed quarterly scans are the usual culprits. Our guide on how to fill out a PCI SAQ covers the eight mistakes we see most.

How do you avoid failing your next PCI audit?

1. Confirm scope. Update data flow diagrams, the inventory and the list of connected systems, and run a card data discovery exercise.
2. Run a gap analysis. Compare controls and evidence with every applicable requirement, ideally with someone independent of the team that runs them. Our guide to a PCI DSS gap analysis explains how.
3. Fix what needs a track record first. Scans, reviews and log monitoring cannot be put right in the final week.
4. Collect evidence as you go, in a shared library organised by requirement, with owners and dates.
5. Brief the people who will be interviewed. Assessors speak to administrators, developers and managers, not just the compliance lead.

Our guide on how to prepare for a PCI DSS audit turns these into a timed plan, and our PCI DSS compliance roadmap comes with a free template that gives every task an owner and a deadline.

Getting help

The earlier you find these gaps, the cheaper they are to fix. Sovereign Secure is a PCI SSC-approved Qualified Security Assessor company. A PCI DSS consultant from our team can run your pre-audit review, our vulnerability scanning services cover quarterly internal scans and ASV scans through an approved partner, and we carry out the formal PCI compliance audit itself.