EMV FAQs ®
EMV Chip
Q A Q A Q A
Q A Q A Q A
What is EMV? EMV, also known as a chip card, is a globally accepted smart chip technology payment standard established by EuroCard, MasterCard and VISA in the early 1990s. EMV cards come with an embedded microprocessor that provides better transaction security, card authentication and additional application capabilities not possible with traditional magnetic stripe cards. The chip on an EMV card interacts with the merchant’s point-of-sale device and is very difficult to duplicate. How does EMV technology benefit SMB merchants? EMV increases security and fraud protection against counterfeit, lost or stolen payment cards. EMV also enables interoperability with the global payments infrastructure. In other words, EMV cards can be used with any EMV-enabled terminal anywhere in the world. How does EMV help prevent fraud? Each EMV card comes with an embedded smart chip that is programmed by the card issuer to create a unique cryptogram (a secret code) for every transaction. The code represents a randomly generated numeral provided by the point-of-sale (POS) terminal at the time that the purchase amount is keyed in by the cashier. Use of an EMV chip triggers cardholder verification required for authentication: Chip & PIN; Chip & signature; or nothing. If connectivity with the card issuer is unavailable during the transaction, the chip determines whether the transaction may be processed offline. What is the timing for EMV in the U.S.? The U.S. is one of the last industrial countries to migrate to EMV chip card technology as a payment standard. October 1, 2015 marks the date on which fraud liability shifts for all non-EMV enabled point-of-sale devices (except for automated fuel dispensers at gas stations). U.S. Banks have already started issuing EMV cards and it is expected that by the end of 2015 there will be 166 million EMV credit cards and 105 million EMV debit and pre-paid cards in circulation in the US. What exactly does the liability shift mean? Starting October 1, 2015, the party that provides the most EMV options will be protected from financial liability originating from counterfeit, lost or stolen card-present transactions. For example, if a chip card is presented to a merchant who has not adopted an EMV-enabled terminal, liability for counterfeit fraud will shift to the merchant’s acquirer who will likely charge the fee back to the non-EMV compliant merchant. If a counterfeit magnetic stripe card (non-EMV chip card) is presented at an EMV-enabled terminal, liability will remain with the card issuer. Am I required to support EMV? You are not required by law to support EMV at this time. However, you may be putting yourself and your customers at risk, as fraud liability migrates to non-EMV enabled parties. Ensuring that your POS terminal(s) are chip capable and that your payment processing application can accept EMV chip card is good business.
©2015 First Data Corporation. All rights reserved. All trademarks, service marks and trade names referenced in this material are the property of their respective owners. Apple and iPhone® are registered trademarks of Apple Inc., registered in the U.S. and other countries. Apple Pay is a trademark of Apple Inc. 20705 0115
1
FAQs Q A Q A Q A Q A Q A Q A Q A
Who is enforcing EMV? There is no government entity or authority that is overseeing or enforcing migration to EMV in the US. However, the Payment Card Industry Security Standards Council (PCI SSC) and EMVCo, the official EMV standard governing body, are collaborating with major card issuers on EMV chip technology adoption and implementation in the US. As such, all SMBs and merchants who are accepting electronic card payments will be required to continue meeting PCI security compliance processes and be subject to the liability shift set forth by card issuers. What happens if SMBs and merchants don’t upgrade their POS system to EMV? Starting October 1, 2015, the merchant whose POS system is not EMV-enabled will assume full liability risk for fraudulent card-present transactions when processing chip cards on a non EMV-enabled terminal. Also, migration to EMV is a perfect opportunity for SMBs to enhance their electronic payment acceptance by adding additional payment forms including PIN debit, NFC (e.g. ApplePay™), and introducing other value-added programs to engage with their customers. Why do SMBs and small merchants have to worry about counterfeit, lost or stolen card fraud? As recently published and widely covered card breaches at several large national retailers in the US have illustrated, card fraud can be extremely costs and damaging to a brand - for a small business such an incident could be catastrophic. In addition to minimizing the risk of fraud, merchants implementing EMV chip payments in neighboring countries, including Canada and Mexico, have reported a significant decrease in fraudulent transactions. How are EMV transactions different? With EMV, customers will no longer hand over their payment card to a store associate/cashier for processing. Rather, a customer will keep the card in his/her possession and control at all times. Instead of swiping the card, as is the case with magnetic stripe cards, the customer will insert or “dip” the card into the EMV card reader and leave the card in the terminal until prompted to remove it. Because the customer will be required to insert (or tap, in case of an NFC card) the card, follow the prompts, enter a PIN and/or sign and remove the card at the appropriate time, an EMV-enabled payment device will have to be available. When is a signature required with a chip transaction? Although chip cards that require a PIN will be the norm, some may be configured to allow for a signature. From the merchant’s and cardholder’s perspectives, nothing changes. The card must remain inserted in the terminal during the entire transaction. If a chip card is removed prematurely, the transaction will be canceled. The terminal determines whether a PIN or signature is required, and the employee simply follows the prompts. When a signature is required, a signature line is printed on the receipt for the customer. What can SMBs and merchants expect from the change? EMV will change the way SMBs and merchants accept debit and credit payment cards at the point-of-sale (POS). The key areas to consider are: upgrading current POS payment system(s), and employee training. What can merchants do now to prepare for EMV? To migrate and successfully adopt EMV chip card technology, merchants must first clearly understand EMV’s requirements, timelines, and potential impacts on their business operations. Merchants should engage a POS provider to assess their options and develop a roadmap for migrating to an EMV-enabled payment system.
EMV Chip
2
AT A GLANCE PCI DSS DATA STORAGE
PCI DSS Data Storage Do’s and Don’ts Requirement 3 of the Payment Card Industry Data Security Standard (PCI DSS) is to “protect stored cardholder data.” The public expects that merchants and financial institutions will protect payment card data to thwart data theft and prevent unauthorized use. Requirement 3 addresses protection of stored cardholder data. Merchants who do not store any cardholder data automatically provide stronger protection by having eliminated a key target for data thieves. Remember if you don’t need it, don’t store it! For merchants who have a legitimate business reason to store cardholder data, it is important to understand what data elements PCI DSS allows them to store and what measures they must take to protect those data. In addition to PCI DSS requirements, PA-DSS and PTS require protection of stored cardholder data for payment applications and payment terminals. To prevent unauthorized storage, only PTS approved PIN entry devices and PA-DSS validated payment applications should be used. PCI DSS, PA-DSS and PTS compliance is enforced by the major payment card brands who established the PCI DSS and the PCI Security Standards Council: American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc. PCI SSC Founders
Basic Payment Card Data Storage Guidelines for Merchants Cardholder data refers to any information contained on a customer’s payment card. The data is printed on either side of the card and is contained in digital format on the magnetic stripe embedded in the backside of the card. Some payment cards store data in chips embedded on the front side. The front side usually has the primary account number (PAN), cardholder name and expiration date. The magnetic stripe or chip holds these plus other sensitive data for authentication and authorization. In general, no payment card data should ever be stored by a merchant unless it’s necessary to meet the needs of the business. Sensitive authentication data on the magnetic stripe or chip must never be stored. Only the PAN, expiration date, service code, or cardholder name may be stored, and merchants must use technical precautions for safe storage (see back of this fact sheet for a summary). The matrix below shows basic “do’s” and “don’ts” for data storage security. Data Do’s
Participating Organizations Merchants, Banks, Processors, Hardware and Software Developers and Point-of-Sale Vendors
Data Don’ts
Do understand where payment card data flows for the entire transaction process
Do not store cardholder data unless it’s absolutely necessary
Do verify that your payment card terminals comply with the PCI Personal Identification Number (PIN) Transaction Security (PTS) requirements
Do not store sensitive authentication data contained in a payment card’s chip or magnetic stripe, including the 3-4 digit card verification code or value printed on the front or back of the payment card, after authorization.
Do verify that your payment applications comply with the Payment Application Data Security Standard (PA-DSS)
Do not have payment terminals print out personally identifiable payment card data; printouts should be truncated or masked
Do retain (if you have a legitimate business need) cardholder data only if authorized, and ensure it’s protected
Do not store any payment card data in payment card terminals or other unprotected endpoint devices, such as PCs, laptops or smart phones
Do use strong cryptography to render unreadable cardholder data that you store, and use other layered security technologies to minimize the risk of exploits by criminals
Do not locate servers or other payment card system storage devices outside of a locked, fullysecured and access-controlled room
Do ensure that third parties who process your customers’ payment cards comply with PCI DSS, PTS and/or PA-DSS as applicable. Have clear access and password protection policies
Do not permit any unauthorized people to access stored cardholder data
Protect Stored Cardholder Data Use Encryption Encrypted data is unreadable and unusable to a system intruder without the proper cryptographic keys. See the PCI DSS Glossary for more information: www.pcisecuritystandards.org/ security_standards/glossary.php Use Other Measures Do not store cardholder data unless there is a legitimate business need; truncate or mask cardholder data if full PAN is not needed and do not send PAN in unencrypted emails, instant messages, chats, etc.. Use Compensating Controls as Alternatives
Technical Guidelines for Stored Payment Card Data PCI DSS Requirement 3 details technical and operational requirements for protecting stored cardholder data. Merchants should develop a data retention and storage policy that strictly limits storage amount and retention time to that which is required for business, legal, and/or regulatory purposes. Sensitive authentication data must never be stored after authorization – even if this data is encrypted. • Never store full contents of any track from the card’s magnetic stripe or chip (referred to as full track, track, track 1, track 2, or magnetic stripe data). If required for business purposes, the cardholder’s name, PAN, expiration date, and service code may be stored as long as they are protected in accordance with PCI DSS requirements. • Never store the card-validation code or value (three- or four-digit number printed on the front or back of a payment card used to validate card-not-present transactions). • Never store the personal identification number (PIN) or PIN Block. • Be sure to mask PAN whenever it is displayed. The first six and last four digits are the maximum number of digits that may be displayed. This requirement does not apply to those authorized with a specific need to see the full PAN, nor does it supersede stricter requirements in place for displays of cardholder data such as on a point-of-sale receipt.
Technical Guidelines for Payment Card Data Storage
If stored cardholder data cannot be encrypted or otherwise rendered unreadable, consult PCI DSS Appendix B: Compensating Controls and Appendix C: Compensating Controls Worksheet.
Cardholder Data Account Data
Verify 3rd Party Compliance Approved PTS Devices www.pcisecuritystandards.org/ approved_companies_providers/ approved_pin_transaction_security.php Validated Payment Applications www.pcisecuritystandards.org/ approved_companies_providers/ validated_payment_applications.php
Sensitive Authentication Data1
Data Element
Storage Permitted
Render Stored Account Data Unreadable per Requirement 3.4
Primary Account Number (PAN)
Yes
Yes
Cardholder Name
Yes
No
Service Code
Yes
No
Expiration Date
Yes
No
Full Magnetic Stripe Data2
No
Cannot store per Requirement 3.2
CAV2/CVC2/CVV2/CID
No
Cannot store per Requirement 3.2
PIN/PIN Block
No
Cannot store per Requirement 3.2
Sensitive authentication data must not be stored after authorization (even if encrypted)
[1]
Full track data from the magnetic stripe, equivalent data on the chip, or elsewhere.
[2]
Technical Guidelines for Protecting Stored Payment Card Data PCI DSS requires PAN to be rendered unreadable anywhere it is stored – including portable digital media, backup media, and in logs. Solutions for this requirement may include one of the following: • One-way hash functions based on strong cryptography – converts the entire PAN into a unique, fixed-length cryptographic value. • Truncation – permanently removes a segment of the data (for example, retaining only the last four digits). • Index tokens and securely stored pads – encryption algorithm that combines sensitive plain text data with a random key or “pad” that works only once. • Strong cryptography – with associated key management processes and procedures. Refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations and Acronyms for the definition of “strong cryptography.” Some cryptography solutions encrypt specific fields of information stored in a database; others encrypt a singular file or even the entire disk where data is stored. If full-disk encryption is used, logical access must be managed independently of native operating system access control mechanisms, and decryption keys must not be tied to user accounts. Encryption keys used for encryption of cardholder data must be protected against both disclosure and misuse. All key management processes and procedures for keys used for encryption of cardholder data must be fully documented and implemented. For more details, see PCI DSS Requirement 3. © 2010 PCI Security Standards Council LLC. The intent of this document is to provide supplemental information, which does not replace or supersede PCI SSC Security Standards or their supporting documents.
October 2010
Standard: PCI Data Security Standard (PCI DSS) Version:
3.0
Date:
August 2014
Author:
Third-Party Security Assurance Special Interest Group PCI Security Standards Council
Information Supplement:
Third-Party Security Assurance
Information Supplement • Third-Party Security Assurance • August 2014
Table of Contents 1
2 3
Introduction ........................................................................................................................................................ 1 1.1
Intended Use ................................................................................................................................................. 2
1.2
Terminology................................................................................................................................................... 2
1.3
Audience ....................................................................................................................................................... 2
Examples of Third-Party Service Providers .................................................................................................... 4 Third-Party Service Provider Due Diligence ................................................................................................... 5 3.1
Determining the Scope of the Services Provided ......................................................................................... 6
3.2 Due Diligence Research of the Third-Party Service Provider ....................................................................... 6 3.2.1 Acquirer/Payment Card Brands ............................................................................................................ 8
4
5
3.2.2
Third-Party Service Provider Validation Documentation ...................................................................... 8
3.2.3
Payment Card Brand Validated Providers Lists and Websites .......................................................... 11
3.3
Perform Risk Assessment ........................................................................................................................... 11
3.4
Documenting Results .................................................................................................................................. 14
Engaging the Third-Party Service Provider .................................................................................................. 15 4.1
Set Expectations ......................................................................................................................................... 15
4.2
Gain Transparency ...................................................................................................................................... 15
4.3
Establish Communications .......................................................................................................................... 16
4.4
Request Evidence ....................................................................................................................................... 16
4.5
Obtain Information about PCI DSS Compliance ......................................................................................... 16
4.6
Frequency of Review .................................................................................................................................. 17
4.7
Mapping of Third-Party Services to Applicable PCI DSS Requirements .................................................... 17
Written Agreements, Policies, and Procedures ............................................................................................ 19 5.1
Agreements between PCI DSS Compliant Third-Party Service Providers versus non-PCI DSS Compliant Third-Party Service Providers .................................................................................................... 19
5.2
Considerations when Building Agreements, Policies, and Procedures ...................................................... 20
5.3 Additional Considerations ........................................................................................................................... 22 5.3.1 Responsibility Matrix .......................................................................................................................... 22
6
5.3.2
Data Breaches .................................................................................................................................... 22
5.3.3
Post-termination Considerations Regarding TPSPs and Their Employees ....................................... 23
5.3.4
Outsourcing of Provided Functionality (Nested TPSPs) .................................................................... 23
5.3.5
Loss of Compliance Status ................................................................................................................. 24
Maintaining Relationships with and Monitoring Third-Party Service Providers ....................................... 25 6.1 Developing a Third-Party Service Provider Monitoring Program ................................................................ 25 6.1.1 Cardholder Data Environment (CDE) Scope Definition ..................................................................... 25 6.1.2
List of Third-Party Service Providers .................................................................................................. 26
6.1.3
Third-Party Service Provider Monitoring Procedure........................................................................... 26
6.2 Other Considerations .................................................................................................................................. 27 6.2.1 Third-Party Service Provider Does Not Provide Requested Information ........................................... 27 6.2.2
Third-Party Service Provider has not Validated PCI DSS Compliance.............................................. 28
This document is provided solely for informational purposes as a convenience to its readers. Information provided here does not replace or supersede the requirements of any PCI SSC Standard or the need for proper due diligence and appropriately qualified legal counsel.
i
i
Information Supplement • Third-Party Security Assurance • August 2014
6.2.3
Third-Party Service Provider Validates PCI DSS Compliance via Inclusion within the Entity’s PCI DSS Assessment ................................................................................................................................ 29
6.2.4
Existing or New Service or Process is not PCI DSS Compliant or will make the Entity or TPSP non-PCI DSS Compliant ..................................................................................................................... 30
Appendix A:
High-Level Discussion Points for Determining Responsibility ............................................... 31
Appendix B:
Sample PCI DSS Responsibility Matrix ..................................................................................... 40
Acknowledgement ................................................................................................................................................. 42 About the PCI Security Standards Council ......................................................................................................... 44
This document is provided solely for informational purposes as a convenience to its readers. Information provided here does not replace or supersede the requirements of any PCI SSC Standard or the need for proper due diligence and appropriately qualified legal counsel.
ii
i i
Information Supplement • Third-Party Security Assurance • August 2014
1 Introduction As entities work toward the goal of achieving and maintaining ongoing PCI DSS compliance, they may choose to leverage third-party service providers (TPSPs) to achieve their objectives. Entities can use a TPSP to store, process, or transmit cardholder data on the entity’s behalf, or to manage components of the entity’s cardholder data environment (CDE), such as routers, firewalls, databases, physical security, and/or servers. These TPSPs can become an integral part of the entity’s cardholder data environment and impact an entity’s PCI DSS compliance, as well as the security of the cardholder data environment. The use of a TPSP, however, does not relieve the entity of ultimate responsibility for its own PCI DSS compliance, or exempt the entity from accountability and obligation for ensuring that its cardholder data (CHD) and CDE are secure. Clear policies and procedures should therefore be established between the entity and its TPSP(s) for all applicable security requirements, and proper measures should be developed to manage and report on the requirements. A robust and properly implemented third-party assurance program assists an entity in ensuring that the data and systems it entrusts to TPSPs are maintained in a secure and compliant manner. Proper due diligence and risk analysis are critical components in the selection of any TPSP. This guidance focuses primarily on the following: Third-Party Service Provider Due Diligence: Thorough vetting of candidates through careful due diligence, prior to establishing a relationship, assists entities in reviewing and selecting TPSPs with skills and experience appropriate for the engagement. Service Correlation to PCI DSS Requirements: Understanding how the services provided by TPSPs correspond to the applicable PCI DSS requirements assists the entity in determining the potential security impact of utilizing TPSPs on the entity’s cardholder data environment. This information can also be used to determine and understand which of the PCI DSS requirements will apply to and be satisfied by the TPSP, and which will apply to and be met by the entity. Note: Ultimate responsibility for compliance resides with the entity, regardless of how specific responsibilities may be allocated between an entity and its TPSP(s). Written Agreements and Policies and Procedures: Detailed written agreements promote consistency and mutual understanding between the organization and its TPSP(s) concerning their respective responsibilities and obligations with respect to PCI DSS compliance requirements. Monitor Third-Party Service Provider Compliance Status: Knowing the TPSP’s PCI DSS compliance status helps to provide the organization engaging a TPSP with assurance and awareness about whether the TPSP complies with the applicable requirements for the services provided. If the TPSP offers a variety of services, this knowledge will assist the entity in determining which TPSP services will be in scope for the entity’s PCI DSS assessment.
This document is provided solely for informational purposes as a convenience to its readers. Information provided here does not replace or supersede the requirements of any PCI SSC Standard or the need for proper due diligence and appropriately qualified legal counsel.
1
Information Supplement • Third-Party Security Assurance • August 2014
2 Examples of Third-Party Service Providers Below are examples of types of services and providers with which an entity may work:
Organizations involved in the storage, processing, and/or transmission of cardholder data (CHD). Thirdparty service providers in this category may include:
Call centers
E-commerce payment providers
Organizations that process payments on behalf of the entity, such as a partner or reseller
Fraud verification services, credit reporting services, collection agencies
Third-party processors
Entities offering processing-gateway services
Organizations involved in securing cardholder data. TPSPs in this category may include:
Companies providing secure destruction of electronic and physical media
Secure storage facilities for electronic and physical media
Companies that transform cardholder data with tokenization or encryption
E-commerce or mobile-application third parties that provide software as a service
Key-management providers such as key-injection services or encryption-support organizations (ESO)
Organizations involved in the protection of the cardholder data environment (CDE). TPSPs in this category may include:
Infrastructure service providers
Managed firewall/router providers
Secure data-center hosting providers
Monitoring services for critical security alerts such as intrusion-detection systems (IDS), antivirus, change-detection, compliance monitoring, audit-log monitoring, etc.
Organizations that may have incidental access to CHD or the CDE. Incidental access is access that may happen as a consequence of the activity or job. TPSPs in this category may include:
Providers of managed IT delivery channels and services
Companies providing software development, such as web applications
Providers of maintenance services
This document is provided solely for informational purposes as a convenience to its readers. Information provided here does not replace or supersede the requirements of any PCI SSC Standard or the need for proper due diligence and appropriately qualified legal counsel.
4
Understanding the SAQs for PCI DSS version 3 The PCI DSS self-assessment questionnaires (SAQs) are validation tools intended to assist merchants and service providers report the results of their PCI DSS self-assessment. The different SAQ types are shown in the table below to help you identify which SAQ best applies to your organization. Detailed descriptions for each SAQ are provided within the applicable SAQ. Note: Entities should ensure they meet all the requirements for a particular SAQ before using the SAQ. Merchants are encouraged to contact their merchant bank (acquirer) or the applicable payment brand(s) to identify the appropriate SAQ based on their eligibility.
SAQ A
A-EP*
B
Description Card-not-present merchants (e-commerce or mail/telephone-order) that have fully outsourced all cardholder data functions to PCI DSS validated third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Not applicable to face-to-face channels. E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Applicable only to e-commerce channels. Merchants 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*
Merchants 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-VT
Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual 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.
C
P2PE-HW
D
Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels. Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage. Not applicable to e-commerce channels. SAQ D for Merchants: All merchants not included in descriptions for the above SAQ types. SAQ D for Service Providers: All service providers defined by a payment brand as eligible to complete a SAQ.
* New for PCI DSS v3.0
The intent of this document is to provide supplemental information. Information provided here does not replace or supersede PCI SSC Security Standards or their supporting documents. © 2014-2015 PCI Security Standards Council, LLC. All Rights Reserved.
Page 1
Information Supplement • Understanding SAQs for PCI DSS Version 3 • April 2015
What’s new in version 3 of the SAQs? The format of the self-assessment questionnaire (SAQs) has been updated in version 3 to provide more guidance and reporting information for each PCI DSS requirement. A new column titled “Expected Testing” describes the testing activities to be performed during the selfassessment, to help the entity determine whether a requirement has been met. The “Special” column from version 2 has been replaced with two separate columns in version 3: “Yes with CCW” (compensating control worksheet) and “N/A.” These updated response options help entities to more clearly identify which response to use for each requirement. The orientation of the SAQs has changed from portrait to landscape to accommodate these additional columns. There is also additional guidance provided at the beginning of the SAQs to assist with understanding how to complete the SAQ. The sections within the SAQ documents have been reorganized, such that Parts 3 and 4 of the AOC now follow the questionnaire portion of the SAQ. This is to ensure that an entity’s attestation encompasses all elements of the SAQ and AOC. Additional guidance and information about SAQ format is provided in the “Before you Begin” section of each SAQ.
How will the SAQ updates impact my organization? With PCI DSS version 3, there are new SAQs as well as updated eligibility criteria for existing SAQs, and organizations will need to review the eligibility criteria to understand which SAQ may now be right for them. For example, one of the new SAQs may be better aligned with an organization’s particular environment than the SAQ used previously. Similarly, an organization that previously completed one type of SAQ will need to review the criteria for that particular SAQ to determine whether it is still appropriate for their environment. The SAQ updates for version 3 may also mean that a merchant may need to validate additional requirements, which could impact how the merchant approaches their self-assessment. Even where the eligibility criteria have not changed for a particular SAQ, the SAQ may include different PCI DSS requirements in version 3 than in version 2. The questions in each SAQ have been updated to reflect changes made to PCI DSS version 3. For example, some complex requirements have been broken down into sub-requirements, and other requirements may have been clarified or extended, resulting in updated questions in the SAQs. Merchants should continue to choose an applicable SAQ based upon the defined eligibility criteria for each SAQ, and according to instructions from their acquirer or payment brand(s).
The intent of this document is to provide supplemental information. Information provided here does not replace or supersede PCI SSC Security Standards or their supporting documents. © 2014-2015 PCI Security Standards Council, LLC. All Rights Reserved.
Page 2
Information Supplement • Understanding SAQs for PCI DSS Version 3 • April 2015
What are the new SAQs for PCI DSS version 3? SAQ A-EP is a new SAQ for e-commerce merchants who outsource their transaction-processing functions to PCI DSS compliant third-party service providers, where the merchant website controls how the cardholder data is redirected to the third-party service provider. To be eligible for this SAQ, the merchant must not store, process, or transmit cardholder data on any of their systems or premises. SAQ B-IP is a new SAQ for merchants who process cardholder data only via standalone, PTSapproved point-of-interaction (POI) devices that have an IP connection to their payment processor, and do not electronically store cardholder data. To be eligible for this SAQ, the merchant must be using payment terminals that are currently listed on the PTS List of Approved POI Devices (https://www.pcisecuritystandards.org/approved_companies_providers/approved_pin_transaction_sec urity.php). Note that the Secure Card Reader (SCR) class of POI devices does not meet the criteria for SAQ B-IP, and thus merchant using SCRs are not eligible for this SAQ. SAQ B-IP is not applicable to e-commerce channels.
What is the intent of SAQ A-EP? SAQ A-EP has been developed to differentiate between merchants that have partially outsourced management of their e-commerce transactions, and merchants that have completely outsourced all management of their e-commerce environment (SAQ A merchants). As with SAQ A, SAQ A-EP merchants do not electronically store, process, or transmit any cardholder data on their systems or premises, but rely entirely on a third party(s) to handle these functions. All processing of cardholder data is outsourced to a PCI DSS validated third-party payment processor for both SAQ A and SAQ A-EP. Prior to the release of SAQ A-EP, many e-commerce merchants with web sites that impacted the security of payment transactions may have felt they were eligible for SAQ A because their web server does not store, process, or transmit cardholder data. As a result, these web servers did not have sufficient security controls applied to them and have become common targets for attackers as a means to compromise cardholder data. SAQ A-EP is intended to identify the controls needed to secure merchant web sites that control or manage the payment transaction, and reduce the likelihood a breach of the web site can be used to compromise cardholder data.
The intent of this document is to provide supplemental information. Information provided here does not replace or supersede PCI SSC Security Standards or their supporting documents. © 2014-2015 PCI Security Standards Council, LLC. All Rights Reserved.
Page 3
Information Supplement • Understanding SAQs for PCI DSS Version 3 • April 2015
How does SAQ A-EP compare to SAQ A? The following table provides a high-level overview of some of the key similarities and differences between SAQ A and SAQ A-EP.
Applies to:
Functions Outsourced
Payment Pages
SAQ A
SAQ A-EP
All Cardholder Data Functions Completely Outsourced
Partially Outsourced E-commerce Payment Channel
Card-not-present merchants (e-commerce or mail/telephone-order)*
E-commerce merchants
All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers
All processing of cardholder data, with the exception of the payment page, is entirely outsourced to a PCI DSS validated third-party payment processor
All elements of all payment pages delivered to the consumer’s browser originate only and directly from a PCI DSS validated third-party service provider(s)
Each element of the payment page(s) delivered to the consumer’s browser originates from either the merchant’s website or a PCI DSS compliant service provider(s)
Third-Party Compliance
Merchant confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant
Merchant Systems
Merchant does not electronically store, process, or transmit any cardholder data on their systems or premises, but relies entirely on a third party(s) to handle all these functions
Data Retention
Merchant retains only paper reports or receipts with cardholder data, and these documents are not received electronically
* Criteria for SAQ A mail/telephone order (MOTO) channels are not included in this comparison. This table is intended to provide a comparison between SAQ A and SAQ A-EP and does not supersede or replace the eligibility criteria for either SAQ.
The intent of this document is to provide supplemental information. Information provided here does not replace or supersede PCI SSC Security Standards or their supporting documents. © 2014-2015 PCI Security Standards Council, LLC. All Rights Reserved.
Page 4
Information Supplement • Understanding SAQs for PCI DSS Version 3 • April 2015
What types of e-commerce implementations are eligible for SAQ A-EP vs. SAQ A? To be eligible for SAQ A, e-commerce merchants must meet all eligibility criteria detailed in SAQ A, including that there are no programs or application code that capture payment information on the merchant website. Examples of e-commerce implementations addressed by SAQ A include: •
Merchant has no access to their website, and the website is entirely hosted and managed by a compliant third-party payment processor
•
Merchant website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process.
•
Merchant website contains a URL link redirecting users from merchant website to a PCI DSS compliant third-party processor facilitating the payment process.
If any element of a payment page delivered to consumers’ browsers originates from the merchant’s website, SAQ A does not apply; however, SAQ A-EP may be applicable. Examples of e-commerce implementations addressed by SAQ A-EP include: •
Merchant website creates the payment form, and the payment data is delivered directly from the consumer browser to the payment processor (often referred to as “Direct Post”).
•
Merchant website loads or delivers script that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.
What is the intent of SAQ B-IP? SAQ B-IP has been developed to differentiate between merchants using only standalone payment terminals that connect to their payment processors via an IP-based connection, from merchants who connect to their payment processor using only dial-out connections (which may meet the criteria of SAQ B). To be eligible for SAQ B-IP, merchants must be using payment terminals that have been approved under the PCI PTS program and are listed on the PCI SSC website as approved devices. Note that merchants using the Secure Card Reader (SCR) category of devices are NOT eligible for SAQ B-IP. Other eligibility criteria for SAQ B-IP include that the approved devices are segmented from other systems within the environment, and the devices do not rely on any other device (e.g., computer, mobile phone, tablet, etc.) to connect to the payment processor. Additionally, to be eligible for SAQ BIP, the only permitted transmission of cardholder data is from the PTS-approved device to the payment processor, and the merchant must not store cardholder data in electronic format. SAQ B-IP, like SAQ B, is not applicable to e-commerce channels. Prior to the release of SAQ B-IP, merchants with this type of environment may have needed to complete SAQ C or SAQ D. These merchants may now be eligible to use SAQ B-IP, which may be better suited for their particular environment and provides a simpler validation than SAQ C.
The intent of this document is to provide supplemental information. Information provided here does not replace or supersede PCI SSC Security Standards or their supporting documents. © 2014-2015 PCI Security Standards Council, LLC. All Rights Reserved.
Page 5
Information Supplement • Understanding SAQs for PCI DSS Version 3 • April 2015
How does SAQ B-IP compare to SAQ B? The following table provides a high-level overview of some of the key similarities and differences between SAQ B and SAQ B-IP.
SAQ B Imprint machines or standalone, dial-out terminals Applies to:
SAQ B-IP Standalone, PTS-approved payment terminals with an IP connection
Brick-and-mortar (card-present) or mail/telephone order (card-not-present) merchants
Payment Terminals
Standalone, dial-out terminal (connected via a phone line to the processor)
Standalone, PTS-approved point-ofinteraction (POI) devices (excludes SCRs) connected via IP to the payment processor
CHD Transmissions
CHD is not transmitted over a network (either an internal network or the Internet)
Only CHD transmission is via IP from the PTS-approved POI devices to the payment processor
Merchant Systems
Merchant does not does not store cardholder data in electronic format
Data Retention
Merchant retains only paper reports or receipts with cardholder data, and these documents are not received electronically
This table is intended to provide a comparison between SAQ B and SAQ B-IP, and does not supersede or replace the eligibility criteria for either SAQ.
The intent of this document is to provide supplemental information. Information provided here does not replace or supersede PCI SSC Security Standards or their supporting documents. © 2014-2015 PCI Security Standards Council, LLC. All Rights Reserved.
Page 6
