Are you new to PCI compliance? This guide gives you a fast overview to help you get started. You'll learn what PCI compliance is, what the requirements cover, and what you need to know.
What Is the PCI DSS?
The major payment card brands created a standard set of security rules to protect credit and debit card information. This is called the Payment Card Industry Data Security Standard, or PCI DSS. Any organization that handles cardholder data, or could affect its security, has to follow these standards. That applies to every process and system that touches cardholder data (more on scope below).
There are 12 main requirements of the PCI DSS:
- Requirement 1 - Install and Maintain Network Security Controls (such as firewalls).
- Requirement 2 - Apply Secure Configurations to All System Components.
- Requirement 3 - Protect Stored Account Data.
- Requirement 4 - Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks.
- Requirement 5 - Protect all Systems and Networks from Malicious Software.
- Requirement 6 - Develop and Maintain Secure Systems and Software.
- Requirement 7 - Restrict Access to System Components and Cardholder Data by Business Need to Know.
- Requirement 8 - Identify Users and Authenticate Access to System Components.
- Requirement 9 - Restrict Physical Access to Cardholder Data.
- Requirement 10 - Log and Monitor All Access to System Components and Cardholder Data.
- Requirement 11 - Test Security of Systems and Networks Regularly.
- Requirement 12 - Support Information Security with Organizational Policies and Programs.
Each requirement has sub-requirements that support the main goal. All of them matter, but the sheer number can feel overwhelming. The PCI DSS standard (version 4.0.1) is nearly 400 pages long. This guide gives you a brief overview of each requirement and what it's really asking for.
This guide covers every major requirement in the PCI DSS, the same ones found in a Report on Compliance (ROC) or the full Self-Assessment Questionnaire (SAQ-D). If you qualify for a shorter SAQ, you'll only need to report on a subset of these.
Determining Your Scope
In PCI terms, “scope” means all the people, processes, and systems that PCI DSS requirements apply to. By default, everything in your organization is in scope: workstations, servers, cash registers, routers, switches, wireless access points, and more. Most organizations cut down the time and cost of staying compliant by isolating the systems that receive, store, process, or transmit cardholder data. This is called “segmentation.” Done right, segmentation shrinks your PCI scope down to just the devices that actually handle cardholder data, which saves a lot of time and money.
How to Achieve Segmentation
Start by isolating every server, workstation, point-of-sale device, and any other device that handles cardholder data into its own firewalled network zone. If a device accepts, views, stores, logs, or transmits cardholder data, it's part of your Cardholder Data Environment, or CDE. All CDE systems should live inside a PCI network. A stateful firewall must control all traffic in and out of that network, including traffic to and from your other internal networks. Devices inside a PCI network need to meet every PCI requirement. Devices outside it are out of scope, and PCI DSS doesn't apply to them. Any in-scope service that needs public access, like a web server, has to sit in a DMZ, with firewall rules locked down to only the IP addresses, protocols, and ports it actually needs.
The PCI council has provided helpful guidance with everything you need to know about PCI scoping and segmentation.
Personnel roles should be clearly defined too, so only people who need CDE access to do their job actually have it.
Note: “Cardholder data” means any data that includes the Primary Account Number (PAN, typically 13-19 digits) of a credit or debit card. If every PAN is truncated to no more than the BIN (the first 6-8 digits, per card brand) and/or the last 4 digits, it's no longer considered cardholder data under PCI standards. You should still handle truncated data securely, but out-of-scope systems can handle it.
Once you've scoped out your CDE (and likely segmented it), you'll know exactly which systems need to meet PCI DSS requirements. The next 12 sections of this guide summarize the 12 major requirements that apply to your CDE.
Note: Some sub-requirements of the PCI DSS apply only to organizations that are “Service Providers.” Most merchants are not considered service providers, but some are. According to the PCI DSS glossary provided by the PCI council, here's how a service provider is defined:
“Service Provider: Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data and/or sensitive authentication data (SAD) on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include payment gateways, payment service providers (PSPs), independent sales organizations (ISOs), managed service providers that provide managed firewalls, IDS and other services, as well as hosting providers and other entities...”
If your business doesn't provide managed security services or payment processing services to other businesses, then the service provider sub-requirements probably don't apply to you.
We hope this guide helps as you work toward PCI DSS compliance. If you have questions about our ASV scanning services or our penetration testing services, please contact our support team. We're happy to help.