The Payment Card Industry Data Security Standard (PCI DSS) is a set of security controls that businesses are required to implement to protected cardholder data and sensitive authentication data wherever it is processed, stored or transmitted. All businesses, regardless of size, that accept credit card transactions or process credit card information must comply with the standards PCI DSS is broad, encompassing every aspect of the extensive cardholder data environment. This includes employee training, documented policies, physical security and online security.
PCI DSS sets both operational and technical requirements. Not only do you want to secure the environment, but you’ll also want to prevent the intrusion from happening in the first place and limit exposure if it does occur.
Some of the basic components of a PCI program can be very straightforward. For example, your organization will begin by assessing where card data is captured, transmitted and stored within your environment. The organization’s network can be mapped to locate card data and conduct a vulnerability scan for card processing services to identify any weaknesses. These scans are available online and through vendors. Vulnerability scans are required each quarter as part of a PCI program, but additional periodic scans can be an extra help. In addition, instituting a system scan process is an effective way to check items like password strength and whether security patches are properly installed. Establishing a comprehensive PCI program doesn’t need to be overwhelming. Certified PCI vendors can be hired to help an organization assess and scan their environment. Vendors may offers data breach protection in addition to software processes. A key benefit of data breach protection is the financial reimbursement for expenses like forensic costs, card replacement costs, any incurred fraud losses and card network assessments, conducted by Visa and MasterCard.
PCI DSS has established requirements to support the protection of credit card data. Follow your organization’s processes relating to these requirements.
Build & Maintain a Secure Network & 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
Do not store sensitive authentication data after authorization.
Purge unnecessary stored data at least quarterly.
Render the Primary Account Number (PAN) unreadable anywhere it is stored
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. Cardholder data stored on paper needs to be secured and tracked at all times and then disposed of in a shredder.
10. Periodically inspect POS device to detect tampering. Credit card terminals should be inspected on a regular basis for tampering. Signs of tampering are cracks in the case of the device as if it were forced open, scratches around seams in the device to change our internal components, extra components that have been added onto the device that have not been there before. If you notice a terminal has been tampered, you should follow your tamper notification procedure immediately.
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 issue isn’t if your organization will be subject to attempted data compromise but when the attack will occur. It is critically important for your organization to examine how strong its existing security practices are before settling on the right balance between time, resources and effort required to implement a solid program.
Every business, large or small, is at risk. Hackers are looking for vulnerabilities in a program, an entire system or just a specific application. When data thieves discover the vulnerability, they exploit it to compromise the system and steal valuable data. In addition to payment card data, they can steal confidential information, employee data and even patient medical data.
A typical breach is first identified by a card network like Visa, Discover or MasterCard. This is triggered by a Common Point-of-Purchase notification, or CPP. A CPP notification can identify multiple cards reporting fraudulent transactions during a specific time range at a single business. Details of the notification are used to pinpoint common factors like the specific employees, terminals or systems involved. Your business must take action right away when a CPP notification is received, and contact customers immediately advising them about possible issue.
Organizations complete a thorough investigation, while taking care not to destroy any key pieces of evidence. If any card data appears at risk, the various card networks take action to gather information and report the risk to banks. Your organization’s name doesn’t need to be involved at this stage. Instead, only the necessary details regarding fraudulent use and transactions need to be passed on. Once an investigation is closed and the breach resolved, to the organization should revalidate their compliance with PCI DSS. After validation is complete, new PCI DSS documents will be delivered to any impacted card networks. This can be helpful in ensuring the risk of future data breaches is minimized.
PCI DSS is designed to reduce the costs of a data breach in three ways. First, it lowers the risk of a payment card compromise from occurring. Second, it reduces the duration of a compromise. Third, it limits the type of data that could be exposed to criminals and fraudsters.
Hard costs start with the investigation itself. Card networks often require a forensic investigation before they take action. This is so that both the organization and the card networks can see when the compromise started, when it was contained and its full scope. An investigation like this averages $12,000 for a small business. A larger business could easily expect to pay much more for a full forensic investigation. After the investigation, payment networks might issue fines, fees, assessments, and card replacement costs to your organization.
Soft costs can be more difficult to quantify. Although soft costs come in many varieties, the most expensive might be damage to an organization’s brand. A data breach can lead to a poor image and a bad reputation among patients or the community at large. Counteracting this damage often takes a massive PR effort, which in turn takes resources away from other important tasks.
Every entity accepting, transmitting or storing payment card data must validate compliance with the PCI DSS. How that happens, however, can vary based on the existing protocol for card processing.
First, organizations need to select the right Self-Assessment Questionnaire, or SAQ. This relates to how a customer handles payment card data. There are seven potential SAQs that could apply, and each is driven by the technology in place. A chart to assist your organization in selecting the right SAQ is included in the Resource Links section of this module.
Customers may also need to pass a vulnerability scan. This is only necessary if they connect to the Internet when processing card payments. A vulnerability scan is an automated tool that scans the network and can identify any known vulnerabilities. The NIST, or National Institute of Standards and Technology, issues an extensive list of all these potential vulnerabilities. Quarterly scans are required to achieve compliance, but many organizations find a more frequent cadence preferable.
A penetration test may also be required for some organizations. Completed by ethical hackers, a penetration test is designed to find out whether an experienced IT professional can hack into the environment where customer cards are processed. After the penetration test, a report is issued detailing the findings. This report advises customers on any security gaps that might exist and how to close them.
A
Card-not-present businesses (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 business' systems or premises. Not applicable to face-to-face channels.
A-EP
E-commerce businesses that outsource all payment processing to PCI DSS validated third parties, and that have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No storage, processing, or transmission of cardholder data on business' systems or premises. Applicable only to e-commerce channels.
B
Businesses 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
Businesses 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
Businesses with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels.
C-VT
Businesses that 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.
P2PE
Businesses using only hardware payment terminals included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage. Not applicable to e-commerce businesses.
D
Any business that does not qualify for one of the other SAQs or qualifies for more than one SAQ, or who stores credit card data in their environment
For more information:
Please visit the PCI Security Standards Council website for additional information
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security controls that businesses are required to implement to protected cardholder data and sensitive authentication data wherever it is processed, stored or transmitted. All businesses, regardless of size, that accept credit card transactions or process credit card information must comply with the standards PCI DSS is broad, encompassing every aspect of the extensive cardholder data environment. This includes employee training, documented policies, physical security and online security.
PCI DSS sets both operational and technical requirements. Not only do you want to secure the environment, but you’ll also want to prevent the intrusion from happening in the first place and limit exposure if it does occur.
Address:
PCI Security Standards Council, LLC
401 Edgewater Place
Suite 600
Wakefield, MA USA 01880
Phone: +1-781-876-8855
Merchant Validation Inquiries: +1-781-876-8855 option 1
Training and Qualification Programs
PCI Training Programs:
Phone: +1-781-876-8855 option 5
Email: training@pcisecuritystandards.org
Approved Scanning Vendor (ASV):
Phone: +1-781-876-8855 option 3
Email: asv@pcisecuritystandards.org
Internal Security Assessors (ISA):
Phone: +1-781-876-8855 option 3
Email: isa@pcisecuritystandards.org
PCI Forensic Investigator (PFI):
Phone: +1-781-876-8855 option 3
Email: pfi@pcisecuritystandards.org
PCI Professional (PCIP):
Phone: +1-781-876-8855 option 3
Email: pcip@pcisecuritystandards.org
Qualified Integrators and Resellers (QIR):
Phone: +1-781-876-8855 option 3
Email: qir@pcisecuritystandards.org
Qualified Security Assessor (QSA):
Phone: +1-781-876-8855 option 3
Email: qsa@pcisecuritystandards.org
Software & Hardware Validation Programs
Card Production:
Email: pcicard@pcisecuritystandards.org
Payment Application (PA-QSA/PA-DSS):
Phone: +1-781-876-8855 option 3
Email: pa-dss@pcisecuritystandards.org
PIN Transaction Security (PTS):
Phone: +1-781-876-8855 option 3
Email: pcipts@pcisecuritystandards.org
Point-to-Point Encryption (P2PE):
Phone: +1-781-876-8855 option 3
Email: p2pe@pcisecuritystandards.org
Get Involved
Participating Organization (PO) Program:
Phone: +1-781-876-8855 option 2
Email: participation@pcisecuritystandards.org
Speaking Opportunities:
Phone: +1-781-876-6224
Email: pcispeaking@pcisecuritystandards.org
Community Meeting:
Phone: +1-781-876-8855 option 4
Email: pcicm@pcisecuritystandards.org
Board of Advisors:
Email: boa@pcisecuritystandards.org
Press and Analyst Inquiries:
Contact: Laura K. Johnson and Lindsay Goodspeed
Email: press@pcisecuritystandards.org
PCI Translations:
Email: Translations@pcisecuritystandards.org
Have a question? Visit our Help Center to see frequently asked questions.
Having a technical issue with the website?
From understanding the PCI DSS 3.2 requirements, to pairing up with the right PCI compliant hosting provider, achieving PCI compliance requires a wealth of knowledge about the payment card industry. Start with our PCI Glossary to learn more about the industry’s many intricacies.
ACQUIRER
An acquirer is an entity that initiates and maintains relationships with merchants for the acceptance of payment cards. Merchants must submit PCI DSS assessment documentation (including an SAQ, ROC, and/or ASV scan report) to acquirers. Because acquirers are involved in payment card processing, they must also be PCI compliant. (Also called “merchant bank,” “acquiring bank,” or “acquiring financial institution.”)
ATTESTATION OF COMPLIANCE (AOC)
The AOC is a form used by merchants and service providers to attest to the results of a PCI DSS assessment. It is submitted to an acquirer or payment brand along with the appropriate SAQ or ROC, plus any other requested documentation.
APPROVED SCANNING VENDOR (ASV)
An ASV is a company that is approved by the PCI SSC to conduct external vulnerability scanning services. These scanning services involve an automated tool that checks a PCI entity’s system for vulnerabilities in OSs, services and devices. A company must submit a passing ASV scan every quarter/every 90 days if it stores CHD electronically after authorization, or if it qualifies for certain SAQs.
AUDIT LOG
An audit log is a chronological record of system activities that provides the ability to prevent, detect or minimize the impact of a cardholder data compromise. The generation and review of an audit log facilitates thorough tracking, alerting and analysis when a CDE system component is compromised. (Also called an “audit trail.”)
In the PCI DSS 3.1, audit log generation and management is primarily addressed in requirement 10 (“Track and monitor all access to network resources and CHD”).
CARDHOLDER DATA (CHD)
CHD consists of, at minimum, a cardholder’s full primary account number (PAN), which is embossed and/or encoded on a payment card. CHD may additionally include cardholder name, card expiration date and/or service code. PCI compliance exists primarily to protect CHD when it is stored, processed and transmitted.
CARDHOLDER DATA ENVIRONMENT (CDE)
A cardholder data environment encompasses the people, processes, and technology that store, process or transmit CHD. The PCI DSS has specific requirements to which the physical and virtual components of a CDE must comply in order to ensure CHD security. These components include POS systems, servers, network components, applications and third party IT systems.
DMZ
DMZ is an abbreviation for “demilitarized zone,” and refers to the second line of defense to a CDE’s Protected Zone containing cardholder data. CHD on servers in the Protected Zone can interact with the DMZ, but not the Internet, thus screening external parties from direct connection to the internal network. PCI DSS requirements that address firewalls also include specifications for DMZ security.
FIREWALL
Firewalls are hardware and/or software technology that protects network resources from unauthorized access. They provide cardholder data environments with perimeter protection—a first line of defense in the path to a Protected Zone where data is stored. The PCI DSS requires entities to install and maintain a firewall configuration to protect cardholder data.
PAYMENT CARDS
In the context of PCI compliance, a “payment card” is any payment card or device that bears the logo of American Express, Discover Financial Services, JCB International, MasterCard Worldwide or Visa Inc. Payment cards in the scope of PCI include credit, debit, and pre-paid cards. Merchants, service providers, acquiring banks, processors and issuers that handle cardholder data from these payment card brands all must comply with the PCI DSS.
PCI
PCI stands for “Payment Card Industry.” PCI includes all entities that store, process or transmit cardholder data (CHD). This applies to both merchants with a Merchant ID (MID) that accept payment cards of PCI SSC members, as well as service providers that handle CHD on behalf of another entity. Additional entities include processors, acquiring financial institutions and card issuers. PCI entities must comply with the PCI DSS, a framework document created and maintained by the PCI SSC. Compliance with these regulations entails the submission of certain documents proving the completion of a PCI DSS assessment.
PCI DSS
PCI DSS stands for “Payment Card Industry Data Security Standard.” The PCI DSS is a document created and maintained by the PCI Security Standards Council that provides industry entities with a framework of 12 requirements meant to reduce payment card fraud and data security breaches. Industry entities include any organization involved in payment card processing—including merchants, processors, acquirers, issuers and service providers. The PCI DSS is intended to ensure that all PCI entities maintain a secure environment for CHD. Compliance with the PCI DSS requires industry entities to perform assessments and submit results to acquirers and payment brands. The most recent version is PCI DSS 3.2.
PCI SSC
PCI SSC stands for “Payment Card Industry Security Standards Council.” The council was launched in 2006 as an open global forum. It is responsible for the maintenance of the PCI Security Standards, including the Data Security Standard (PCI DSS), Payment Application Data Security Standard (PA-DSS), and PIN Transaction Security (PTS) requirements. The PCI SSC consists of 5 global payment brands: American Express, Discover Financial Services, JCB International, MasterCard and Visa Inc. Because these brands have incorporated compliance with the PCI DSS into their security programs, companies that handle cardholder data from these brands must comply with PCI requirements. (Note that compliance is coordinated with the individual brands, not with the SCC.)
PENETRATION TESTING
Penetration tests are tests performed to identify and address ways in which a CDE’s system components’ security features can be exploited. That exploitation could lead to either the features’ circumvention or breach. Penetration testing also helps verify that segmentation is appropriately in place, thereby isolating the CDE from other networks.
Requirement 11.3 of the PCI DSS speaks specifically to penetration testing requirements. It stipulates that an entity’s testing methodology be based on industry-accepted penetration testing approaches; that the testing must include coverage of the CDE perimeter and critical systems; that the testing must occur internally and externally; and that it must include both the network and application, in addition to the corresponding controls and processes of each.
QSA
QSA stands for “Qualified Security Assessor.” QSAs are independent security companies qualified by the PCI SSC to validate an entity’s adherence to the PCI DSS by performing an on-site assessment of a merchant or service provider. After an assessment, a QSA report must accompany a Report on Compliance (ROC) with an Attestation of Compliance (AOC) that summarizes whether the entity is in compliance PCI DSS, and any related findings.
RISK ASSESSMENT
Risk assessment is defined as a process that identifies critical assets, threats and vulnerabilities in a cardholder data environment. The process should be implemented as part of an organization’s risk management strategy, and should result in formal risk assessment documentation. Risk assessments should be performed annually and in the event of significant changes to a CDE. (Also called “risk analysis.”)
RISK RANKING
A risk ranking is a defined criterion of measurement based upon the risk assessment performed on an entity. Such a ranking should be applied to newly discovered security vulnerabilities in a cardholder data environment, and may be ranked as “high,” “medium,” or “low.” Risk rankings should, at a minimum, identify all “high risk” vulnerabilities.
In the PCI DSS 3.1, risk ranking is primarily addressed in requirement 6.
REPORT ON COMPLIANCE (ROC)
A Report on Compliance is a report documenting detailed results from a Level 1 entity’s PCI DSS assessment. The ROC is filled out by a QSA after an audit, and subsequently submitted to the merchant’s acquirer. The acquirer, after accepting the ROC, sends it to the payment brand for verification.
SAQ
SAQ stands for “Self-Assessment Questionnaire.” The PCI DSS SAQ is a reporting tool used by eligible merchants and service providers to document self-assessment results from a PCI DSS assessment. An SAQ consists of two components: a set of questions corresponding to the PCI DSS requirements and an Attestation of Compliance (AOC). There are a number of SAQs available, each for different environments. Once complete, the SAQ is submitted with the AOC and any other requested documentation to the appropriate acquirer or payment brand.
SENSITIVE DATA
Any data center, server room or any area that houses systems that store, process or transmit CHD. PCI DSS requirement 9 specifies means for restricting physical access to CHD in order to secure sensitive areas. (These exclude areas that only have POS terminals.)
SERVICE PROVIDER
A PCI service provider is a business entity that is not a payment brand, directly involved in the processing, storage or transmission of CHD on behalf of another entity. Service providers collaborate with partnering business entities to create compliant solutions that enable both parties to be PCI compliant. Examples include PCI compliant hosting providers, managed service providers and other entities.
In the PCI DSS 3.1, compliance measures required of a service provider are primarily addressed in requirements 8 and 12.
SYSTEM COMPONENTS
Any network devices, servers, computing devices, or applications included in or connected to the cardholder data environment. The PCI DSS security requirements apply to all CDE system components.These include network and virtualization components, security service systems and certain server types.
In the PCI DSS 3.1, CDE system component security is primarily addressed in requirements 8 and 10.
TWO-FACTOR AUTHENTICATION
Two-factor authentication requires two independent authentication factors to validate user access. This level of authentication provides an extra layer of defense to protect a cardholder data environment (CDE) against unauthorized entry. Two-factor authentication solutions require the user to produce two different items, each from a different category. The categories include something the user has, knows, is or does. (Also called “dual-factor authentication” or “multi-factor authentication.”)
In the PCI DSS 3.1, two-factor authentication is primarily addressed in requirement 8.3.