Since 2005, over 11 billion consumer records have been compromised from over 8,500 data breaches. These are the latest numbers from The Privacy Rights Clearinghouse, which reports on data breaches and security breaches affecting consumers dating back to 2005.
To improve the safety of consumer data and trust in the payment ecosystem, a minimum standard for data security was created. Visa, Mastercard, American Express, Discover and JCB formed the Payment Card Industry Security Standards Council (PCI SSC) in 2006 to administer and manage security standards for companies that handle credit card data. Before the PCI SSC was established, these five credit card companies all had their own security standards programmes – each with roughly similar requirements and goals. They banded together through the PCI SSC to align on one standard policy, the PCI Data Security Standards (known as PCI DSS) to ensure a baseline level of protection for consumers and banks in the internet era.
Understanding PCI DSS can be complex and challenging
If your business model requires you to handle card data, you may be required to meet each of the 300+ security controls in PCI DSS. There are more than 1,800 pages of official documentation, published by the PCI Council, about PCI DSS, and more than 300 pages just to understand which form(s) to use when validating compliance. This would take over 72 hours just to "read".
To ease this burden, the following is a step-by-step guide to validating and maintaining PCI compliance.
PCI DSS version 4.0 goes into effect on 31 March 2024
Overview of PCI Data Security Standard (PCI DSS)
PCI DSS is the global security standard for all entities that store, process or transmit cardholder data and/or sensitive authentication data. PCI DSS sets a baseline level of protection for consumers and helps reduce fraud and data breaches across the entire payment ecosystem. It is applicable to any organisation that accepts or processes payment cards.
PCI DSS compliance involves three main components:
- Handling the ingress of credit card data from customers; namely, that sensitive card details are collected and transmitted securely
- Storing data securely, which is outlined in the 12 security domains of the PCI standard, such as encryption, ongoing monitoring and security testing of access to card data
- Validating annually that the required security controls are in place, which can include forms, questionnaires, external vulnerability scanning services and third-party audits (see the step-by-step guide below for a table with the four levels of requirements)
Handling card data
Some business models require the direct handling of sensitive credit card data when accepting payments, while others do not. Companies that need to handle card data (e.g. accepting untokenised PANs on a payment page) may be required to meet each of the 300+ security controls in PCI DSS. Even if card data only traverses its servers for a short moment, the company would need to purchase, implement and maintain security software and hardware.
If a company does not need to handle sensitive credit card data, it shouldn't. Third-party solutions (e.g. Stripe Elements) securely accept and store the data, whisking away considerable complexity, cost and risk. As card data never touches its servers, the company would only need to confirm a few security controls, most of which are straightforward, such as using strong passwords.
Storing data securely
If an organisation handles or stores credit card data, it needs to define the scope of its cardholder data environment (CDE). PCI DSS defines CDE as the people, processes, and technologies that store, process or transmit credit card data – or any system connected to it. Because all 300+ security requirements in PCI DSS apply to the CDE, it's important to properly segment the payment environment from the rest of the business so as to limit the scope of PCI validation. If an organisation is unable to contain the CDE scope with granular segmentation, the PCI security controls would then apply to every system, laptop and device on its corporate network. Yikes.
Annual validation
Regardless of how card data is accepted, organisations are required to complete a PCI validation form every year. The way PCI compliance is validated depends on a number of factors, which are outlined below. Here are three scenarios in which an organisation could be asked to show that it is PCI compliant:
- Payment processors may request it as part of their required reporting to the payment card brands.
- Business partners may request it as a prerequisite to entering into business agreements.
- For platform businesses (those whose technology facilitates online transactions among multiple distinct sets of users), customers may request it to show their customers that they are handling data securely.
The PCI DSS security standard includes 12 main requirements with more than 300 sub-requirements that mirror security leading practices.
BUILD AND MAINTAIN A SECURE NETWORK AND SYSTEMS
- 1. Install and maintain network security controls.
- 2. Apply secure configurations to all system components.
PROTECT ACCOUNT DATA
- 3. Protect stored cardholder data.
- 4. Protect cardholder data with strong cryptography during transmission over open, public networks.
MAINTAIN A VULNERABILITY MANAGEMENT PROGRAM
- 5. Protect all systems and networks from malicious software.
- 6. Develop and maintain secure systems and software.
IMPLEMENT STRONG ACCESS CONTROL MEASURES
- 7. Restrict access to system components and cardholder data by business need to know.
- 8. Identify users and authenticate access to system components.
- 9. Restrict physical access to cardholder data.
REGULARLY MONITOR AND TEST NETWORKS
- 10. Log and monitor all access to system components and cardholder data.
- 11. Test security of systems and networks regularly.
MAINTAIN AN INFORMATION SECURITY POLICY
- 12. Support information security with organisational policies and procedures.
To make it "easier" for new businesses to validate PCI compliance, the PCI Council has created nine different forms or Self-Assessment Questionnaires (SAQs) which are a subset of the entire PCI DSS requirement. The trick is working out which is applicable or whether it's necessary to hire a PCI Council–approved auditor to verify that each PCI DSS security requirement has been met. In addition, the PCI Council revises the rules every three years and releases incremental updates throughout the year, adding even more dynamic complexity.
Step-by-step guide to PCI DSS compliance
1. Know your requirements
The first step in achieving PCI compliance is knowing which requirements apply to your organisation. There are four different PCI compliance levels, typically based on the volume of credit card transactions your business processes during a 12-month period.
Compliance level
|
Applies to
|
Requirements
|
---|---|---|
Level 1
|
|
|
Level 2
|
|
|
Level 3
|
|
|
Level 4
|
|
|
For Levels 2 to 4, there are different SAQ types depending on your payment integration method. Here's a brief table:
Integration
|
Requirement
|
Recommendation
|
---|---|---|
Checkout or Elements
|
SAQ A |
Checkout and Stripe.js and Elements host all card data collection inputs within an iframe served from Stripe’s domain (not yours), so your customers’ card information never touches your servers.
|
Connect
|
SAQ A | If you exclusively collect card data through a Connect platform (for example, Squarespace), we can determine whether the platform provides the necessary PCI documentation. |
Mobile SDK
|
SAQ A |
Stripe’s mobile SDK development and change control complies with PCI DSS (requirements 6.3–6.5) and deploys through our PCI validated systems. When you only use UI components from our official SDKs for iOS or Android, or build a payment form with Elements in a WebView, card numbers pass directly from your customers to Stripe, so you have the lightest PCI compliance burden. If you do otherwise, such as writing your own code to handle card information, you might be responsible for additional PCI DSS requirements (6.3–6.5) and would be ineligible for an SAQ A. Talk to a PCI QSA to determine how to best validate your compliance according to the current guidance from the PCI Security Standards Council. If your application requires your customers to enter their information on their own devices, then you qualify for SAQ A. If your application accepts card information for multiple customers on your device (for example, a point-of-sale app), consult a PCI QSA to learn how to best validate your PCI compliance. |
Stripe.js v2
|
SAQ A-EP |
Using Stripe.js v2 to pass card data entered in a form hosted on your own site requires completing the SAQ A-EP annually to prove your business is PCI compliant. Alternatively, both Checkout and Elements allow you the flexibility and customisability of a self-hosted form, while also meeting PCI eligibility for the SAQ A. |
Terminal
|
SAQ C |
If you exclusively collect card data through Stripe Terminal, you can validate using SAQ C. If you integrate with Stripe using additional methods listed in this table, you must illustrate compliance for them separately as described. |
Dashboard
|
SAQ C-VT |
Manual card payments through the Dashboard are possible for exceptional circumstances only, not routine payment processing. Provide a suitable payment form or mobile application for your customers to enter their card information. We can’t verify that manually entered card information is secure outside of Stripe, so you must protect card data in accordance with PCI compliance requirements and complete the SAQ C-VT annually to prove your business is PCI compliant. |
Direct API
|
SAQ D |
When you pass card information directly to Stripe’s API, your integration is directly handling that data, and you’re required to annually prove your PCI compliance using the SAQ D –the most demanding of the SAQs. To reduce this burden:
In addition, Radar, our fraud prevention tool that includes risk evaluation and rules, is only available when using any of our methods for client-side tokenization. |
2. Map your data flows
Before you can protect sensitive credit card data, you need to know where it lives and how it gets there. You'll need to create a comprehensive map of the systems, network connections and applications that interact with credit card data across your organisation. Depending on your role, you'll probably need to work with your IT and security team(s) to do this.
- First, identify every consumer-facing area of the business that involves payment transactions. For example, you may accept payments via an online shopping basket, in-store payment terminals or orders placed over the phone.
- Next, pinpoint the various ways cardholder data is handled throughout the business. It's important to know exactly where the data is stored and who has access to it.
- Then, identify the internal systems or underlying technologies that touch payment transactions. This includes your network systems, data centres and cloud environments.
3. Check security controls and protocols
Once you've mapped out all the potential touchpoints for credit card data across your organisation, work with IT and security teams to ensure that the right security configurations and protocols are in place (see the list of 12 security requirements for PCI DSS above). These protocols are designed to secure the transmission of data, such as Transport Layer Security (TLS).
The 12 security requirements for PCI DSS stem from leading practices for protecting sensitive data for any business. Several overlap with those required to meet GDPR, HIPAA and other privacy mandates, so a few of them may already be in place in your organisation.
4. Monitor and maintain
It's important to note that PCI compliance is not a one-off event. It's an ongoing process to ensure that your business remains compliant even as data flows and customer touchpoints evolve. Some credit card brands may require you to submit quarterly or annual reports, or complete an annual on-site assessment to validate ongoing compliance, particularly if you process more than 6 million transactions each year.
Managing PCI compliance throughout the year (and year over year) often requires cross-departmental support and collaboration. If this doesn't already exist, it may be worth creating a dedicated team internally to properly maintain compliance. While every company is unique, a good starting point for a "PCI team" would include representation from the following:
- Security: The Chief Security Officer (CSO), Chief Information Security Officer (CISO) and their teams ensure that the organisation is always properly investing in the necessary data security and privacy resources and policies.
- Technology/Payments: The Chief Technology Officer (CTO), VP of Payments and their teams make sure that core tools, integrations and infrastructure remain compliant as the organisation's systems evolve.
- Finance: The Chief Financial Officer (CFO) and their team ensure that all payment data flows are accounted for when it comes to payment systems and partners.
- Legal: This team can help navigate the many legal nuances of PCI DSS compliance.
For more information about the complex world of PCI compliance, head to the PCI Security Standards Council website. If you only read this guide and a few other PCI docs, we recommend starting with these: prioritised approach for PCI DSS, SAQ instructions and guidelines, FAQ about using SAQ eligibility criteria to determine onsite assessment requirements and FAQ about obligations for merchants that develop apps for consumer devices that accept payment card data.
How Stripe helps organisations achieve and maintain PCI compliance
Stripe significantly simplifies the PCI burden for companies that integrate with Checkout, Elements, mobile SDKs and Terminal SDKs. Stripe Checkout and Stripe Elements use a hosted payment field for handling all payment card data, so the cardholder enters all sensitive payment information in a payment field that originates directly from our PCI DSS–validated servers. Stripe mobile and Terminal SDKs also enable the cardholder to send sensitive payment information directly to our PCI DSS-validated servers.
For all our users, regardless of integration type, Stripe acts as a PCI advocate and can help in a few different ways.
- We'll analyse your integration method and advise you on how to reduce your compliance burden.
- We'll notify you ahead of time if a growing transaction volume will require a change in how you validate compliance.
- For large merchants (Level 1), if you need to work with a PCI QSA (because you store credit card data or have a more complex payment flow), there are more than 350 such QSA companies around the world, and we can connect you with several auditors that deeply understand the different Stripe integration methods.