A guide to PCI compliance
Payment Card Industry Data Security Standards (PCI DSS) sets the minimum standard for data security — here’s a step by step guide to maintaining compliance and how Stripe can help.
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 impacting 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 programs—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 over 1,800 pages of official documentation, published by the PCI Council, about PCI DSS, and over 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.
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 organization that accepts or processes payment cards.
PCI DSS compliance involves 3 main things:
- 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 3rd party audits (see the step by step guide below for a table with the four levels of requirements)
Handling card data
Some business models do require the direct handling of sensitive credit card data when accepting payments, while others do not. Companies that do need to handle card data (e.g., accepting untokenized 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. Since card data never touches its servers, the company would only need to confirm 22 security controls, most of which are straightforward, such as using strong passwords.
Storing data securely
If an organization 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. Since all 300+ security requirements in PCI DSS apply to 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 organization 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, organizations are required to complete a PCI validation form annually. The way PCI compliance is validated depends on a number of factors, which are outlined below. Here are 3 scenarios in which an organization 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 latest set of security standards, PCI DSS version 3.2.1, includes 12 main requirements with over 300 sub-requirements that mirror security best practices.
BUILD AND MAINTAIN A SECURE NETWORK AND SYSTEMS
- Install and maintain a firewall configuration to protect cardholder data
- Do not use vendor-supplied defaults for system passwords and other security parameters
PROTECT CARDHOLDER DATA
- Protect stored cardholder data
- Encrypt transmission of cardholder data across open or public networks
MAINTAIN A VULNERABILITY MANAGEMENT PROGRAM
- Protect all systems against malware and regularly update anti-virus software
- Develop and maintain secure systems and applications
IMPLEMENT STRONG ACCESS CONTROL MEASURES
- Restrict access to cardholder data by business need to know
- Identify and authenticate access to system components
- Restrict physical access to cardholder data
REGULARLY MONITOR AND TEST NETWORKS
- Track and monitor all access to network resources and cardholder data
- Regularly test security systems and processes
MAINTAIN AN INFORMATION SECURITY POLICY
- Maintain a policy that addresses information security for all personnel
To make it “easier” for new businesses to validate PCI compliance, the PCI Council created nine different forms or Self-Assessment Questionnaires (SAQs) that are a subset of the entire PCI DSS requirement. The trick is figuring 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 v3.2.1 compliance
1. Know your requirements
The first step in achieving PCI compliance is knowing which requirements apply to your organization. There are four different PCI compliance levels, typically based on the volume of credit card transactions your business processes during a 12-month period.
| APPLIES TO | REQUIREMENTS | |
|---|---|---|
| LEVEL 1 | 1. Organizations that process more than 6 million transactions annually; or |
- Have experienced a data breach; or
- Are deemed “Level 1” by any card association (Visa, Mastercard, etc)|1. Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA)—also commonly known as a Level 1 onsite assessment—or internal auditor if signed by an officer of the company
- Quarterly network scan by Approved Scan Vendor (ASV)
- Attestation of Compliance (AOC) for Onsite Assessments–there are specific forms for merchantsand service providers|
|LEVEL 2|Organizations that process between 1-6 million transactions annually|1. Annual PCI DSS Self-Assessment Questionnaire (SAQ)—there are 9 SAQ types shown briefly in the table below - Quarterly network scan by Approved Scan Vendor (ASV)
- Attestation of Compliance (AOC)—each of the 9 SAQs has a respective AOC form|
|LEVEL 3|1. Organizations that process between 20,000-1 million online transactions annually - Organizations that process less than 1 million totaltransactions annually|
|LEVEL 4|1. Organizations that process fewer than 20,000 onlinetransactions annually; or - Organizations that process up to 1 million total transactions annually|
For Level 2-4, there are different SAQ types depending on your payment integration method. Here’s a brief table:
| SAQ | DESCRIPTION |
|---|---|
| A | Card-not-present merchants (e-commerce or mail/telephone-order), that have fully outsourced all cardholder data functions to PCI DSS compliant third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. |
Not applicable to face-to-face channels.|
|A-EP|E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of cardholder data on merchant’s systems or premises.
Applicable only to e-commerce channels.|
|B|Merchants using only:
- Imprint machines with no electronic cardholder data storage, and/or
- Standalone, dial-out terminals with no electronic cardholder data storage.
Not applicable to e-commerce channels.|
|B-IP|Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor with no electronic cardholder data storage.
Not applicable to e-commerce channels.|
|C-VT|Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based, virtual payment terminal solution that is provided and hosted by a PCI DSS validated third-party service provider. No electronic cardholder data storage.
Not applicable to e-commerce channels.|
|C|Merchants with payment application systems connected to the Internet, no electronic cardholder data storage.
Not applicable to e-commerce channels.|
|P2PE|Merchants using only hardware payment terminals included in and managed via a validated, PCI SSC-listed Point-to-Point Encryption (P2PE) solution, with no electronic cardholder data storage.
Not applicable to e-commerce merchants.|
|D|SAQ D FOR MERCHANTS: All merchants not included in descriptions for the above SAQ types.
SAQ D FOR SERVICE PROVIDERS: All service providers defined by a payment brand as eligible to complete an SAQ.|
To select the SAQ and Attestation documents that best apply to your organization, the flowchart on page 18 of this PCI doc can help.
The PCI DSS requirements change over time, so one of the best ways to get updates on new or changing certification requirements and how to meet them is to become a PCI Participating Organization (PO).
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 want to create a comprehensive map of the systems, network connections, and applications that interact with credit card data across your organization. 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 cart, 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 centers, and cloud environments.
3. Check security controls and protocols
Once you map out all the potential touchpoints for credit card data across your organization, work with IT and security teams to ensure 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, like Transport Layer Security (TLS).
The 12 security requirements for PCI DSS v3.2.1 stem from best 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 organization.
4. Monitor and maintain
It’s important to note that PCI compliance is not a one-time event. It’s an ongoing process to ensure 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 over 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 worthwhile to create 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 the organization 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 organization’s systems evolve.
- Finance : The Chief Financial Officer (CFO) and their team ensures 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: prioritized 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 organizations 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.
With safer card acceptance methods like these, we’ll populate the PCI form (SAQ) in the Stripe Dashboard, making PCI validation as easy as clicking a button. For smaller organizations this can save hundreds of hours of work, for larger ones this can save thousands.
For all our users, regardless of integration type, Stripe acts as a PCI advocate and can help in a few different ways.
- We’ll analyze your integration method and advise you on which PCI form to use and 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), we provide a PCI-packet that can reduce PCI validation time from months to days. If you need to work with a PCI QSA (because you store credit card data or have a more complex payment flow), there are over 350 such QSA companies around the world, and we can connect you with several auditors that deeply understand the different Stripe integration methods.
| VISA’S MERCHANT LEVEL | AVERAGE AUDIT TIME (annual estimates) | AVERAGE AUDIT TIME WITH STRIPE ELEMENTS, CHECKOUT OR MOBILE SDK (annual estimates) |
|---|---|---|
| LEVEL 1 | 3-5 months | 2-5 days |
| LEVEL 2 | 1-3 months | 0 days |
| LEVEL 3 | 1-3 months | 0 days |
| LEVEL 4 | 1-3 months | 0 days |
For more information about how Stripe helps you protect your customers’ data and achieve PCI compliance, check out our docs about integration security.
Conclusion
Assessing and validating PCI compliance usually happens once a year, but PCI compliance is not a one-time event — it’s a continuous and substantial effort of assessment and remediation. As a company grows so will the core business logic and processes, which means compliance requirements will evolve as well. An online business, for example, may decide to open physical stores, enter new markets, or launch a customer support center. If anything new involves payment card data, it’s a good idea to proactively check whether this has any impact on your PCI validation method, and re-validate PCI compliance as necessary.
PCI compliance helps. It’s just not enough.
Adherence to the PCI DSS guidelines is a necessary layer of protection for your business — but it’s not enough. PCI DSS sets important standards for handling and storing cardholder data, but by itself does not provide sufficient protection for every payment environment. Instead, moving to a safer card acceptance method (like Stripe Checkout, Elements and mobile SDKs) is a much more effective way to protect your organization. The long-standing benefit this provides is that you don’t need to rely on industry baseline standards or worry about the potential failure of security controls. This approach provides agile businesses a way to mitigate a potential data breach and avoid the emotional, time consuming, and costly historical approach to PCI validation. Not to mention, a safer integration method is reliable every single day of the year.
Curated by Liquid Layer Networks
At Liquid Layer Web Hosting [LiquidLayer.net], we’ve made a shared web hosting platform that’s both feature-rich and easy to make use of. Our programmers have built up a custom Linux cloud web hosting platform plus an innovative Control Panel that perfectly takes advantage of its capabilities. After long hours of programming and bug fixing on our end, we are now capable to guarantee that all of our shared web hosting services are safe, virus-free, full of capabilities and very easy-to-work-with. In addition, they feature 99.9% server uptime as well as 99.9% network uptime warranties.
Powered by:
HostCheetah Networks
Global Web Hosting, Domain Registration, and Internet Services
https://hostcheetah.net | http://hostcheetah.uk
PC Helper | Est 1996 - Web Hosting | US, AU, UK, Finland, Bulgaria | 
https://pchelper.com
