PCI DSS guide
PCI DSS common mistakes: the ten that fail assessments, and how to fix each one
The ten mistakes that most often stall a PCI DSS assessment, from forgotten card data stores and untested segmentation to missing targeted risk analyses, with why each happens, how the assessor finds it and the fix.
Key points
- Most failed PCI DSS assessments are not caused by missing technology. They come from ten repeatable mistakes, and every one of them is visible months before the QSA arrives.
- Three mistakes are about the boundary: card data nobody mapped, segmentation nobody tested and a questionnaire chosen for convenience rather than eligibility.
- Five are controls that exist on paper but not in operation: provider evidence, quarterly scans, payment page scripts, shared administrator accounts and logs nobody reads.
- The last two are governance under v4.0.1: targeted risk analyses never written, and a programme that wakes up once a year.
Why PCI DSS assessments fail
A Qualified Security Assessor does not grade effort. For each requirement in scope the assessor looks for a control that is defined, in place and operating for the period the requirement expects. An assessment stalls when one of those is missing, and the same gaps recur whatever the organisation's size or sector. It applies to a ROC and an SAQ alike: an SAQ signed without the controls behind it is a false attestation.
Each mistake below gives why it happens, how it shows when the assessor tests it, and the fix. Where another guide in this series owns the subject, we point to it rather than repeat it.
Mistakes 1 to 3: the boundary is wrong
1. Undocumented data flows and forgotten PAN stores
Why: the data-flow diagram follows the payment system's design, not how people work. Card numbers end up in call recordings, support tickets, spreadsheets, inboxes and old backups nobody thinks of as payment systems.
How it shows: an interview or a discovery query finds full card numbers somewhere the diagram does not show. Everything connected to that store falls into scope, with no evidence behind it.
Fix: trace each payment channel end to end with the people who handle it, run data discovery across file shares, databases and ticketing tools, then purge or protect what you find and keep the purge record.
2. Segmentation that was never tested
Why: a firewall or VLAN was installed to shrink the cardholder data environment, and everyone assumes it works because it was designed to.
How it shows: the assessor asks for the segmentation penetration test. Without one, or with one whose open paths were never closed, segmentation cannot be relied on and the flat network is in scope.
Fix: test every segmentation control at the frequency the standard sets for your entity type, retest after changes to those controls and close what the test finds. The scoping and segmentation guide covers designing the boundary.
3. The wrong SAQ
Why: the shortest questionnaire is picked because it looks least work, without checking its eligibility criteria against the real payment channels.
How it shows: the acquirer notices an e-commerce page, a telephone channel or stored card data that breaks eligibility, and the attestation must be redone on a longer SAQ or a full ROC, often near a contractual deadline.
Fix: confirm the validation type with your acquirer in writing before work starts. The SAQ eligibility guide walks through the choice.
Mistakes 4 to 6: dependencies and tests that lapse
4. Third parties without AOCs or a responsibility matrix
Why: hosting, gateways, contact-centre platforms and managed security providers are assumed compliant because they are large or the contract mentions PCI DSS.
How it shows: expired AOCs, AOCs for a different service, or no written split of who owns which requirement leave controls nobody can evidence.
Fix: register every provider that handles card data or can affect its security, collect current AOCs, agree a responsibility matrix with each and monitor their status at least annually.
5. Missed quarterly scans
Why: Approved Scanning Vendor scans and internal vulnerability scans are treated as assessment-season work; a quarter is skipped or a failing scan never rescanned.
How it shows: the run of passing scans across the period has a gap, or high-risk findings have no passing rescan.
Fix: schedule both scan types for the year on day one, give them an owner, and remediate and rescan until each passes.
6. Payment page script changes left unmanaged
Why: marketing tags, analytics and chat widgets reach checkout pages through teams outside security. The script controls became mandatory on 31 March 2025 and many merchants have not caught up.
How it shows: there is no script inventory, no authorisation or justification per script, no integrity method and no alert when a page is altered.
Fix: inventory every script on the payment page, remove what is not needed, authorise the rest through change control and deploy tamper detection whose alerts someone acts on.
Mistakes 7 and 8: who did what cannot be shown
7. Shared or generic administrator accounts
Why: one "admin" login is convenient for a small team, a vendor's support staff or a legacy system nobody wants to touch.
How it shows: sampled privileged accounts cannot be tied to one person, access into the CDE lacks multi-factor authentication, or leavers remain active. Individual accountability, on which logging depends, is lost.
Fix: issue unique IDs, justify and tightly control any account that must stay shared, enforce MFA on all non-console access into the CDE and record the decisions of six-monthly access reviews.
8. Logs collected but never reviewed
Why: a logging platform goes live, events flow in and the project closes. Nobody is given the job of reading the alerts.
How it shows: the assessor picks dates and asks for review evidence, then asks what happened after a real alert.
Fix: automate the review, name a reviewer and a deputy, ticket every alert that needs action and monitor for failures of critical security controls, logging included.
Mistakes 9 and 10: governance treated as paperwork
9. Targeted risk analyses missing where v4.x expects them
Why: version 4 lets an entity set its own frequency for several periodic activities, but only with a documented targeted risk analysis behind it. Teams set the frequency and forget the analysis.
How it shows: the assessor asks for the analysis behind each self-set frequency and its annual review; without it the requirement is not met, even though the activity runs.
Fix: list every in-scope requirement that relies on one, write each analysis with the asset, threat, chosen frequency and reasoning, approve it and review it yearly. Meeting a requirement another way is a separate subject, covered in the compensating controls and customised approach guide.
10. Treating compliance as an annual event
Why: the organisation mobilises for the assessment, receives the AOC and stands the team down.
How it shows: next year's assessment finds lapsed quarterly and six-monthly tasks, changes that moved the scope unnoticed and no annual scope confirmation. A year of evidence cannot be recreated afterwards.
Fix: run a compliance calendar with an owner for every periodic task, assess each change for its effect on scope and review progress quarterly at management level. The annual cycle guide sets out that rhythm.
The ten mistakes at a glance
| Mistake | What the assessor finds | The fix |
|---|---|---|
| 1. Unmapped data flows | Card numbers outside the documented CDE | Channel tracing, data discovery, purge records |
| 2. Untested segmentation | No test, or open paths never closed | Regular segmentation tests, retest after change |
| 3. Wrong SAQ | Eligibility broken by real channels | Acquirer confirmation in writing |
| 4. Unmanaged third parties | Missing AOCs, no responsibility matrix | Provider register, annual monitoring |
| 5. Missed scans | Gaps, or no passing rescan | Scheduled scans with an owner |
| 6. Unmanaged page scripts | No inventory or tamper detection | Inventory, change control, alerting |
| 7. Shared admin accounts | Actions not traceable, MFA gaps | Unique IDs, MFA, access reviews |
| 8. Unread logs | No review evidence or follow-up | Automated review, named reviewers |
| 9. Missing risk analyses | Self-set frequencies unjustified | Approved analyses, reviewed yearly |
| 10. Annual-event compliance | Lapsed tasks, drifted scope | Compliance calendar, quarterly oversight |
An internal assessment a few weeks before fieldwork catches all ten if it samples as an assessor will. For what the assessor tests on the day, see the PCI DSS assessment guide.
How Sterling prevents these failures
All ten are checked in the gap analysis and again before fieldwork.
Sterling's PCI DSS engagements begin with scope, validation type and data discovery, so the boundary mistakes are settled before remediation. With Design™ your team does the work with Sterling's structure, templates and coaching; with Drive™ Sterling consultants take on the agreed remediation with your system owners. On either level of support, periodic tasks, provider AOCs, risk analyses and scan reports are tracked in Effivity, included with the engagement at no additional cost, and an internal assessment tests the evidence before the assessor sees it. We ensure successful validation for our clients. The QSA assesses, or your acquirer accepts the SAQ; Sterling does not validate compliance.
Book a free discovery callPCI DSS common mistakes: questions buyers ask
Which mistake is the most expensive to fix late?
An undocumented store of card data. It can pull many systems into scope at once, each needing hardening, logging, access control and evidence. Found early, it costs a purge; found during fieldwork, it can cost the assessment date.
Can a failed requirement be fixed during the assessment?
A documentation gap sometimes can. A control that must operate over time, such as quarterly scans or daily log review, cannot be backdated, so those gaps usually delay the AOC until enough operating evidence exists.
Do these mistakes matter if we only complete an SAQ?
Yes. An executive signs the SAQ as a statement that each applicable requirement is in place. These mistakes make that statement untrue, and the acquirer or a later breach investigation can test it.
Our payment provider says it is PCI compliant. Is that enough?
Not on its own. You need its current AOC for the service you use and a clear split of what it manages and what stays with you. Outsourcing reduces your responsibilities; it rarely removes them.
How often should we check ourselves against this list?
Track the periodic items monthly through the compliance calendar, and run a fuller internal assessment against all ten at least once between validations and again before fieldwork.
More PCI DSS guides
Every guide in the PCI DSS series is written for one question and links back to the hub for the whole picture.
- PCI DSS for call centres and BPOs
- PCI DSS checklist
- Choosing a QSA
- PCI DSS compensating controls and the customised approach
- PCI DSS compliance cost: what moves the price
- Do you need PCI DSS
- PCI DSS vs ISO/IEC 27001 and SOC 2
- PCI DSS requirements explained, requirement by requirement
- PCI DSS scoping and segmentation: shrinking the CDE
- PCI DSS v4.0.1: what changed and what your next assessment tests
- PCI DSS validation step by step: ROC, SAQ and AOC
- Which SAQ applies to you: eligibility explained
Keep exploring
Explore more about PCI DSS
Watch a video on how to implement PCI DSS here.
Watch a video on PCI DSS requirements here.
PCI DSS resources
Services for PCI DSS
Talk to a consultant
Find these ten mistakes before your assessor does.
Tell us your goals, locations and target date. We’ll help you define the scope, timeline and next steps.
hello@sterling-grc.com+1 201 263 4443 (global headquarters) · your nearest office and its number are at the top of this page
What would you like to achieve?
Choose a starting point. The enquiry form takes about a minute.
Book my free discovery callContinue to the enquiry form to share your details. Please do not include passwords, sensitive personal information or confidential files. A Sterling consultant replies within one working day. Privacy notice