Are you new to PCI compliance? This fast-start guide will give you a condensed overview and serve as a primer to help you get started with what PCI compliance is, a summary of the requirements, and what you need to know.

What is the PCI DSS?:
In an effort to protect the sensitive information associated with credit cards and debit cards, the major payment card brands have established a standard set of security requirements that help to keep credit card information safe. This set of requirements is called the Payment Card Industry Data Security Standard (or PCI DSS). All organizations that handle cardholder information, or that could impact the security of cardholder information are required to maintain these standards for all processes and systems that can impact the security of cardholder data (see more on determining scope below).

There are 12 main requirements of the PCI DSS:

Each requirement includes supportive sub requirements that help to meet the primary objective. While all the requirements of the PCI DSS are important and help to enhance security, the amount of requirements and subrequirements can be overwhelming. The PCI DSS standard is 139 pages long! This guide will give a brief overview of each requirement and provides insight to clarify the purpose and objective of each requirement.

This guide covers all the major requirements of the PCI DSS as contained in a Report on Compliance (ROC) or the full Self Assessment Questionnaire (SAQ-D). Merchants that qualify to use other SAQ versions will only need to report on a subset of these requirements.

Determining scope:

In PCI terms, “scope” is used to describe all the people, processes and systems to which the PCI DSS requirements apply. By default, all systems of an organization are in scope, including all workstations, servers, cash registers, routers, switches, wireless access points, etc. In order to reduce the time and costs involved with maintaining compliance with the PCI DSS, most organizations find it very beneficial to isolate the systems involved in receiving, storing, processing, or transmitting cardholder data. This isolation is commonly referred to as “segmentation”. When performed properly, segmentation allows organizations to reduce the scope of their PCI environment to only include the devices which are essential to the handling of cardholder data. In most cases, segmentation significantly reduces the time and resources required to maintain PCI compliance.

How to achieve segmentation:

The first step to achieving segmentation is to isolate all servers, workstations, point-of-sale devices, and all other devices used to handle cardholder data into dedicated, firewalled network zones. If a device is used to accept, view, store, log, or transmit cardholder data then it is part of your Cardholder Data Environment, or CDE. All CDE systems should be in a PCI network. A stateful firewall must be used to restrict all traffic into and out of the PCI network(s), including all traffic to or from any of your other internal networks. Any device on a PCI network must have all the PCI requirements maintained, but devices outside of your PCI networks are out-of-scope, and the PCI DSS standards do not apply. Any in-scope services that require public access (like a webserver) must be put in a DMZ, and firewall rules must be locked down to restrict all access in and out to only the IP addresses, protocols, and ports that are absolutely necessary.

The PCI council has provided helpful guidance with everything you need to know about PCI scoping and segmentation.

Personnel roles should also be clearly defined and assigned such that access to the CDE is restricted to only individuals that require access to perform their job-related responsibilities.

*Note: Keep in mind that “cardholder data” is defined as any data that includes the 15 or 16 digit Primary Account Number (PAN) of a Credit or Debit card. However, if all PAN instances are shortened (aka truncated) to include no more than the first 6 digits and/or last 4 digits, then the data is no longer considered cardholder data by PCI standards. Data that is truncated in this way should still be handled securely but it can be handled by out-of-scope systems.

Once you have your CDE scoped out (and likely segmented), you know which systems will need to meet the requirements of the PCI DSS. The next 12 sections of this guide will summarize the 12 major requirements of the PCI DSS that should be applied 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, this is the definition of a service provider:

“Service Provider: Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities...”

If your business does not 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 that you find this guide useful in your efforts toward PCI DSS compliance. If you have any questions about our ASV scanning services or our penetration testing services, please contact our support team and we will be happy to assist you!