If you’re a merchant taking credit card payments, chances are high that you’ve heard of the Payment Card Industry Data Security Standard (PCI DSS). While you may know that in order to process these payments, credit card providers require you to comply with the requirements outlined in the standard, knowing exactly what this entails and how to comply with each requirement is another story.
In this article, we’ll explain what it means to achieve PCI DSS compliance and why it matters for organisations.
History of the PCI DSS
Payment card fraud has long been a problem—even since before the magnetic stripe on the back of cards came into existence.
As Marcia Frellick, in her article on CreditCards.com puts it, “Perhaps the biggest driver for the stripe technology was the prevalence of credit card fraud in the 1960s, which was hard to prevent with the lag between purchase and account verification. Using a device called a zip-zap machine, a merchant would apply a roller over paper covering the raised numbers on the customer’s card, then physically take the paper to the bank. The bank would read it optically and manually check the number against known fraudulent accounts. That process could take days.”
Unfortunately, the magnetic stripe only helped reduce the amount of fraud for a time, but fraudsters found other ways to exploit the technology, which eventually led to the move to EMV chip and pin technology several years ago across Europe and the United States in 2005 and 2015 respectively. With the rise of ecommerce in the late 90s and early 2000s the amount of fraud skyrocketed and was exacerbated even more. Both Visa and MasterCard suffered massive losses of $750 million due to credit card fraud between the years 1988 and 1998, and thus had ample financial incentive to combat the issue and come up with a solution.
Visa led the pack when it created a set of security standards for merchants accepting payments online in 2001 called the Cardholder Information Security Programme. The other major payment card providers quickly followed suit and established their own unique sets of security standards as well, all requiring any merchant accepting their cards to abide with them. Merchants who accepted multiple card types had to follow each card brand’s standard, adding a layer of burdensome complexity to compliance efforts. In addition to Visa’s, the four other programmes included:
- MasterCard’s Site Data Protection
- American Express’s Data Security Operating Policy
- Discover’s Information Security and Compliance
- JCB’s Data Security Programme
Introduction of the PCI DSS
In 2004, realising the burden they were putting on merchants with their separate, but similar, security programmes, and to address the crisis of the growing amount of data breaches due to the explosion in ecommerce payments, the major card brands came together to condense their standards into one comprehensive, overarching programme. The end result was PCI DSS version 1.0, with the same twelve broad requirements that are still in place today and which have not changed since its inception. As Chad Clay of Kontrol Payables Journal says, “The system was immediately hailed by the industry as a massive breakthrough, one that offered potential for incremental improvement in the future.”
In 2006, the first major update to the PCI DSS was announced in version 1.1, along with the formation of the Payment Card Industry Security Standards Council (PCI SSC).
What is the PCI SSC?
The PCI SSC is an independent body formed by the five major payment card providers (Visa, MasterCard, American Express, Discover, and JCB), to oversee the administration and evolution of the PCI DSS. According to the PCI SSC’s website, “The Council maintains, evolves, and promotes the Payment Card Industry Security Standards. It also provides critical tools needed for implementation of the standards such as assessment and scanning qualifications, self-assessment questionnaires, training and education, and product certification programmes.”
In terms of membership and participation, it goes on to say, “All five payment brands, along with Strategic Members, share equally in the Council’s governance, have equal input into the PCI Security Standards Council and share responsibility for carrying out the work of the organisation.”
An important point to note is that the Council is not responsible for the enforcement of compliance of the PCI DSS or the application of any penalties for noncompliance, which is left to the card brands themselves.
Since the introduction of PCI DSS version 1.1, the Council has released the following versions:
- 1.2 on October 1, 2008 to enhance clarity, improved flexibility, and addressed evolving risks and threats.
- 1.2.1 in August 2009 made minor corrections designed to create more clarity and consistency among the standards and supporting documents.
- 2.0 in October 2010.
- 3.0 in November 2013; in effect from January 1, 2014 to June 31, 2015.
- 3.1 in April 2015, retired on October 31, 2016.
- 3.2 in April 2016, will be retired on December 31, 2018.
- 3.2.1 was released in May 2018.
Twelve Main Requirements of the PCI DSS
As previously mentioned, the PCI DSS has twelve overarching security requirements, which are each broken down into sets of specific and detailed sub-requirements. The requirements are as follows:
PCI DSS Requirement:
|Build and Maintain a Secure Network||1. Install and maintain a firewall configuration to protect cardholder data.
2. Do not use vendor-supplied defaults for system passwords and other security parameters.
|Protect Cardholder Data||3. Protect stored cardholder data.
4. Encrypt transmission of cardholder data across open, public networks.
|Maintain a Vulnerability Management Programme||5. Use and regularly update anti-virus software or programs.
6. Develop and maintain secure systems and applications.
|Implement Strong Access Control Measures||7. Restrict access to cardholder data by business need-to-know.
8. Assign a unique ID to each person with computer access.
9. Restrict physical access to cardholder data.
|Regularly Monitor and Test Networks||10. Track and monitor all access to network resources and cardholder data.
11. Regularly test security systems and processes.
|Maintain an Information Security Policy||12. Maintain a policy that addresses information security for all personnel – and ensure that all personnel are aware of it.|
To learn more about each requirement and what they entail, take a look at our PCI DSS compliance checklist blog.
Who Must Comply with the PCI DSS?
Simply put, any merchant accepting card payments must comply with all twelve of the requirements laid out in the PCI DSS. At the same time, the card brands recognise different levels of merchants, depending on the amount of transactions they process per year. While the compliance requirements are the same for every merchant, the validation requirements vary by level, so it’s important to understand where your organisation falls and what it will take to prove compliance. To learn more about merchant levels and their validation requirements, refer to our blog post all about PCI DSS merchant levels.
How to Prove PCI DSS Compliance
Depending on an organisation’s merchant level (level 1 merchants process more than 6 million transactions annually, whereas level 4 merchants process up to 20,000 transactions annually), the validation requirement will vary, however there are generally two types of assessments the PCI SSC recognises to demonstrate proof of compliance.
Report on Compliance (ROC) – a wide-ranging report that contains six sections prepared by a Qualified Security Assessor (QSA) as part of their annual PCI assessment. The QSA then passes this on to the merchant’s acquiring bank, who then sends it on to the card brands for compliance verification.
Self-Assessment Questionnaire (SAQ) – the SAQ serves as a self-validation tool that organisations can complete on their own. It consists of a series of Yes or No questions relating to the 12 requirements of the PCI DSS, with “No” answers requiring an attached remediation plan describing the organisation’s actions it plans to take to solve the issue. In addition to the set of questions, the SAQ also requires an Attestation of Compliance.
Penalties for Noncompliance
For merchants that fail to achieve PCI DSS compliance, the card brands can choose to fine the merchant’s acquiring bank anywhere between $5000 – $100,000 per month. The acquiring banks then usually pass these fines onto the merchant. For repeated violations, the card brands may revoke the merchant’s privileges to accept payments using their cards entirely, which could be catastrophic for business.
Why Your Organisation Should Comply
In addition to avoiding fines for noncompliance by the card brands and potential revocation of the privilege to accept card payments, there are a number of benefits to achieving PCI DSS compliance. These include tighter data security and a reduced risk of data breaches, leading to a squeaky-clean brand reputation. Additionally, complying with the PCI DSS can establish a mindset of security throughout your organisation and can also provide a blueprint for complying with other data security regulations like GDPR. Finally, and perhaps most importantly, it can provide you with peace of mind that you’ve implemented proper security controls to help protect your business.