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 or PCI Qualified Security Assessor (QSA) 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 card payments, compliance with the PCI DSS requirements is mandatory.


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.

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

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 cardholder data is processed, some PCI DSS requirements may not be applicable to you.

Adyen PCI DSS 3.2 validation requirements for merchants

Adyen has different validation requirements for different integration methods.

Card-Not-Present validation requirements

The table below shows the required PCI DSS validation documentation for each Adyen integration method for card-not-present channel. Note that these validation requirements are based on Adyen’s acceptable risk profile for each integration method and may differ from what is required by other acquirers.

Connection Method/Channel  
HPP / E-commerce none
Checkout (secured fields)/E-commerce & in-app SAQ A or equivalent
CSE / E-commerce & MOTO SAQ A or equivalent
API / E-commerce & MOTO SAQ D for merchants or equivalent, and quarterly vulnerability scan from ASV

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.

Card-Present validation requirements

Although you are always required to comply with PCI DSS, Adyen does not require you to send validation documentation if you are not processing more than 1 million card transactions per year. The table below shows the required PCI DSS validation documentation for each Adyen integration method for card-not-present channel.

Connection Method  

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.

Card-Present, which SAQ to use?

Imprint machines or standalone, dial-out terminals
Not an Adyen Solution
Standalone PTS-approved payment terminals with an IP connection
Applies to 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-of-interaction (POI) devices (excludes SCRs) connected via IP to the payment processor
Cardholder Data Transmissions Cardholder data is not transmitted over a network (either an internal network or the Internet) Only encrypted cardholder data transmission is done via IP from the PTS-approved POI devices to the payment processor

Get in touch with your Adyen contact person to learn how the Adyen POS solution impacts the scope of your PCI DSS requirements.

Adyen Checkout

Adyen’s Checkout solution provides a highly secured payment solution for merchants to accept credit card payments from shoppers while outsourcing many of the requirements for PCI DSS to Adyen. Checkout complies fully with PCI SSC requirements for ‘strong cryptography’.

Checkout is, at its core, an iframe method which seamlessly embeds several components of the Adyen payments interface within a larger page provided by the merchant all together in a web page on the shopper browser, and where the shopper enters all the cardholder data only within the Adyen iframes.

Cardholder data is not collected, stored, processed or transmitted by the merchant. In more detail:

  • Cardholder data is only entered on page elements served from Adyen, wrapped in iframes on the shopper browser, and is never exposed to the merchant’s ecommerce environment.
  • The encrypted cardholder data is sent directly to Adyen, without ever touching the merchant’s ecommerce environment.
  • The Adyen-hosted iframes can only be presented to the shopper if the merchant has initiated a payment session server side (because of the signature calculation and check).
  • All communications between Adyen, the merchant and the shopper use TLS, and all cryptographic operations in use by all components of the Adyen Checkout solution adhere to PCI Security Standards Council definitions of ‘strong cryptography’.

Adyen Checkout was designed to follow PCI SSC guidelines around iframe implementations, and does not deviate from more general industry approaches except where specific implementation choices allow lower risk to cardholder data.

Adyen CSE

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 (including contents and codes) 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.

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)

Want to talk to a payments expert?

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 v3.2 Rev 1.1 (January 2017 version)


Clarification for PCI DSS Requirements that address the protection of computer systems (for example, Requirements 2 and 8) apply to ecommerce merchants that redirect customers from their website to a third party for payment processing, and specifically to the merchant webserver upon which the redirection mechanism is located.

Mail order/telephone order (MOTO) or ecommerce merchants that have completely outsourced all operations (where there is no redirection mechanism from the merchant to the third party) and therefore do not have any systems in scope for this SAQ, would consider these requirements to be “not applicable.”


Addition of two new requirements:

  • 8.3.1 on the usage of multi-factor authentication for all non-console administrative access via non-console connections. This requirement was added to provide consistency with Requirement 2.3, which requires merchants to secure these connections with strong cryptography.
  • 11.3.4 on verification segmentation controls if segmentation is used. This requirement requires that specific device types be used and that the defined devices are not connected to other systems. 

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).

Adyen requires service providers to always remain PCI DSS-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:

Service Providers validation requirements

Level Criteria Requirements
Level 1 Service Provider Store, process and/or transmit over 300,000 transactions per year

AoC (Attestation of Compliance) by QSA and quarterly network scan by ASV

Level 2 Service Provider Store, process and/or transmit less than 300,000 transactions per year SAQ D Service Provider and quarterly network scan by ASV

In many cases, service providers help Adyen connect with merchants using the connection methods offered by Adyen. Depending on their connection methods, Adyen may still require the merchants to fill out SAQ as applicable. In this case, the Card-Not-Present validation requirements apply.


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);
  • Token Service Provider (TSP);
  • Terminal Servicer (TS);
  • Merchant Monitoring Service Provider (MMSP); and
  • Service Provider Registration Facilitator (SPRF).

A Service Provider is categorized by the Schemes based upon their services provided to merchants. The description for each program service can be found in the latest Mastercard Rules.

Terminal Servicer

In August 2017, Mastercard introduced a new Service Provider type – Terminal Servicer (TS). A Terminal Servicer is an entity that provides ongoing maintenance and support of a payment terminal. Terminal Servicers generally do not store, process, or transmit cardholder data but are “connected-to” the merchant cardholder data environment.

Mastercard requires all service providers to be PCI-compliant. A Level 1 Service Provider is any TPP, Staged DWO (SDWO), DASP, or TSP (regardless of volume) and any DSE or PF that stores, transmits, processes more than 300,000 total combined Mastercard and Maestro transactions annually. A Level 2 Service Provider is any DSE or PF that is not deemed a Level 1 Service Provider and that stores, transmits, or processes 300,000 or less total combined Mastercard and Maestro transactions annually and any TS. For guidelines on suggested PCI DSS requirements that apply to TSs, please consult the Guidance for Terminal Servicer PCI DSS Validation.


Visa Europe recognizes two categories of service providers (Third Party Agents):

  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. Visa Member Agents are classified into the following registration types:
    • Member Visa System Processor (MVSP)
    • Visa System Processor (VSP)
    • Third Party Servicer (TPS)
    • Independent Sales Organization (ISO)

With Visa, PCI DSS validation is the same for all third party agents that store, process, or transmit card or account data. All Visa System Processors are considered Level 1 Service Providers. For more information, consult the Visa Europe Third Party Agent Registration and PCI DSS Compliance Validation Guide.

Visa Inc. recognizes third party agents as Merchant Services.

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. 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. 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.

Migration from SSL to early TLS

Due to the various security vulnerabilities present in Secure Sockets Layer (SSL) and early versions of Transport Layer Security (TLS), PCI SSC no longer considers these protocols as example of strong cryptography. After 30 June 2018, all entities must have stopped use of SSL/early TLS and upgrade to TLS 1.2. Prior to this date, existing implementations must have a formal Risk Mitigation and Migration Plan in place.

Adyen will disable early TLS on its Live Platform on February 19, 2018. Merchants should upgrade server-to-server and modification requests notifications to TLS 1.2 before this date. Direct API and CSE merchants are also required to upgrade to TLS 1.2. For more information, please visit this blog post and read this information supplement from PCI SSC.


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

  • Store, process or transmit cardholder data (the cardholder data environment)
  • Connect to the cardholder data environment
  • Provide security services to the cardholder data environment
  • Provide segmentation of the cardholder data environment
  • Could otherwise impact security of cardholder data environment

A2: System components that:

  • Do not store, process or transmit cardholder data, and
  • Do not connect to the cardholder data environment, and
  • Do not provide security services to the cardholder data environment, and
  • Do not provide segmentation of the cardholder data environment, and
  • Cannot otherwise impact security of cardholder data

Q3: What is “connected to”?

A3: Communication to and/or from the cardholder data environment

A4: Isolating the cardholder 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 data 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.


AOC Attestation of Compliance
ASV PCI Accredited Scanning Vendor
CHD Cardholder cata, 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
SSL Secure Sockets Layer
TLS Transport Layer Security


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 Quick Resource Guide
  • SAQ Instructions and Guidelines

The Frequently Asked Questions page of the PCI SSC website is constantly updated with new items.

Start your journey with Adyen today

Getting started is easy. Create an account, and explore all the tools you need to grow your business.

Are you looking for test card numbers?

Would you like to contact support?