In a recent post, we discussed what PCI DSS is, why it matters, and the release of the latest version, including a summary of the changes and the impact of each. See “What PCI DSS version 3.2 means for you” for more information.
In 2016, West Monroe Partners has conducted over 140 IT diligences on behalf of private equity firms and strategic buyers across a number of industries as part of their mergers and acquisitions process, and many of those transactions have included a PCI DSS compliance component. We have also helped our clients conduct PCI DSS gap assessments and developed roadmaps and project schedules for meeting all required controls and achieving a PCI DSS compliant environment. We’ve found during the diligence or assessment process that there are many common areas where the PCI DSS requirements are misinterpreted or not properly met by organizations.
The Challenges with Attesting to Compliance
PCI DSS is a very complex standard, with over 233 requirements that all merchants must meet. The majority of merchants that we assess as part of the diligence process are categorized as Visa or MasterCard Level 3 or Level 4 for reporting purposes (See Compliance Validation section here for merchant level definitions). These organizations are typically self-reporting their compliance using a PCI DSS Self-Assessment Questionnaire (SAQ). While the intent of SAQs is to simplify the process of reporting compliance, we usually find that confusion over the correct form to use, and a misunderstanding of the payment ecosystem, means that these merchants are actually at higher risk due to underestimating which portions of their environment are required to be compliant and how to secure those systems.
Regardless of industry or company size, security budget or team size, and payment card acceptance channels or annual transaction volume, we see recurring issues with how PCI DSS required controls are interpreted and, as a result, how they are implemented. Common errors include:
- Identifying payment processes – PCI DSS applies to all storage, processing, or transmission of cardholder data, meaning it applies to any electronic or manual process that interacts with payment card data, regardless of the number of transactions. The most common processes we see omitted are telephone orders (particularly for predominantly ecommerce businesses) or manual orders via fax. Very often, the person filling out the PCI DSS attestation is not even aware that these other processes exist, in part because they are low-volume processes, or aren’t considered to be a “common” acceptance channel. The only way for an organization to avoid compliance obligations on a mechanism through which payment card data is provided is to establish processes to refuse acceptance of data via those channels and remove the mechanisms (e.g., a form that is faxed or emailed) that are being used to provide data via those channels where possible.
- Defining the cardholder data environment (CDE) – When determining PCI DSS compliance, the cardholder data environment is often thought to include far fewer systems and processes than it actually does. Many times organizations believe that not storing payment card data on systems removes them from scope, despite the transmission of payment card data across those systems. Other times, the entire payment card acceptance channel is not considered. A common example of this is customer contact centers where payment information is received; the Voice over IP (VoIP) phone system through which calls are received are often not considered to be in scope, nor are the workstations through which the customer service representatives enter the payment card information. As a result, required controls are not applied to all systems that store, process, or transmit payment card data, putting those channels at risk of unaddressed security vulnerabilities that may be used to compromise payment card data or other systems.
- Outsourcing the risk – Organizations often over-rely on vendors or service providers to address required controls or assume that because a vendor has gone through the process of attesting to compliance that the organization is not at risk. A common example of this is organizations that use a validated payment processor believe they are compliant because they are using a compliant solution; however, these organizations overlook how the data is protected before it gets to the solution they are using (i.e., securing the channels used to accept and enter the payment card data).
- Completing the SAQ – Incorrectly defining the CDE often leads merchants to complete the incorrect SAQ, as the choice of SAQ is often tied to specific payment card acceptance and entry channels. Additionally, the complex nature of PCI DSS means that merchants tend to choose the simplest SAQ that they think applies in an effort to reduce the number of applicable reporting requirements. This causes them to overlook the rules that apply to their environment, therefore incorrectly attesting to compliance.
- Estimating the financial costs of non-compliance or a data breach – Organizations often don’t understand the implications of not meeting specific controls or being non-compliant. If a card breach does occur, an organization could face fines from the card brands, costs to engage a forensic investigator to determine the extent of the breach and a containment strategy, costs associated with notifying affected cardholders by mail, and remediation and control implementation costs. While some of these costs vary according to the number of records compromised, many of them are relatively static, and economies of scale mean that smaller merchants are likely to face higher costs on a per-card basis than we have seen in the mega-breaches such as Target or Home Depot. One control that can be especially costly is the requirement that the Card Verification Value (CVV) may never be stored post transaction authorization. Storage of this value can come with fines of up to $500k per card brand per month.
Addressing the Challenges
In an upcoming blog series over the next few weeks, we will discuss in greater detail some specific PCI DSS required controls and common misconceptions we have heard from organizations, as well as ways that we have seen the controls appropriately implemented.
Upcoming topics include:
- Using network segmentation to isolate the cardholder data environment
- Documenting and testing incident response plans with teams beyond IT to ensure consistent and timely responses
- Encryption and key management solutions that effectively protect payment card data
- Considerations when engaging a vendor in PCI DSS compliant environments
- Managing and configuring customer application access to the CDE
- Accessing and administering the cardholder data environment without increasing the scope of the CDE
- Applying required controls to backup and disaster recovery systems and environments to protect all stored cardholder data
In a parallel blog series, we will also be discussing how we specifically met certain PCI DSS required controls for a client that migrated a customer facing Software as a Service application to Microsoft Azure. For more information on that design and implementation, see the introductory post of our other blog series.