Adyen PCI DSS 3.2 Compliance Guide

December 2016 Version 1.2

Disclaimer: This document is for guidance purposes only. Adyen does not accept responsibility for any inaccuracies. Merchants should always consult their acquirer for clarification.

AN INTRODUCTION TO PCI DSS ...... 4 PCI SSC ...... 4 Adhering to the PCI DSS ...... 4 Security and operational implications ...... 4 General PCI DSS goals and requirements ...... 5 ADYEN PCI DSS 3.2 REQUIREMENTS FOR MERCHANTS ...... 6 Card Not Present ...... 6 Adyen CSE requires an SAQ A ...... 6 Card Present ...... 6 Card Present, which SAQ to use? ...... 7 New requirements ...... 7 Changes to applicable SAQs ...... 7 ADYEN PCI DSS 3.2 REQUIREMENTS FOR SERVICE PROVIDERS ...... 9 New requirements ...... 11 FAQ ...... 12 Q1: What is in scope? ...... 12 Q2: What is NOT in scope? ...... 12 Q3: What is “connected to”? ...... 12 Q4: What is Segmentation? ...... 12 Q5: Do PCI DSS controls reduce scope? ...... 12 Q6: What is a Service Provider? ...... 12 Q7: Does outsourcing solve my PCI Compliance effort? ...... 12 Q8: What is PTS POI? ...... 13 Q9: Does a PTS-approved device solve my PCI Compliance effort? ...... 13 Q10: What is SRED? ...... 13 Q11: What is a P2PE solution? ...... 13 Q12: Is Adyen a Payment Application? ...... 13 Q13: What PCI certification does Adyen have? ...... 13 Q14: What is a Qualified Integrator & Reseller? ...... 13 Consequences of non-compliance ...... 13 Acronyms/Glossary ...... 14 Resources ...... 14

AN INTRODUCTION TO PCI DSS

PCI DSS is the global data security standard adopted by the card schemes for all entities that process, store or transmit cardholder data and/or sensitive authentication data. It consists of steps that mirror security best practices. When your company starts accepting credit cards via an API connection, compliance with the PCI DSS requirements is mandatory.

PCI SSC PCI Security Standards are technical and operational requirements set by the PCI Security Standards Council (PCI SSC) to protect cardholder data. The PCI Security Standards Council is an open global forum, launched in 2006, that is responsible for the development, management, education, and awareness of the PCI Security Standards. The Council's five founding global payment brands – American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. – have agreed to incorporate the PCI DSS as the technical requirements of each of their data security compliance programs. In this paper you'll find useful information about the PCI DSS requirements for merchants and the Council's certification, created to mitigate data breaches and prevent payment cardholder data fraud.

Adhering to the PCI DSS From the world's largest corporations to small Internet stores, compliance with the PCI Data Security Standard (PCI DSS) is vital for all merchants who accept credit cards, online or offline, because nothing is more important than keeping your customer’s payment card data secure. The size of your business will determine the specific compliance requirements that must be met.

There are three steps for adhering to the PCI DSS – which is not a single event, but a continuous, ongoing process. • Assess – identify cardholder data, take an inventory of your IT assets and business processes for payment card processing, and analyze them for vulnerabilities that could expose cardholder data. • Remediate – fix vulnerabilities and do not store cardholder data unless you need it. • Report – compile and submit required remediation validation records (if applicable), and submit compliance reports to the acquiring bank and card brands you do business with.

Security and operational implications In security terms, it means that your business adheres to the PCI DSS requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. In operational terms, it means that you are playing your role to make sure your customers' payment card data is being kept safe throughout every transaction, and that they – and you – can have confidence that they're protected against the pain and cost of data breaches.

General PCI DSS goals and requirements

Table 1 PCI DSS goals and requirements

Goals PCI DSS Requirements

1. Install and maintain a firewall configuration to Build and Maintain a Secure Network and protect Cardholder Data Systems 2. Do not use vendor-supplied defaults for system passwords and other security parameters 3. Protect stored Cardholder Data Protect Cardholder Data 4. Encrypt transmission of Cardholder Data across open, public networks 5. Protect all systems against malware and regularly update anti-virus software or programs Maintain a Vulnerability Management Program 6. Develop and maintain secure systems and applications 7. Restrict access to Cardholder Data by business need to know Implement Strong Access Control Measures 8. Identify and authenticate access to system components 9. Restrict physical access to Cardholder Data 10. Track and monitor all access to network resources Regularly Monitor and Test Networks and Cardholder Data 11. Regularly test security systems and processes 12. Maintain a policy that addresses information security Maintain an Information Security Policy for all personnel

Depending on your payment channels and the way that Card Holder Data is processed, some PCI DSS requirements may not be applicable to you.

ADYEN PCI DSS 3.2 REQUIREMENTS FOR MERCHANTS

Card Not Present The PCI DSS 3.1 standard has expired on October 31, 2016. Merchants are expected to have adhered to PCI DSS 3.2 beginning November 1, 2016. In accordance with PCI SSC guidelines, new validation efforts starting from that date will be to PCI DSS v3.2. Adyen will validate merchants’ compliance with PCI DSS v3.2 by asking for new documentations for v3.2. The table below shows the requirements for PCI DSS 3.2 for each Adyen integration method.

Table 2 Card Not Present SAQ Guide

Connection Method/Channel until October 31, 2016 after October 31, 2016 HPP / E-commerce none none CSE / E-commerce & MOTO SAQ A v3.1 SAQ A v3.2 API / E-commerce & MOTO SAQ A v3.1 SAQ D Merchant v3.2 & network scan or certificate from QSA

Important: For merchants with more than one channel, several SAQ's may be applicable. Adyen recommends that merchants should tackle PCI compliance per channel, per legal entity and in case of questions reach out to a PCI Qualified Security Assessor. https://www.pcisecuritystandards.org/approved_companies_providers/qualified_security_assessors.php

Adyen CSE requires an SAQ A An aim of the PCI DSS 3.2 is to ensure that the browser that sends encrypted payment data is securely sent to the Adyen payment platform (and not another recipient). Since the encryption key that is provided by Adyen to the CSE merchant cannot be used to decrypt the Cardholder Data, and the decryption key is never available to the merchant or the shopper, the primary concern is to ensure the integrity of the merchant website’s assets and not to protect Cardholder Data, which is never available there as all Cardholder Data functions are outsourced. Adyen does offer the option of hosted CSE Javascript where the merchant requires this to avoid even having the encryption keys in their environment.

However, please note that compliance for the Adyen CSE solution does not require the following: • Constant maintenance • An on-site visit by a Qualified Security Assessor (QSA) • A quarterly network scan by an Approved Scanning Vendor (ASV)

Card Present Network segmentation is critical to the impact of the PCI requirements related to Card Present environment.

Table 3 Card Present SAQ Guide

Connection Method/Channel until October 31, 2016 after October 31, 2016 POS / mPOS SAQ B-IP v3.1 SAQ B-IP v3.2

Important: For merchants with more than one channel, several SAQ's may be applicable. Adyen recommends that merchants tackle PCI compliance per channel, per legal entity and in case of questions reach out to a PCI Qualified Security Assessor.

Card Present, which SAQ to use?

SAQ B SAQ B-IP Imprint machines or standalone, Standalone PTS-approved payment dial-out terminals terminals with an IP connection Not an Adyen Solution

Brick-and-mortar (Card-Present) or Applies to Mail/telephone order (Card-Not-Present) Merchants

Standalone, PTS-approved point-of- Standalone, dial-out terminal interaction (POI) devices (excludes Payment Terminals (connected via a phone line to the SCRs) connected via IP to the processor) payment processor Only Encrypted Cardholder Data Cardholder Data is not transmitted transmission is via IP from the PTS- Cardholder Data Transmissions over a network (either an internal approved POI devices to the network or the Internet) payment processor

6.4.6: New requirement for change control processes to include verification of PCI DSS requirements impacted by a change. 8.3.1: Addresses multi-factor authentication for all personnel with non-console administrative access to the CDE.

Changes to applicable SAQs SAQ A Part 2f Registration of the use of a Qualified Integrator & Reseller = integrators and resellers qualified to assist merchants and industry participants in their effort to install PA-DSS validated payment applications in a

manner that facilitates PCI DSS compliance.

Section 2: Self-Assessment Questionnaire New requirements: • Requirement 2: Additional questions in relation to not using vendor-supplied defaults for system passwords and other security parameters. • Requirement 8: Additional questions in relation to identify and authenticate access to system components. • Requirement 12: Additional question 12.10.1 on the incident response plan.

SAQ D

New questions: • 6.4.6: Upon completion of a significant change, are all relevant PCI DSS requirements implemented on all new or changed systems and networks, and documentation updated as applicable? • 8.3.1: Is multi-factor authentication incorporated for all non- console access into the CDE for personnel with administrative access? • 8.3.2: Is multi-factor authentication incorporated for all remote network access (both user and administrator, and including third party access for support or maintenance) originating from outside the entity’s network? • 10.9: Are security policies and operational procedures for monitoring all access to network resources and cardholder data documented, in use and known to all affected parties?

ADYEN PCI DSS 3.2 REQUIREMENTS FOR SERVICE PROVIDERS

For the purpose of this guide, Service Providers are defined as third parties that work with merchants and process, store, or transmit cardholder data and/or sensitive authentication data (see also Q6 in FAQ).

MASTERCARD MasterCard has recognized seven categories of Service Providers: • Independent Sales Organization (ISO); • Third Party Processor (TPP); • Data Storage Entity (DSE); • Payment Facilitator (PF); • Digital Wallet Operator (DWO); • Digital Activity Service Provider (DASP); and • Service Provider Registration Facilitator (SPRF).

A Service Provider is categorized by the Schemes based upon their services provided to merchants.

Independent Sales Organization (ISO) Program Service: • Cardholder and/or Merchant Solicitation, including application processing. • Cardholder and/or Merchant customer service not affording access to Account data, Transaction data, or both, including the collection of any fee or other obligation associated with the Customer’s Program. • Cardholder and/or Merchant statement preparation not affording access to Account or Transaction data. • Merchant education and training. • Terminal deployment, not including ATM Terminal deployment by an ATM Terminal owner that does not perform any other type of ISO Program Service. • Any other service determined by the Corporation in its sole discretion to be ISO Program Service.

Third Party Processor (TPP) Program Service: • Terminal operations with electronic data capture deployment. • Authorization services, including but not limited to authorization routing, payment gateway and switching services, voice authorization, and call referral processing. • Clearing file preparation and submission. • Settlement processing (excluding possession, ownership, or control of settlement funds, which is not permitted). • Cardholder and/or Merchant statement preparation affording access to Account data, Transaction data, or both. • Cardholder customer service affording access to Account data, Transaction data, or both. • Fraud control and risk monitoring, including but not limited to fraud screening and fraud scoring services. • Chargeback processing. • Any other service determined by the Corporation in its sole discretion to be TPP Program Service.

Data Storage Entity (DSE) Program Service: Any service affording access to Account or Transaction data and not identified by the Corporation as TPP Program Service, including but not limited to: • Merchant website hosting or other service involving the computer-based storage of Account or Transaction data. • External hosting of payment applications, such as website shopping carts. • Terminal servicing. • Encryption key loading.

Payment Facilitator (PF) Program Service: • Submit to the Acquirer records of valid Transactions submitted to the Payment Facilitator by a Submerchant. • Educate and train Submerchants to ensure compliance with the Standards. • Maintain names, addresses, and URLs if applicable of Submerchants. • Timely pay Submerchants for Transactions. • Supply Submerchants with all materials necessary to effect Transactions. • Monitor the Activity and use of the Marks of each Submerchant for purposes of deterring fraudulent and other wrongful activity.

Digital Wallet Operator (DWO) Program Service: • Operates and offers to consumers a Pass-through Digital Wallet. • Operates and offers to consumers a Staged Digital Wallet.

Digital Activity Service Provider (DASP) Program Service: • Account Enablement System • Credentials Management System • Transaction Management System • Trusted Service Manager • Any other service specified by the Corporation in its discretion from time to time to be DASP Program.

Service Provider Registration Facilitator (SPRF) Program Service: • Identification of entities the Standards obligate a Customer to register as a Service Provider. • Assisting a Customer to register Service Providers other than SPRFs.

Mastercard requires all service providers to be PCI-compliant. All TPPs are considered Level 1 Service Providers. Data Storage Entities (DSEs) are categorized as Level 1or Level 2 Service Providers based on annual Mastercard transaction volume.

VISA

Visa has recognized two categories of Service Providers: 1. Merchant Agents: Agents that directly or indirectly store, process, or transmit card or account data on behalf of a Merchant. Merchant Agents usually have a contract in place with the Merchant

to provide these services. 2. Member Agents: Agents who provide payment related services, to or on behalf of a Visa Europe Member, which includes directly or indirectly storing, processing, or transmitting card or account data. Member Agents must have a contract in place with the Member to provide these services.

With Visa, PCI DSS validation is the same for all third party agents that store, process, or transmit card or account data.

Adyen requires service providers to be PCI DSS 3.2-compliant. Service providers are classified into two different levels according to their annual transaction volume. As such, the requirements for service providers to comply with PCI DSS 3.2 are summarized below:

Table 4 Service Providers Compliance Guide

Level Criteria Requirements RoC (Report of Compliance) by QSA Store, process and/or transmit over Level 1 Service Provider or an AoC (Attestation of 300,000 transactions per year Compliance) by QSA Store, process and/or transmit less SAQ D Service Provider v3.2 and Level 2 Service Provider than 300,000 transactions per year quarterly network scan by ASV

In many cases, service providers help Adyen connect with merchants (referred to as sub-merchants) using the connection methods offered by Adyen. Depending on their connection methods, Adyen may still require them to fill out SAQ as applicable. In this case, the requirements set forth in Table 2 apply.

New requirements PCI DSS 3.2 also comes with new requirements that are framed as “best practices” until January 31, 2018 and will become effective as requirements starting February 1, 2018. Several of these requirements are applicable to service providers as follows: • 3.5.1: New requirement for service providers to maintain a documented description of the cryptographic architecture. • 10.8.1: New requirement for service providers to detect and report on failures of critical security control systems. • 11.3.4.1: New requirement for service providers to perform penetration testing on segmentation controls at least every six months. • 12.4: New requirement for service providers’ executive management to establish responsibilities for the protection of cardholder data and a PCI DSS compliance program. • 12.11.1: New requirement for service providers to perform reviews at least quarterly, to confirm personnel are following security policies and operational procedures.

FAQ Q1: What is in scope? A1: System components (people, processes, and technologies) that do any of the following: • Store, process or transmit Cardholder Data (a.k.a. the Cardholder Environment) • Connect to the Cardholder Environment • Provide security services to the Cardholder Environment • Provide segmentation of the Cardholder Environment • Could otherwise impact security of Cardholder Data

Q2: What is NOT in scope? A2: System components that: • Do not store, process or transmit Cardholder Data, and • Do not connect to the Cardholder Environment, and • Do not provide security services to the Cardholder Environment, and • Do not provide segmentation of the Cardholder Environment, and • Cannot otherwise impact security of Cardholder Data

Q3: What is “connected to”? A3: Communication to and/or from the Cardholder Environment

Q4: What is Segmentation? A4: Isolating the Card Holder Data Environment from the rest of the network via logical or physical means. Controlled access is not segmentation. Out of scope = security is not reviewed = untrusted.

Without adequate network segmentation, the entire network is in scope of the PCI DSS assessment. Segmentation is strongly recommended as a method that may reduce not only the scope and cost of a PCI DSS assessment, but also the ongoing overhead of maintaining PCI DSS compliance. By consolidating cardholder data into fewer, more controlled locations, the risk of data breach may also be reduced.

Q5: Do PCI DSS controls reduce scope? A5: A system is “in scope” due to its function and/or network connectivity and implementing PCI DSS controls does not change that.

Q6: What is a Service Provider? A6: Any company that: • Meets PCI DSS requirements for you or • You share Cardholder Data with or • Could impact your Cardholder Environment

Q7: Does outsourcing solve my PCI Compliance effort? A7: No, responsibility cannot be fully outsourced. • Outsourcing may reduce complexity of implementing PCI DSS controls • Outsourcing may increase oversight and validation complexity • Merchant still responsible for customer's data

Q8: What is PTS POI? A8: PTS = PIN Transaction Security. A PTS-approved POI incorporates hardware, firmware, and applications that are evaluated and included on the List of Approved PTS devices for that POI.

Q9: Does a PTS-approved device solve my PCI Compliance effort? A9: A PTS-approved device: • Can facilitate PCI DSS compliance • Does not guarantee PCI DSS compliance or reduce PCI DSS scope • Is in scope for PCI DSS to confirm it is configured properly and that secure functionality has not been disabled

Q10: What is SRED? A10: SRED stands for secure reading and exchange of data. SRED devices provide secure encryption of account data by covering data from point of contact to point of output. PCI PTS devices with SRED can be used in validated PCI P2PE solutions.

Q11: What is a P2PE solution? A11: Combination of secure devices, applications, and processes that encrypt data from the point of interaction to the solution providers secure decryption environment.

Q12: Is Adyen a Payment Application? A12: No, Adyen is not a Payment Application in terms of PCI DSS. Adyen is a Payment Service Provider.

Q13: What PCI certification does Adyen have? A13: Adyen is a PCI DSS 3.2-certified Level 1 Service Provider.

Additional to v3.2 Q14: What is a Qualified Integrator & Reseller? A14: These are integrators and resellers qualified to assist merchants and industry participants in their effort to install PA-DSS validated payment applications in a manner that facilitates PCI DSS compliance.

Consequences of non-compliance Enforcement of compliance with the PCI DSS and determination of any non-compliance penalties are carried out by the individual card schemes. However, potential consequences include the following: • If a merchant is found to be non-compliant they can be fined up to $25,000 per month. • Additionally, they are susceptible to huge fines if a breach occurs – up to five- or six-figure amounts. • Breach costs have been estimated to be between $100 and $300 per breached record (card number). • Reputational damage.

Acronyms/Glossary

AOC Attestation of Compliance ASV PCI Accredited Scanning Vendor CHD Cardholder Data, including PANs, expiry dates, shopper names, SAD CDE Cardholder Data Environment CSE Client-Side Encryption MOTO Mail order/Telephone order PCI Payments Card Industry PCI DSS Payments Card Industry Data Security Standard QSA PCI DSS Qualified Security Assessor ROC Report on Compliance SAD Sensitive Authentication Data – CVV, CVV2 etc SAQ PCI DSS Self Assessment Questionnaire

Resources The following documents, freely downloadable from the Document Library of the PCI SSC Council Website, can help gain a better understanding of what is expected from you:

PCI DSS Summary of Changes (v3.1 to v3.2)

PCI DSS Quick Resource Guide

SAQ Instructions and Guidelines