PCI DSS 101: Get up to speed quickly on PCI Compliance

The PCI DSS – Payment Card Industry Data Security Standard – is one of the most important security standards in the world. It applies wherever card transactions are processed, meaning it covers companies from tiny retail stores to the largest banks.

If you’re responsible in any way for the security of payment card transactions its likely you’ll need to deal with PCI DSS. Unfortunately the world of PCI DSS can be intimidating, with lots of jargon and knowledge assumed. Let us get you up to speed quickly with our basic overview. Welcome to PCI DSS 101!

Overview

The PCI DSS was created to improve the security of Cardholder Data (CHD) through the widespread adoption of a consistent set of security measures. Many people think of PCI as being a strict security standard. But really, for large companies PCI should be seen more as a minimum security baseline.

Who does PCI DSS apply to?

PCI DSS applies to any entity that stores, processes and/or transmits CardHolder Data (CHD) and/or Sensitive Authentication Data (SAD). These entities are typically categorized as Merchants, Issuers, or Acquirers. Companies called Processors can act as outsourced providers for any of these entities.

History of PCI DSS

In the late 1990s and early 2000s, the major card brands (Visa, Mastercard, American Express, and Discover) all introduced their own information security programs. Visa’s was Cardholder Information Security Program (CISP); Mastercard’s was Site Data Protection (SDP). Descendents of these original programs still exist today, although they have changed considerably.

Unfortunately the lack of a single security standard complicated merchant compliance efforts. It also drove up merchant compliance costs considerably as they were assessed multiple times per year.

To solve this issue, the card brands worked together to create a common set of data security standards. Their work resulted in the PCI DSS. Now, programs such as Visa CISP and Mastercard SDP reference the PCI DSS for many controls. Only those aspects which are card brand-specific, such as merchant levels, are spelled out in the card brand security programs.

After creating the PCI DSS, the above-mentioned security programs all deferred to this new standard for a large chunk of their core requirements.

The PCI Security Standards Council (PCI SSC)

The PCI Security Standards Council (PCI SSC or ‘Council’) was established as a joint venture between American Express, Discover, JCB, Mastercard, and Visa (the Card Brands) in 2006. The objective of the PCI SSC was and still is to develop and maintain the Payment Card Data Security Standard (PCI DSS).

The PCI SSC is not controlled by any of the card brands; rather it is controlled by its members who include companies from across the card payment ecosystem.

The PCI SSC and the Card Brands

The following table illustrates the separation of responsibilities between the PCI SSC itself, and the payment Card Brands.

PCI SSC	Payment Brands
Create awareness and adoption of PCI standards through community participation	Tracking and enforcement of PCI Compliance on Merchants and Service Providers
Manages qualification and accreditation of assessors, such as QSACs, ASVs, etc.	Issue Penalties for non-compliance
Responsible for maintaining the PCI DSS, and creating related standards such as Secure Software Framework	Defines the compliance levels for Merchants and Service Providers

Is the PCI DSS a law?

The PCI DSS is an industry driven security standard, not a law. Some jurisdictions may legislate to enact PCI DSS compliance into law for card processing; this is done outside the control of the PCI SSC.

PCI DSS Review Cycle

Because the information security environment is constantly changing, all security frameworks require regular review. The PCI SSC has defined a 3 year review cycle for the PCI DSS.

What is Cardholder Data?

The PCI DSS exists to protect CardHolder Data (CHD). So what is CHD?

PCI DSS defines all data related to payment cards as Account Data. This Account Data is subdivided into CardHolder Data (CHD) and Sensitive Authentication Data (SAD).

The key difference between these is that CHD can be stored after authorization if there is:

1. A defined business reason for the storage; and
2. Appropriate protection in place for that data

SAD may never be stored post authorization unless you are a card Issuer with a written business justification.

Why is there a difference between Merchants and Acquirers, and Issuers? Merchants and Acquirers never need to present the SAD after authorization, as authorization has already occurred. But Issuers may need to store SAD so they can use it to authenticate each card and cardholder as authorizations are received.

Cardholder Data	Sensitive Authentication Data
Primary Account Number (PAN)	Full track data
Cardholder Name	CAV2/CVC2/CVV2/CID
Expiration Date	PINs/PIN blocks
Service Code

The following table summarizes the storage requirements for PCI DSS Account Data.

	Data Element	Storage Permitted	Render Stored Data Unreadable per req. 3.4
Cardholder Data	Primary Account Number (PAN)	Yes	Yes
	Cardholder Name	Yes	No
	Service Code	Yes	No
	Expiration Date	Yes	No
Sensitive Authentication Data	Full Track Data	No	N/A
	CAV2/CVC2/CVV2/CID	No	N/A
	PIN/PIN Block	No	N/A

Payment Card Anatomy

Many of these data fields are easy to identify when looking at a diagram of a payment card. The magnetic stripe track data includes all the information embossed on the card, together with the Service Code and other information.

The Payment Card Processing Ecosystem

There are multiple entities in the payment card ecosystem:

• the card brands themselves
• issuers
• acquirers
• merchants

In addition, the cardholder is the one actually making purchases using their payment card.

As mentioned previously, any of these can outsource to a Processor, so cards can be “powered” by Issuer Processors. Typically the cardholder has no knowledge of these Processor entities, only the issuer themselves.

Issuers

An Issuer is a bank or other Financial Institution (FI) who made the payment card and provided it to the card holder. Often the Issuer is not actually the well known company on the front of the card. For example, many airlines offer credit cards with their branding. But they’re not the issuer – that’s some FI with their name in small print on the back.

Every time a cardholder attempts a purchase, the card Issuer decides if there is available credit or funds on hand to complete the transaction. Issuers are also responsible for releasing the funds to settle the transaction once it has been completed.

Merchants

Merchants are entities who accept cards as payment for goods or services. As such, Merchants can be companies of any size from an individual with a Square reader, to the largest grocery chains.

Card brands recognize that there’s not a one-size-fits-all approach to security that will work for all Merchants. So they define levels of Merchants, with different PCI DSS requirements. Fundamentally everyone is subject to the same rules around protecting CardHolder Data. But bigger merchants are expected to run more comprehensive security programs, and do more to show compliance.

Level	American Express	Discover	JCB	Mastercard	Visa
1	Merchants processing over 2.5 million American Express Card transactions annually, or any merchant that American Express deems a Level 1.	Merchants processing more than 6 million card transactions annually on the Discover network. Any merchant that Discover deems to be a Level 1. All merchants required by another payment brand or acquirer to validate and report their compliance as a Level 1 merchant.	Merchants processing over 1 million JCB transactions annually, or compromised merchants.	Merchants processing over 6 million Mastercard transactions annually, identified by Visa as Level 1, or merchants that have experienced an account data compromise.	Merchants processing over 6 million Visa transactions annually, identified by another payment card brand as Level 1, or merchants that have experienced an account data compromise.
2	Merchants processing 50,000 to 2.5 million American Express transactions annually or any merchant that American Express otherwise deems Level 2.	All merchants processing between 1 million and 6 million card transactions annually on the Discover network.	Merchants processing less than 1 million JCB transactions annually.	Merchants processing 1 million to 6 million Mastercard transactions annually, or merchants meeting the Level 2 criteria of Visa.	Merchants processing 1 million to 6 million Visa transactions annually.
3	Merchants processing less than 50,000 American Express transactions annually.	All other merchants.	N/A	Merchants processing 20,000 to 1 million Mastercard e-commerce transactions annually, or merchants meeting the Level 3 criteria of Visa.	Merchants processing 20,000 to 1 million Visa e-commerce transactions annually.
4	N/A	N/A	N/A	All other Mastercard merchants.	Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually.

The PCI DSS assessment and reporting requirements vary by size of merchant. Because the Merchant levels are set by the card brands rather than the PCI SSC, these requirements vary by card brand as well as by level.

Level	American Express	Discover	JCB	Mastercard	Visa
1	Annual on-site Security Assessment conducted by either a QSA, or an internal auditor with results certified by CEO, CFO, CISO, or principal Conduct quarterly network scans by an ASV and submit the AOSC or executive summary	Annual on-site Security Assessment conducted by either a QSA or an internal auditor holding the ISA qualification Conduct quarterly network scans by an ASV, submission of scan results not required	Annual on-site Security Assessment conducted by a QSA Conduct quarterly network scans by an ASV	Annual on-site Security Assessment conducted by either a QSA or an internal auditor holding the ISA qualification Quarterly network scans conducted by an ASV	File a ROC by QSA or Internal Auditor if signed by officer of the company. Submit an AOC form Conduct quarterly scans by an ASV
2	Complete an annual SAQ and have it certified by CEO, CFO, CISO, or principal Conduct quarterly network scans by an ASV and submit the AOSC or executive summary	Annual self-assessment conducted by an internal auditor Conduct quarterly network scans by an ASV, submission of scan results not required	Annual self-assessment Conduct quarterly network scans by an ASV	Annual self-assessment conducted by an internal auditor holding the ISA qualification, or on-site assessment conducted by a QSA Quarterly network scans conducted by an ASV	Complete an SAQ Submit an AOC form Conduct a quarterly network scan by an ASV
3	Recommended to complete an annual SAQ and have it certified by CEO, CFO, CISO, or principal Recommended to conduct quarterly network scans by an ASV and submit the AOSC or executive summary	Annual self-assessment conducted by an internal auditor Conduct quarterly network scans by an ASV, submission of scan results not required	N/A	Annual self-assessment conducted by an internal auditor holding the ISA qualification, or on-site assessment conducted by a QSA Quarterly network scans conducted by an ASV	Complete an SAQ Submit an AOC form Conduct a quarterly network scan by an ASV
4	N/A	N/A	N/A	PCI DSS compliance is required Acquirer will determine if compliance validation is required. If required: - Annual self-assessment conducted by an internal auditor holding the ISA qualification, or on-site assessment conducted by a QSA - Quarterly network scans conducted by an ASV	Complete an SAQ Submit an AOC form Conduct a quarterly network scan by an ASV

Acquirers

Acquirers are the banks which hold funds for Merchants. Acquiring banks provide Point Of Interaction (POI) devices to Merchants, such as card readers and payment terminals.

Because Acquirers provide or operate the payment terminals which allow merchants to accept card payments, Acquirers hold a couple of key roles:

1. they accept card payments and route then via the Card Brand networks to the Issuers;
2. they are responsible for paying the Merchant for the goods or services, and getting paid themselves by the Card Brands.

For PCI DSS purposes, Acquirers are typically treated as Service Providers, and demonstrate compliance using the Service Provider SAQs and AOCs.

Card Brands

The payment Card Brands include American Express, Discover, JCB, Mastercard, and Visa. Networks operated by the Card Brands connect the Acquirers and the Issuers, to enable payment transactions to be authorized.

The payment Card Brands are also responsible for assessing and paying interchange fees on the transactions they facilitate. They may also provide cross-border services such as currency exchange, depending on the transaction and entities involved.

Card Payment Overview

There are multiple steps involved in card payment processing, starting with the CardHolder swiping or dipping their card.

Authorization

Authorization is the process where a Merchant obtains approval in principle from an Issuer.

1. CardHolder swipes or dips their payment card at the Merchant POS terminal
2. Card details are sent to the Acquirer via an Internet or other connection in an authorization message
3. Acquirer forwards the authorization message to the Card Brand network
4. Card Brand forwards the authorization message along with any fee information to Issuer
5. Issuer receives Authorization request
6. Issuer validates the PAN, Expiration Date, CVC/CVVs, potentially other card data (card Authentication)
7. If card appears valid, Issuer verifies sufficient funds available to proceed
8. If sufficient funds or credit limit available, Issuer places hold on Authorization amount in CardHolder account
9. Issuer sends approval or decline message back to Merchant via Card Brand and Acquirer
10. Merchant POS records Approval amount to be submitted for clearing process at end of day
11. Merchant provides the customer a receipt to complete the sale

Clearing & Settlement

Clearing is the process whereby Authorizations are converted into completed transactions. Authorization simply places a hold on funds or credit limit; Clearing says that the transaction was successful and moves the funds internally.

Settlement is the process where funds are exchanged between each entitiy to finalize the transaction.

Authorization occurs at the time a customer swipes or dips their card. Clearing and Settlement are both typically batch processes and can happen one or more times per day.

1. At end of each day, Merchant sends all approved Authorizations in a batch to its Acquirer
2. The Acquirer sends the completed Authorization records to the appropriate Card Brands as Clearing Messages
3. Each Card Brand sends the Clearing Messages to the Issuers to be cleared
4. Typically next business day, the Issuer will transfer funds corresponding to all Cleared transactions to the Card Brand
5. The Card Brand then sends the appropriate amounts to each Acquirer bank account
6. The Acquirer transfers appropriate funds to the Merchant bank account to cover CardHolder purchases
7. For a credit card, the Issuer bills the cardholder at the end of each billing cycle. The Cardholder pays the Issuer.

Because clearing files are processed after authorization has occurred, additional PCI DSS rules apply. Clearing messages typically won’t contain SAD, because the Merchant is not allowed to store this information after authorization for later use.

Matching Clearing and Authorization messages

If there is no SAD present in clearing messages, how does the Issuer match the clearing message with the original authorization message?

When the Issuer response to an authorization request, there is a randomly-generated authorization ‘auth’ code included in the response. The Merchant is allowed to store this auth code, and includes it in the subsequent clearing message they generate at the end of day. Issuers use a combination of the PAN, expiration date, auth code, and other information such as the merchant ID, to match the clearing message with the original authorization request.

The Payment Card Security Ecosystem

While the PCI DSS is maintained by the PCI SSC, no assessments are performed by this organization. The PCI SSC exists to maintain the standards, but the PCI compliance world is full of other companies.

Qualified Security Assessor (QSA) Companies

Qualified Security Assessor (QSA) Companies are authorized by the PCI SSC to perform annual PCI DSS assessments. If you are a larger merchant or service provider, you will likely need to undergo an annual assessment by a QSA.

Approved Scanning Vendors (ASVs)

PCI Approved Scanning Vendors (ASVs) are companies trained and authorized by the PCI SSC to perform vulnerability scanning of your Internet computers. All but the smallest merchants are required to use a PCI ASV to perform quarterly scans of their Internet connection. Even if you are doing a Self-Assessment Questionnaire (SAQ) you are likely to need to contract with an ASV.

Note that this vulnerability scanning is one aspect of PCI DSS you are not allowed to do yourself. As such, the ASV relationship is probably the most common one by far in the PCI compliance world.

PCI Forensic Investigators

PCI Forensic Investigators (PFIs) are companies trained and authorized by the PCI SSC to conduct breach investigations. In the event there is a breach of computers in PCI scope, you are required to contract with a PFI company. The PFI will review all aspects of your computer systems and information security program. Their objectives are to understand how the breach happened, and what the total data lost was. You don’t want to be in a situation where you must work with a PFI company.

PCI DSS Objectives and Requirements

The PCI DSS consists of 12 requirements, which are grouped together into 6 separate objectives.

Objective	#	Requirement
Build and Maintain a Secure Network and Systems	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 Program	5	Protect all systems against malware 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	Identify and authenticate access to system components
	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

The following is a high level description of each requirement. We use the language of the requirement summary from the PCI DSS Assessment Procedures document to capture the essence of each requirement.

Requirement 1

All systems must be protected from unauthorized access from untrusted networks. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.

Requirement 2

Malicious individuals often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.

• Change vendor default passwords
• Have one primary function per server
• Remove unnecessary functions & services
• Encrypt all non-console admin access
• Shared hosting providers must protect each client’s environment and CHD

Requirement 3

Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data the data is unreadable and unusable to that person.

• Keep CHD storage to a minimum
• Do not store SAD after authorization
• Never store Track data, CVC/CVV, PIN/PIN blocks
• Mask PAN when displayed
• Protect stored PAN by encryption or hashing
• Follow standardized cryptographic procedures

Requirement 4

Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured networks and vulnerabilities in legacy protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gainaccess to cardholder data environments

• Encrypt CHD during transmission over open, public networks
• Encrypt wireless networks transmitting CHD
• Never send unprotected PANs by end-user messaging technologies (email, iMessage, WhatsApp, …)

Requirement 5

Malware – including viruses, worms, and Trojans – enters the network during manyapproved activities including employee e-mail and use of the Internet, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.

• Install antivirus software on all systems
• Regularly update antivirus signatures
• Antivirus must be configured to scan regularly
• Prevent end-users from disabling antivirus software and scanning

Requirement 6

Unscrupulous individuals use security vulnerabilities to gain access to systems. Many of these vulnerabilities are fixed by vendor security patches which must be installed as needed.

• Perform regular patch management
• Define and operate a secure SDLC
• Perform code reviews
• Maintain & use a secure coding checklist aligned with industry standards
• Use a Web Application Firewall for services outside the CDE

Requirement 7

Systems and processes must be in place to limit access to sensitive data and systems based on need to know and according to job responsibilities. “Need to know” is when access rights are granted to only the least amount of data and privileges needed to perform a job.

• Role-based access to CHD
• Principle of business need to know
• Principle of least privilege
• Deny all access by default

Requirement 8

Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their actions. Actions taken on critical data and systems are performed by, and can be traced to, known and authorized users and processes.

• Assign a unique user ID & password for all users
• Grant access based on approvals
• Remove access for terminated users
• Lock out accounts after multiple login failures
• Time out user sessions after 15 minutes inactivity
• Require strong passwords which must be changed every 90 days
• Require MFA for all remote access to the CDE

Requirement 9

Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted.

• Operate video cameras & access control mechanisms
• Restrict access to network jacks, Wireless Access Points (WAPs), mobile devices & network infrastructure
• Ensure visitors can be readily identified
• Protect removable media
• Protect all devices capturing or storing CHD

Requirement 10

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong.

• Define what events should be logged
• Define what should be logged for each event
• Syncronize time across all systems
• Use FIM to protect log files
• Review logs daily
• Store logs online for 90+ days, and keep for 1+ years

Requirement 11

Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.

• Test for rogue Wireless Access Points (WAPs)
• Perform quarterly internal vulnerability assessment
• Quarterly ASV scans
• Annual penetration testing
• Use IDS/IPS platform at critical network points

Requirement 12

A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it.

Where to get more training?

Many sites now have information on PCI DSS compliance, but unfortunately this knowledge is fragmented. To help you quickly get the information you need for your specific case, we maintain an article on PCI DSS training. This discussed both the paid and free training options available to help you develop PCI knowledge.