When did PCI DSS become mandatory?
PCI DSS compliance became mandatory with the rollout of version 1.0 of the standard on December 15, 2004. But we should pause here to talk about what we mean by “mandatory” in this context. PCI DSS is a security standard, not a law. Compliance with it is mandated by the contracts that merchants sign with the card brands (Visa, MasterCard, etc.) and with the banks that actually handle their payment processing.
And, as we’ll see, for most companies compliance with the standard is achieved by filling out self-reported questionnaires. For those merchants, PCI DSS compliance mainly becomes “mandatory” in retrospect: if a breach occurs that can be traced back to a failure to implement the standard correctly, the merchant can be sanctioned by their payment processors and the card brands. Merchants may be required to undergo (and pay for) an assessment to ensure that they’ve improved their security, which we’ll discuss in more detail later in this article; they may also be required to pay fines. Very large companies may be required to undergo assessments conducted by third parties even if they haven’t suffered a breach.
PCI DSS fines
PCI DSS fines can vary from payment processor to payment processor, and are larger for companies with a higher volume of payments. It can be difficult pin down a typical fine amount, but IS Partners provides some ranges in a blog post. For instance, fines are assessed per month of non-compliance and the per-month charge increases for longer periods, so a company might pay $5,000 a month if they’re out of compliance for three months, but $50,000 a month if they go as long as seven months. In addition, fines ranging from $50 to $90 can be imposed for each customer who’s affected in some way by a data breach.
Again, keep in mind that these aren’t “fines” in the same sense that, say, you’d pay for violating some government regulation or traffic law; they’re penalties built into a contract between merchants, payment processors, and card brands. Generally the card brands fine the payment processors, who in turn fine the merchants, and the whole process is not necessarily based on the same standards of evidence one would expect in a criminal court, though disputes can end up in civil court.
A 2012 case involving Utah restaurateurs Stephen and Cissy McComb brought some of the murky world of PCI DSS fines into the limelight; the McCombs claimed that they had been accused of lax security based on no evidence and that $10,000 had been improperly siphoned from their bank account by their payment processor. In 2013, Tennessee shoe retailer Genesco fought back against a $13 million dollar PCI DSS fine leveled in the wake of a major data breach, eventually recovering $9 million in court.
Still, most merchants seek to avoid having to pay these fines by ensuring that they comply with the PCI DSS standard. So let’s dive into the details of what that entails.
PCI DSS requirements
The PCI DSS standard lays out 12 fundamental requirements for merchants. We’re listing the requirements for version 4.0 here, though they largely parallel the requirements in 3.2. (We’ll discuss this transition in more detail in a moment.)
- Install and maintain network security controls to prevent unauthorized access to systems.
- Apply secure configuration to all system components. It may seem obvious to say this, but it’s particularly important to not use vendor-supplied defaults for system passwords and other security parameters.
- Protect stored account data; and…
- Use strong cryptography when transmitting cardholder data across open, public networks. These two requirements ensure that you protect data both at rest and in motion.
- Protect systems and networks from malicious software. Malware is a tool hackers use to gain access to stored data, so constant vigilance is required.
- Develop and maintain secure systems and applications. You need to not only roll out security measures, but make sure they’re up to date.
- Restrict access to cardholder data by business need-to-know. This is a fundamental basis of data security generally, but is especially important when it comes to financial data.
- Identify users and authenticate access to system components. Not only will this protect against unauthorized data access, but it will allow investigators to determine if an authorized insider misused data. It’s particularly important that each authorized user have their own access ID, rather than a single shared ID for all employees who access an account.
- Restrict physical access to cardholder data. Not all data theft is a result of high-tech hacking. Make sure nobody can simply walk off with your hard drive or a box of receipts.
- Log and monitor all access to network resources and cardholder data. This is one of the most commonly violated requirements, but it’s crucial.
- Regularly test security systems and processes, and…
- Maintain a policy that addresses information security. These last two requirements ensure that the steps you take to meet the previous ten are effective and become part of your organization’s institutional culture.
What does it mean to be PCI DSS compliant?
PCI DSS compliance comes from meeting the obligations laid down by these requirements in the way best suited to your organization, and the PCI Security Standards Council gives you the tools to do so. The RSI security blog breaks down the steps in some detail, but the process in essence goes like this:
- Determine your organization’s PCI DSS level. Organizations are divided into levels (more on which in a moment) based on how many credit card transactions they handle annually.
- Complete a self-assessment questionnaire. These are available from the PCI Security Standards Council website, and there are various questionnaires tailored to how different companies interact with credit card data. If you only take card payments online via a third party, you’d fill out Questionnaire A, for instance; if you use a standalone payment terminal connected to the internet, you’d go with Questionnaire B-IP. Each questionnaire determines how well your organization adheres to the PCI DSS requirements, tailored as appropriate by the ways in which you interact with customer credit card data.
- Build a secure network. The answers you give on your questionnaire will reveal any weak spots in your credit card infrastructure and requirements you fail to meet, and will guide you in plugging those holes.
- Formally attest your compliance. An AOC (attestation of compliance) is the form you use to signal that you’ve achieved PCI DSS compliance. Finishing your questionnaire with no “wrong” answers means that you’re ready to go.
As should be clear, the questionnaires provide a sort of PCI DSS compliance checklist. However, don’t let this be the end of your security journey. As David Ames, principal in the cybersecurity and privacy practice at PricewaterhouseCoopers, told CSO Online’s Maria Korolov, “we have seen that concentrating strictly on standalone compliance efforts can produce a false sense of security and an inappropriate allocation of resources. Use the PCI DSS as a baseline controls framework that is supplemented with risk management practices.”
PCI DSS levels
As noted, the PCI DSS standard recognizes that not all organizations have equal risk factors or equal capability to roll out security infrastructure. The specific requirements for meeting the standard that your organization will need to meet will depend on your company’s level, which is in turn determined by how many credit card transactions you process annually:
- Level 1: Merchants that process over 6 million card transactions annually.
- Level 2: Merchants that process 1 to 6 million transactions annually.
- Level 3: Merchants that process 20,000 to 1 million transactions annually.
- Level 4: Merchants that process fewer than 20,000 transactions annually.
What’s new in PCI DSS 4.0?
The PCS DSS standard has of course had to evolve with the times, as both security technology and hacker techniques have evolved. As John Bambenek, a principal threat hunter at IT and digital security operations company Netenrich, puts it, “One of the problems with crafting regulations or pseudo-regulations, like PCI-DSS, is that technology changes and what was once a meaningful security control ceased to be one.”
Still, PCI DSS 3.2, which was retired in March 2024, had been the most up-to-date version of the standard since 2016. But PCI DSS 4.0 was in the works for a while, developed with industry feedback, and was finalized in April of 2022. Changes include:
- Terminology around firewalls has been updated to refer to network security controls more generally, to support a broader range of technologies used to fill firewalls’ traditional role. “Firewalls mattered 20 years ago,” says Bambenek. “You can’t get rid of them, but what you really want are network security controls that can do meaningful analysis and policy on a per-session basis, so the regulations needed to be changed.”
- Requirement 8 now goes beyond just requiring a unique ID for each person with computer access—a requirement generally fulfilled by assigning a username and password—and now mandates multi-factor authentication (MFA) for all access into the cardholder data environment
- Organizations now have increased flexibility to demonstrate how they are using different methods to achieve the security objectives outlined in the standard.
- Organizations can now also conduct targeted risk analyses, making it more flexible for them to define how frequently they perform certain activities. This allows them to better match their security posture with their business needs and risk exposure.
Who is responsible for PCI compliance?
Every organization will have a somewhat different take on who should lead its PCI compliance team, based on its structure and size. Very small businesses who have outsourced most of their payment infrastructures to third parties generally can rely on those vendors to handle PCI compliance as well. At the other end of the spectrum, very large organizations may need to involve executives, IT, legal, and business unit managers. The PCI Standards Security Council has an in-depth document, “PCI DSS for Large Organizations,” with advice on this topic; check out section 4, beginning on page 8.
PCI DSS certification vs PCI DSS assessment
There’s no such thing, in the world of PCI DSS, as “certification.” As we’ve discussed, the most common means of showing compliance with the PCI DSS is by completing the appropriate questionnaire and completing an attestation of compliance (AOC). This process is known as self-assessment.
Merchants may also choose to pay a third-party vendor to conduct a PCI DSS assessment. The PCI Security Standards Council certifies Qualified Security Assessors who can conduct these audits and produce what’s known as a report of compliance (ROC); you may sometimes see this process referred to as PCI DSS certification, though that’s strictly speaking not correct. While some organizations pay for ROCs voluntarily, others may be required to acquire one if they have suffered a breach or some other security violation. And large companies that qualify as PCI DSS level 1 are required to get an ROC on a regular basis.
Assessments aren’t cheap: they can run up to $50,000 for a large company. But even you aren’t required to get one, it may pay off in the long run. As Paul Cotter, senior security architect at West Monroe Partners, told CSO Online, in self-assessments companies tend to look at themselves in “in the most flattering way possible. You might spend $50,000 to hire a professional, but it might wind up saving you in the long run” because you’ll get an honest assessment of your security situation. And at its heart, that’s the kind of assessment the PCI DSS standard ought to deliver.
More on PCI DSS:
