Glossary of PCI DSS Terms and Definitions
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.