7 Common Mistakes to Avoid During Your First PCI Audit

Drawing on decades of experience in PCI auditing, SecurityMetrics VP, Gary Glover, and Audit Director, Matt Halbleib, share the seven most common pitfalls organizations encounter, and how to navigate them successfully.

PCI Audit
Auditor Tips
7 Common Mistakes to Avoid During Your First PCI Audit

Starting your first PCI DSS audit can feel overwhelming. Many organizations, especially those transitioning from an SAQ (Self-Assessment Questionnaire) to a full Report on Compliance (RoC), underestimate the required effort and scope.

Drawing on decades of experience in PCI auditing, SecurityMetrics VP, Gary Glover, and Audit Director, Matt Halbleib, share the seven most common pitfalls organizations encounter, and how to navigate them successfully.

Scoping Your Environment Incorrectly

The single biggest factor that trips up those new to PCI audits is adequately scoping. 

Your Cardholder Data Environment (CDE) is not just your Point of Sale (POS) system or ecommerce server; it includes people, processes, and technology that store, process, or transmit cardholder data, or that could affect the security of systems that do.

“The most important part of a first PCI audit is understanding and not underestimating your scope,” says Glover. PCI assessors will systematically trace all inflows and outflows of your card data, which can reveal forgotten or secondary systems.

He goes on to say, “Sometimes people overlook or forget about big systems; say a call center that sometimes receives card data coming in through phones. This means that there is a secondary system of your phone process, and then imagine you’re also doing call recordings. People don’t always realize this is part of their cardholder scope, and it can really impact a first-time audit in terms of cost and time spent.” 

This can be remediated through thorough segmentation, which would involve network segmentation that’s enforced by firewall rules and logic to strictly limit inbound and outbound traffic to only what is necessary. 

Pro Tip: Scan For Card Data– SecurityMetrics PANscan can identify unencrypted payment data at your business, so you can get PCI compliant.

Procrastinating Documentation and Policies 

It’s easy for organizations to think, "We all know what we're doing, we don't need to write it down." However, excellent documentation is a non-negotiable requirement of PCI DSS and an important factor in passing your assessment. It’s important to understand the difference between policy versus procedure. 

Policies dictate what should be done, while procedures detail how it is accomplished.

Without documentation, it is easy to deviate from secure practices, and communicating security standards to new employees becomes difficult. Your auditor must prove that you have written policies in place covering all applicable PCI requirements.

Treating PCI as a Once-a-Year "Checkbox" Event

Many first-timers view the audit as a once-a-year obligation, ignoring compliance for the next 11 months. PCI compliance should be a continuous process that informs year-round security improvements. 

Remember, to meet PCI compliance, you must show evidence. You can’t just say you did the required tasks; you must provide documentation (logs, reports, change tickets, etc.) as evidence. This includes demonstrating your controls are maintained year-round, because your "assessor has to have something they can cite in their report that shows that you actually did it” says Halbleib. 

This is easier to do with the right mindset. Gary suggests that you look at “little ways to improve instead of thinking of PCI as a box that you have to tick.”

Failing to Manage Third-Party Service Providers (TPSPs)

When you outsource a service that touches your CDE (ecommerce hosting, firewalls, data center, etc.), you are still on the hook for its security. Glover explains that “you are responsible for what your third-party providers are doing, and you need to make sure that you understand that and don't just necessarily trust that they are secure, but do the work to verify them"

While a third-party service provider may be responsible for their own PCI compliance, a breach on their end puts your name in the headlines. Halbleib explains, “If you get compromised, there's a lot of potential reputational damage there. And you can say all you want, ‘it was a third-party service provider who screwed up’, but everybody sees your name in the headlines, not the third-party service provider.” 

You can do this by reviewing the TPSP's Attestation of Compliance (AOC) to ensure it covers the specific service you are purchasing.

Requirement 12.8 demands a clear delineation of which PCI requirements are the TPSP's responsibility, which are shared, and which remain yours. This is crucial for cloud-based services.

Inadequately Enforcing Access Controls

Access controls (Requirement 7) are foundational, but their implementation is often flawed, creating unnecessary risk. Remember to use:

  • Least Privilege: Access should be granted strictly on a "need-to-know" basis (role-based access control).
  • Unique IDs: You must ensure every person accessing the CDE has a unique identifier for accountability.
  • Mandate MFA Multi-Factor Authentication: Effective (MFA) is deployed correctly and with adequate strength for all remote access and non-console administrative access into the CDE.

Skipping Security Awareness Training

A common failure is assuming your workforce, even technical staff, understand their role in protecting card data without consistent, formal training.

PCI DSS requires annual security awareness training for all personnel and periodic reminders throughout the year. Glover suggests ensuring your staff “know their role in protecting cardholder data. You have to remind them about things and update them if anything new has happened."

In addition to training, all personnel must formally acknowledge, at least annually, that they have read and understood the relevant security policies.

Ignoring New PCI DSS Requirements

The latest version of the standard introduces new requirements that are no longer "future-dated." Organizations must be aware of and adequately prepare for them, especially those related to e-commerce and authentication.

So, what is new with PCI version 4? Requirements like 6.4.3 and 11.6.1 address the rise of e-commerce skimming (Magecart) attacks. 

Glover describes the rise in eskimming as something "we've been working on for three or four years researching, because we knew it was coming due to the forensics we saw. Eskimming is now the most prevalent method. So is it real? Yes. And do you have to deal with it? Yes. And is it simple to do on your own? No." The complexity of meeting these requirements (often involving monitoring changes to payment page content) means you should plan your solution now rather than wait.

Need an ecommerce skimming solution that meets 6.4.3 and 11.6.1? Check out SecurityMetrics Shopping Cart Monitor.

Join thousands of security professionals.
Subscribe Now
Get the Guide To PCI Compliance
Download
Get Quote for PCI Compliance
Request a Quote