Updated: 3 July 2026
What are PCI DSS certification pitfalls? These are the areas where organisations entering a PCI DSS assessment most commonly receive findings (nonconformities) – despite being confident they comply before the audit begins. They typically arise from the gap between the literal wording of a requirement and how a QSA interprets it in practice, or from changes introduced by PCI DSS v4.0.1 (fully mandatory from 31 March 2025). Every finding means a remediation project, a delayed certificate, and additional cost. The following 7 pitfalls are drawn from QSA practice across many assessments.
PCI DSS v4.0.1 – most common PCI DSS certification pitfalls at a glance:
- Organisations assume they do not process cardholder data and are therefore out of scope – while connected-to systems fall within scope without exception
- MFA is required from 31 March 2025 for ALL access to the CDE – not only for remote access
- Authenticated internal scans (11.3.1.2) are mandatory from 31 March 2025 – many organisations still submit unauthenticated scan results
- AOCs and Responsibility Matrices from all in-scope TPSP suppliers must be collected and updated annually (Requirement 12.8)
- The penetration testing methodology must be documented and approved before the test takes place (Requirement 11.4.1 – new in v4.0.1)
- Scripts, iFrames, and tracking codes on e-commerce payment pages must be inventoried and monitored (Requirement 6.4.3)
- Patronusec as a QSA conducts pre-audit gap analysis so clients know the pitfalls before the formal assessment – not during it
Table of Contents
Why does “we don’t store cardholder data” not mean being out of PCI DSS scope?
This is the first and most costly pitfall. A firm convinced that “we don’t store cards, so PCI DSS doesn’t apply to us” may be surprised by the breadth of scope when an assessment begins.
Why non-CHD systems may be in scope:
PCI DSS v4.0.1 identifies three categories of in-scope systems:
- Systems that store, process, or transmit CHD
- Connected-to systems – those with network connectivity to CHD systems or that could affect their security
- Systems providing security services to the CDE
Category 2 (connected-to) is the pitfall. Active Directory servers managing accounts that have access to CHD servers, SIEM systems collecting logs from the CDE, helpdesk platforms with tickets containing information about CDE systems – all of these are connected-to and fall within scope.
How to determine whether a system is connected-to:
- Can this system initiate a network connection to a CHD system?
- Can this system receive a connection from a CHD system?
- If this system were compromised, would an attacker gain access to or information useful for attacking CHD?
If the answer to any of these is “yes” – the system is connected-to.
Patronusec Insight: A scenario that repeats consistently in our projects: a fintech certifying for the first time assumes the scope is 3 application servers. After scope assessment, it turns out that Active Directory, an MDM system managing laptops with CDE access, a network monitoring platform, and the helpdesk are all connected-to. The real scope is 12 to 15 systems. Without a scope assessment, the client would have discovered this during Stage 2 of the audit – the worst possible moment. We conduct PCI DSS scope assessments before pricing the audit.
What are the MFA requirements in PCI DSS v4.0.1 – and when do they apply?
Multi-factor authentication is one of the most significant changes in PCI DSS v4.0.1, mandatory from 31 March 2025.
PCI DSS v4.0.1 Requirement 8.4:
- 8.4.2: MFA is required for ALL access to the CDE – not only remote access. This is a change from v3.2.1, which required MFA only for remote access.
- 8.4.3: MFA is required for all remote access to the network from outside (even where this does not lead directly into the CDE)
Who the MFA requirement applies to:
- IT administrators with access to servers and devices in the CDE
- Developers with access to production CDE environments
- Suppliers and subcontractors with remote access to the organisation’s network or systems
- All users accessing management consoles (AWS Console, Azure Portal, VMware vCenter) in CDE scope
Acceptable MFA methods:
- TOTP apps (Google Authenticator, Microsoft Authenticator, Duo)
- Hardware keys FIDO2/WebAuthn (YubiKey, Titan Key)
- Push notifications (Duo Push, Okta Verify)
- SMS/voice – not recommended and increasingly rejected by QSAs due to SIM-swapping risk
Unsure whether your MFA configuration satisfies Requirement 8.4 of PCI DSS v4.0.1?
Patronusec conducts a technical review of MFA configuration against PCI DSS requirements. Within 5 working days, we deliver a written assessment and recommendations – before a QSA identifies the issue during the formal assessment.
Book an MFA configuration review
Why do unauthenticated scans not satisfy PCI DSS v4.0.1 Requirement 11.3.1.2?
PCI DSS v4.0.1 Requirement 11.3.1.2 (mandatory from 31 March 2025) requires the use of authenticated (credentialed) scans for internal CDE vulnerability scanning.
The difference between authenticated and unauthenticated scans:
An unauthenticated scan connects to a host anonymously – it scans open ports, service banners, and externally visible vulnerabilities. It detects what is visible from outside.
An authenticated scan logs into the system with credentials – it verifies missing patches, operating system configurations, installed software, and vulnerabilities not visible from outside. It typically identifies 3 to 5 times as many vulnerabilities.
Why this matters:
A QSA reviewing a scan report asks: was the scan authenticated? If not – the scan does not satisfy Requirement 11.3.1.2 and is a finding. The organisation must repeat the scans with correct configuration.
How to configure authenticated scans correctly:
- Create a dedicated scanner account with minimum access (read-only is sufficient for most scanners)
- Configure credentials in the scanning platform (Tenable, Qualys, Rapid7)
- Verify that the scanner is successfully authenticating to hosts (the report should confirm successful login)
- Store scanner credentials in line with key management requirements
Patronusec Insight: From our QSA assessments, approximately 70% of organisations that arrive at their first PCI DSS v4.0.1 assessment with scan results have unauthenticated scans – a direct consequence of Requirement 11.3.1.2 being future-dated until 31 March 2025 and many organisations not having updated their procedures. An unauthenticated scan finding delays the audit by 4 to 8 weeks (reconfiguration plus new scans plus re-review). In our vulnerability scanning service, we configure and verify scanner authentication at the start of every engagement.
How do you correctly manage TPSP suppliers under PCI DSS v4.0.1 Requirement 12.8?
TPSP management is one of the requirements with the highest finding rate in PCI DSS assessments – particularly for organisations using cloud services and external IT suppliers.
What PCI DSS v4.0.1 Requirement 12.8 requires:
- 12.8.1: A list of all TPSPs with a description of their services and scope of access to CHD
- 12.8.2: A written agreement with each TPSP containing PCI DSS security requirements
- 12.8.3: A defined due diligence process before engaging a new TPSP
- 12.8.4: Annual monitoring of PCI DSS compliance status of all TPSPs
- 12.8.5: A documented division of PCI DSS control responsibilities between the organisation and each TPSP
Typical findings in TPSP management:
- No TPSP list (or an incomplete one)
- No written agreements containing PCI DSS requirements
- No current AOCs from key suppliers (cloud, payment processor)
- No Responsibility Matrix defining the control division
Why does PCI DSS v4.0.1 Requirement 6.4.3 catch e-commerce merchants off guard?
Requirement 6.4.3 (mandatory from 31 March 2025) covers the management of scripts and code loaded on e-commerce payment pages – including analytics scripts, chat widgets, advertising tags, and iFrames.
What Requirement 6.4.3 requires:
- An inventory of all scripts loaded on payment pages with a business justification for each
- A method to confirm the integrity of each script (for example, Sub-Resource Integrity or a CSP nonce)
- Written authorisation for each script
Why it catches merchants by surprise:
Many e-commerce stores load dozens of third-party scripts on checkout pages – Google Analytics, Meta Pixel, session recording tools, chat support, advertising, cookie consent managers. None of these was previously a “PCI DSS problem.” From v4.0.1, each must be inventoried, justified, and monitored for integrity – because a compromised script can intercept cardholder data (formjacking / Magecart-style attacks).
FAQ – PCI DSS certification pitfalls
Which PCI DSS v4.0.1 changes are mandatory from 31 March 2025?
From 31 March 2025, all previously “future-dated” PCI DSS v4.0.1 requirements became mandatory, including: authenticated internal scans (11.3.1.2), expanded MFA (8.4.2 for all CDE access), e-commerce script management (6.4.3 and 11.6.1), documented penetration testing methodology (11.4.1), and several dozen other new or modified requirements.
What is the difference between a minor and major finding in a PCI DSS assessment?
A minor finding (observation) represents incomplete satisfaction of a requirement with an overall correct direction – it may not block certification but requires a remediation plan. A major finding represents a failure to meet a key requirement – it blocks AOC issuance until remediation is confirmed and a re-review is completed.
Can a PCI DSS certificate be issued with open findings?
Not for major finding categories. A QSA can issue an AOC only after confirming remediation of all requirements. In practice, clients with major findings implement corrections and undergo a re-review of the specific area – not a full re-assessment from the beginning.
How long must evidence be retained for PCI DSS?
PCI DSS requires log retention for 12 months with the most recent 3 months immediately available online (Requirement 10.7). Policy and procedure documents must be retained for their active life plus an appropriate buffer after withdrawal. Audit and penetration test reports: minimum 12 months.
How does Patronusec help organisations avoid PCI DSS certification pitfalls?
We conduct a pre-audit gap analysis that identifies all common pitfalls before the formal assessment. The client receives a prioritised list of areas to address with a remediation schedule – and has 2 to 3 months to close gaps before the QSA begins the formal assessment. After a free initial call, we confirm which pitfalls apply to the specific organisation.
How much does a PCI DSS pre-audit gap analysis with Patronusec cost?
Cost depends on scope and environment complexity. Patronusec provides a fixed-price quotation after a free initial call. The investment in a gap analysis is typically a fraction of the cost of remediating findings discovered during the formal assessment. For clients commissioning gap analysis plus formal assessment plus penetration testing from us, preferential package pricing applies.
PCI DSS certification – free consultation
Patronusec as an accredited QSA has seen hundreds of PCI DSS assessment findings – we know where organisations make mistakes and how to avoid them. A pre-audit gap analysis moves discoveries from the assessment to the preparation phase.
In a free 30-minute consultation we will help you:
- Identify which of the 7 pitfalls most likely applies to your organisation
- Assess whether your environment is ready for PCI DSS v4.0.1 requirements mandatory from 31 March 2025
- Plan a pre-audit gap analysis and remediation schedule before the formal assessment
- Choose an engagement model appropriate to your certification timeline
Free consultation | PCI DSS certification | Gap analysis PCI DSS | Penetration testing | Vulnerability scans ASV
