Blog Posts

6 Common Mistakes and Challenges with PCI DSS Compliance

6 Common Mistakes and Challenges with PCI DSS Compliance

Service providers and retailers that accept credit cards can save tons of money and time on PCI DSS compliance by avoiding a few costly mistakes. Officially called the Payment Card Industry Data Security Standard, the amount of information about PCI DSS compliance, audits, and self-assessments can feel overwhelming at first. When you break it down, there are a few important points to know about PCI audits, as well as the common mistakes and challenges you could run into along the way. 

What Does a PCI DSS Audit Look Like? 

An audit with PCI DSS can only be performed by a Qualified Security Assessor who is certified by the Security Standards Council. Audits are performed annually either on larger Level 1 merchants or on smaller merchants that have experienced a prior data breach. It can cost anywhere from $15,000 to $40,000 to complete your audit depending on the size and complexity of your business. The PCI website offers a list of Qualified Security Assessors to choose from in your first step towards compliance.

Noncompliance comes with many consequences from damaging your reputation as a merchant, to losing the ability to accept payment cards, to fines of $5,000 to $100,000 per month until compliance is met. For these reasons it is of the utmost importance to recognize some of the mistakes and challenges met with achieving compliance. 

Three Common Mistakes

1. Improper Segmentation and Scope: One of the biggest mistakes that merchant organizations make is failing to separate the cardholder data environment from the rest of the data infrastructure. This is known as network segmentation. Knowing and understanding your cardholder data environment means ensuring that all necessary IT controls are in place, providing segmentation between in-scope and out-of-scope environments, and reducing the risk of impact by those environments which are out-of-scope. 

Improper segmentation and scoping can result in hackers accessing cardholder data from less secure areas. 

To avoid issues here, make sure to take the time necessary to properly plan and document all in-scope areas of your cardholder data environment. Any system that affects the security of the cardholder data environment is considered to be in-scope and should be labeled as such. This applies primarily to your subnetworks. Any subnetworks that have no access to cardholder data should be segmented out. Some examples of in-scope systems include antivirus, monitoring servers, patch management, and administrative workstations. 

2. Failure To Change Vendor Defaults: One of the controls necessary to PCI compliance is building and maintaining a secure network, which includes a couple of simple rules. One of these is “do not use vendor-supplied defaults for system passwords or other security parameters.” 

Surprisingly default passwords are often forgotten about, making this one of the most common mistakes. This includes when you’re handling the deployment of virtual machines, which have vendor-supplied defaults and can be missed in scans performed during an audit. This can be avoided by changing all passwords and configurations on systems in use, including virtual machines, from their default settings before they are deployed. 

3. Assuming That Compliance Doesn’t Apply To You: Many merchants assume that how they take or store payment card information makes them exempt from PCI DSS compliance without realizing that the standard applies to any transaction, transmission, or storage of payment card data. If you take payment card information by word of mouth and input it into a system to be stored, that is still being transmitted via a network through your bank. 

Some merchants also assume that the size of their business also plays a role in whether or not PCI DSS applies again without realizing that there is no size of business that is exempt from compliance. PCI DSS applies to all businesses that handle the storing, processing, or transmitting of cardholder data or sensitive authentication data regardless of size and scope. Further, even if you outsource card processing to a vendor, you still have responsibilities associated with some PCI DSS controls so you must ensure that you meet those compliance requirements. 

Three Common Challenges  

1. All Requirements Are Mandatory: Unlike the SOC 2 Trust Services Criteria which are flexible and can be modified to fit the needs of your organization, there are over 300 complete requirements that need to be fulfilled to be compliant with the PCI DSS. This is a difficulty for many organizations which feel they only need to fulfill some or most of the requirements to be compliant. 

If controls cannot be fulfilled directly, organizations must fulfill compensating controls that lead to the same compliance. If all requirements aren’t fulfilled, your organization is subject to fines and potential termination of payment card acceptance. Qualified Security Assessors (QSA) and Approved Scanning Vendors (ASV) approved through the Security Standards Council go a long way to ensure that all requirements of the security standard are met. 

2. Confirming Third-Party Service Providers Are Compliant: Often organizations hire third-party suppliers to help with their PCI compliance aims, but this does not entirely relieve all responsibility. It can help to ensure that your third-party support is also compliant by conducting risk assessments on the third party. You can also employ modes for continuous monitoring to ensure that the third party is compliant over time with PCI DSS requirements. 

3. Completing Proper Self Assessment Questionnaires: If you aren’t being audited, you’re filling out one of these. One of the biggest compliance challenges is ensuring that your organization completes the proper Self Assessment Questionnaire (SAQ). Often organizations meet compliance difficulty when they assume they fit different criteria when they actually don’t. This causes them to fill out the wrong information in the questionnaire. 

There are officially eight different SAQs to be filled out based on eligibility. For example, some SAQs are only for merchants that handle card-not-present transactions, which require only the identifying information on the card. Others are for merchants using imprint machines only. Still, others are for merchants with payment application systems connected to the internet but no electronic cardholder data storage. Filling out the wrong SAQ can be an unfortunate waste of time so it’s better to make sure you fit the eligibility criteria by looking into the eight different SAQ types beforehand. 

The road to PCI compliance can feel like quite the hassle but getting expert advice can help save your team valuable time and money. Book a demo with Carbide today to see how we can help you reach your PCI DSS goals.

Share