PCI DSS 3.2 compliance guide

Everything you need to know about PCI DSS 3.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

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

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

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.


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
Imprint machines or standalone, dial-out terminals
Not an Adyen Solution
SAQ B-IP
Standalone PTS-approved payment terminals with an IP connection
Applies to none none
Payment Terminals SAQ A v3.1 SAQ A v3.2
Cardholder Data Transmissions SAQ A v3.1 SAQ D Merchant v3.2 & network scan or certificate from QSA

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.

Some of these requirements are applicable to merchants as follows:

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 Sub-merchant.
  • Educate and train Submerchants to ensure compliance with the Standards.
  • Maintain names, addresses, and URLs if applicable of Sub-merchants.
  • Timely pay Sub-merchants for Transactions.
  • Supply Sub-merchants 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.

Notes:

  • 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:

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.

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
Level 1 Service Provider Store, process and/or transmit over over 300,000 transactions per year RoC (Report of Compliance) by QSA or an AoC (Attestation of
Compliance) by QSA
Level 2 Service Provider Store, process and/or transmit less than 300,000 transactions per year SAQ D Service Provider v3.2 and 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 for PCI DSS 3.2

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.

Some of the 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

A1: System components (people, processes, and technologies) that do any of the following:

  • Store, process or transmit Cardholder Data (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

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

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.

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

A6: Any company that:

  • Meets PCI DSS requirements for you or
  • You share Cardholder Data with or
  • Could impact your Cardholder Environment

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

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.

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

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.

A11: Combination of secure devices, applications, and processes that encrypt data from the point of interaction to the solution providers secure decryption environment.

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

A13: Adyen is a PCI DSS 3.2-certified Level 1 Service Provider.

Additional to v3.2

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).
  • Damage to reputation.

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

Want to talk to a payments expert?