Common PCI Compliance Mistakes

Why Compliance Mistakes Are So Common

PCI DSS isn't a simple standard. With 12 requirements, hundreds of specific controls, and the need for continuous vigilance, it's not surprising that businesses make mistakes. What is surprising is how often the same mistakes come up — year after year, audit after audit, across organisations of all sizes and industries.

The good news is that if you know what the common pitfalls are, you can avoid them. In this guide, we'll walk through nine of the most frequent PCI compliance mistakes that auditors and QSAs encounter, and more importantly, we'll explain how to fix each one. If you've been following this series from Guide 1, you'll recognise some themes — but seeing them framed as concrete mistakes makes the lessons much more actionable.

Mistake 1: Treating Compliance as an Annual Checkbox

This is the single most common mistake, and PCI DSS v4.0.1 has made it even riskier. Many businesses treat PCI compliance like an annual tax return — scramble to get everything in order before the assessment, pass, and then let things slide until next year. During the intervening months, patches go unapplied, access reviews are skipped, logs go unmonitored, and security policies gather dust.

PCI DSS has always been intended as a continuous standard. V4 makes this explicit, with multiple requirements stating that controls must be in place and operating "at all times." If your security posture only meets the standard for the two weeks around your annual assessment, you're not compliant — and you're exposed to real risk for the other 50 weeks of the year.

How to fix it: Build PCI controls into your regular operations. Schedule monthly or quarterly internal checks. Automate where possible — automated patch management, automated log alerting, automated access reviews. Make compliance part of how you operate, not something you do once a year.

Mistake 2: Storing Card Data Unnecessarily

You'd be amazed how many businesses store cardholder data without a genuine business reason. Credit card numbers in spreadsheets. PANs in CRM notes. Card details in email threads. Full card numbers in paper forms filed in cabinets. Call recordings containing spoken card numbers and CVVs.

PCI DSS Requirement 3 is clear: only store cardholder data if there's a documented business justification, keep it for the minimum period necessary, and purge it on schedule. Sensitive authentication data — CVV codes, PINs, full track data — must never be stored after authorisation, under any circumstances.

How to fix it: Conduct a thorough data discovery exercise. Search your systems — databases, file shares, emails, CRM platforms, paper files, call recordings — for cardholder data. You'll almost certainly find it in places you didn't expect. Delete what you don't need. Encrypt what you must keep. And implement controls to prevent new unnecessary storage from creeping in. For telephone payments, DTMF masking technology like Paytia's prevents card data from entering your systems in the first place.

Mistake 3: Not Knowing Your Full Scope

Scope creep is insidious. Many businesses assess their PCI scope once and never revisit it, even as their technology and processes change. A new CRM system that captures payment details. A new VoIP phone system that carries calls where card numbers are spoken. A new remote working arrangement where agents take payments from home. A new integration between your payment system and your analytics platform. Each of these can expand your PCI scope without anyone realising.

If your scope assessment doesn't reflect reality, your compliance programme has a blind spot. You might have systems handling card data that aren't secured to PCI standards, simply because nobody knew they were in scope.

How to fix it: Review your PCI scope at least annually and after any significant change to your technology, processes, or business model. Trace the complete lifecycle of cardholder data through your organisation — where it enters, where it flows, where it's stored, and where it exits. Document every system, person, and process that touches it. The scoping exercise in Guide 10 provides a structured approach to this.

Mistake 4: Weak Password and Access Controls

Despite years of security awareness campaigns, weak access controls remain stubbornly common. Shared accounts ("everyone uses the admin login"). Default passwords left unchanged on network devices. Excessive access privileges ("just give everyone admin access, it's easier"). No multi-factor authentication on systems within the cardholder data environment. Former employees whose accounts are still active months after they left.

PCI DSS Requirements 7 and 8 cover this in detail, and v4.0.1 raised the bar further — as we covered in Guide 8. Minimum 12-character passwords, MFA for all CDE access (not just remote), unique IDs for every user, and 90-day maximum for deactivating unused accounts.

How to fix it: Implement a formal access control policy based on least privilege — people only get access to what they need for their role. Deploy MFA on all systems in the cardholder data environment. Use a password manager to enforce strong, unique passwords. Set up automated alerts for dormant accounts. Review access rights quarterly and immediately when someone changes role or leaves.

Mistake 5: Ignoring Call Recordings Containing Card Data

This one is specific to businesses that take payments over the phone, and it's remarkably widespread. Contact centres record calls for quality assurance, training, dispute resolution, and sometimes regulatory compliance. But if those recordings capture customers reading out card numbers — and especially CVV codes — they become a PCI compliance liability.

Many businesses don't even realise this is a problem until an auditor asks about call recordings. Suddenly, they're sitting on thousands of hours of audio containing cardholder data, stored on systems with no PCI controls, accessible to staff with no need to hear that data, and retained for far longer than necessary.

How to fix it: The best solution is to prevent card data from entering recordings in the first place. DTMF masking ensures card numbers are never spoken aloud during calls — customers enter them on their keypad, and only flat tones are recorded. If you're currently using pause and resume, check that it's working reliably (audit a sample of recordings to verify card data isn't slipping through). If you have historical recordings containing card data, develop a remediation plan — you may need to redact or delete them, depending on your retention obligations.

Mistake 6: Incomplete Vendor Management

Your PCI compliance doesn't exist in isolation. If you use third-party providers that handle, store, or could impact the security of cardholder data — payment processors, hosting providers, telephone payment solutions, IT support companies — they're part of your PCI story. Requirement 12.8 requires you to maintain a programme for managing these relationships.

The common mistake is not maintaining a complete inventory of these providers, not verifying their PCI compliance status, and not having written agreements that define security responsibilities. "We assumed they were compliant" is something auditors hear frequently, and it's not an adequate answer.

How to fix it: Create and maintain an inventory of every third-party provider that handles or could affect the security of cardholder data. For each provider, obtain evidence of their PCI compliance (an Attestation of Compliance or AoC). Ensure you have written agreements specifying each party's security responsibilities. Review this inventory at least annually and whenever you add a new provider.

Mistake 7: No Incident Response Plan

Requirement 12.10 requires a documented incident response plan that covers how you'll detect, respond to, contain, and recover from a security breach. Many businesses either don't have one at all, or have a generic template that nobody has read and that hasn't been tested.

When a breach happens — and it's a matter of "when," not "if," for most organisations — the first hours are critical. Without a tested plan, the response is chaotic. Evidence is destroyed. Notification deadlines are missed. The breach expands because containment is delayed. What could have been a manageable incident becomes a crisis.

How to fix it: Write a specific, practical incident response plan that includes: who to contact (internal teams, acquiring bank, law enforcement, QSA), how to contain a breach, how to preserve evidence, notification procedures and timelines, and recovery steps. Then test it. PCI DSS requires at least annual testing — a tabletop exercise where you walk through a realistic breach scenario is a good start. Make sure everyone named in the plan knows their role.

Mistake 8: Not Patching Systems Promptly

Unpatched systems are one of the most common entry points for attackers. PCI DSS Requirement 6.3.3 requires that critical security patches be installed within one month of release. Yet many organisations have patching processes that are ad hoc or delayed by concerns about system stability.

How to fix it: Implement a formal patch management process. Subscribe to vendor security bulletins for all software and hardware in your CDE. Critical patches should be fast-tracked with a clear target of less than 30 days. Automate patching where practical, and track compliance with your patching schedule.

Mistake 9: Assuming Cloud Equals Compliant

Cloud providers like AWS and Azure are PCI DSS compliant for their infrastructure. But under the shared responsibility model, you're responsible for everything you deploy on that infrastructure: your configurations, your access controls, your encryption, your applications, your data.

How to fix it: Understand the shared responsibility model for your cloud provider. Validate that your cloud configurations meet PCI requirements on your side. Use the provider's security tools to continuously monitor your configuration, and include your cloud environment in your regular PCI scope assessments.

In our final guide, Guide 10: Your PCI Compliance Roadmap, we'll bring everything together into a practical, step-by-step action plan.

Key Takeaways

• Treating compliance as an annual checkbox is the most common and most dangerous mistake — PCI DSS v4 explicitly requires continuous, year-round compliance
• Unnecessary card data storage lurks in unexpected places — CRM notes, emails, spreadsheets, and especially call recordings
• Scope creep is real — review your PCI scope annually and after every significant change to your technology or processes
• Access control failures — shared accounts, weak passwords, excessive privileges, and orphaned accounts — remain stubbornly common
• Call recordings containing card data are a compliance liability that many businesses don't discover until audit time — DTMF masking prevents the problem entirely
• Vendor management requires a complete inventory, evidence of compliance, and written agreements for every provider that touches card data
• An untested incident response plan is almost as bad as no plan at all — test it annually with realistic scenarios
• Patching delays create real exposure windows that attackers actively exploit — critical patches need to be applied within 30 days
• Cloud doesn't equal compliant — you're responsible for everything above the infrastructure layer under the shared responsibility model