---
title: "PCI DSS compliance guide"
description: "Learn what you need to do to comply with PCI DSS v4.0.1."
url: "https://docs.adyen.com/development-resources/pci-dss-compliance-guide"
source_url: "https://docs.adyen.com/development-resources/pci-dss-compliance-guide.md"
canonical: "https://docs.adyen.com/development-resources/pci-dss-compliance-guide"
last_modified: "2024-02-27T10:02:00+01:00"
language: "en"
---

# PCI DSS compliance guide

Learn what you need to do to comply with PCI DSS v4.0.1.

[View source](/development-resources/pci-dss-compliance-guide.md)

**PCI DSS v4.0.1 has been released**

[PCI DSS v4.0.1](https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf) has replaced v3.2.1. Now, when you assess your compliance, you must use PCI DSS v4.0.1 documents.

If you already completed a v4.0 document, you do not need to complete the v4.0.1 document. Your v4.0 document is valid until it expires.

The Payment Card Industry Data Security Standard (PCI DSS) is a set of global security standards created by the Payment Card Industry Security Standards Council (PCI SSC) to ensure that every company that collects, processes, stores, or transmits cardholder data maintains a secure cardholder data environment. PCI DSS applies to all entities that accept credit cards or are involved in payment processing, such as payment processors, acquirers, issuers, and service providers.

This document should be used only for guidance purposes, and should not be taken as definitive advice. You should always consult your acquirer or a PCI DSS Qualified Security Assessor (QSA) for clarification.

## Introduction to PCI DSS

PCI DSS, a global standard adopted by the major card schemes (Mastercard, Visa, JCB, Diners, and American Express), defines a set of technical and operational requirements that when implemented correctly, helps you to protect cardholder data, reduce fraud, and minimize the chances of a data breach resulting from malicious attacks. Complying with the requirements helps you to maintain your shopper's trust.

As mandated by the card schemes, every merchant that accepts credit card payments has to comply with PCI DSS requirements. Even though PCI DSS is not part of any law, the standard is applied globally and it comes with significant penalties and costs for organizations that do not comply with the requirements. These financial consequences include non-compliance assessment fees, legal costs, and costs for forensic investigations, onsite QSA assessments, and security updates.

Before you continue, it is important to understand that:

* PCI DSS applies solely to the people, processes, and technology that collect, store, process, or transmit cardholder data, known as the Cardholder Data Environment (CDE).
* PCI DSS is not a single event, but a continuous, ongoing process. Every entity has to validate their compliance with PCI DSS **annually** by completing one of the official PCI SSC validation documents.

## Adyen's role in PCI DSS compliance

Implementing PCI DSS in your business can be daunting, especially if you do not have an existing framework to protect sensitive information. To help reduce the scope of PCI DSS compliance, Adyen offers integrations that handle most of the PCI DSS requirements. The simplest way for you to be PCI compliant is to use our encrypted solutions—you never see and never have access to unencrypted cardholder data.

When you use our encrypted solutions, you are outsourcing most PCI DSS responsibilities to Adyen. However, because you accept credit card payments on your website, your app, or in your physical store, your integration with Adyen does not completely eliminate your PCI scope.

* **Adyen's responsibility**: Adyen is solely responsible for the security of cardholder data only as soon as Adyen receives the data through the relevant payment interface. After Adyen receives your shoppers' cardholder data, the data is contained in a PCI DSS Level 1 Service Provider Cardholder Data Environment.
* **Your responsibility**: You are responsible for making sure that cardholder data is secure and protected before the data reaches Adyen. Depending on your integration, you also have to comply with cardholder data storage requirements.

Adyen is a PCI DSS Level 1 Service Provider, with PCI DSS compliance assessed by an independent [Qualified Security Assessor (QSA)](https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors) annually.

## Ensuring compliance with PCI DSS v4.0.1

PCI DSS v4.0.1 was released on June 11, 2024. It has updates to existing requirements and introduces expanded requirements in key security and technology areas, such as:

* Mobile phones and tablets.
* Contactless payments.
* Cloud adaptation.
* New software development practices.
* Increased reliance on third-party services.

To validate your compliance with v4.0.1 and review the requirements, refer to the relevant integration sections for [Online payments](#online-payments), [Mobile in-app online payments](#mobile-in-app-online-payments-integration), and [In-person payments](#in-person-payments).

## Online payments integration

Select your [Web online payments](/online-payments) integration below to learn which PCI DSS requirements you must comply with and the corresponding documentation that you should provide:

The following validation requirements are based on Adyen's acceptable risk profile for each integration type. These may differ from what other acquirers require.

### Tab: Drop-in / Components / Plugins

**Required documents:**

* PCI DSS v4.0.1: [v4.0.1 Self-Assessment Questionnaire A](https://docs-prv.pcisecuritystandards.org/SAQ%20\(Assessment\)/SAQ/PCI-DSS-v4-0-1-SAQ-A.pdf)

You must [make sure that you have eligibility for SAQ A](/development-resources/pci-dss-compliance-guide/saq-a-eligibility).

**Integration:** You use Drop-in, Components, or a plugin that uses Adyen's [Card Component](/payment-methods/cards/web-component/) to embed a web page within your website using an [`iframe` element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe).

The content of the embedded elements is isolated from your web page, and the cardholder data is encrypted on your shopper's browser. You do not have access to decryption keys, thus you do not have access to your shoppers' cardholder data.

**Possible risks | Low-Medium:** This integration type may still be susceptible to data compromises by malicious actors. If an attacker gains unauthorized access to your website, they can find ways to deceive the shopper. For example, attackers can create alternative content for the Drop-in or Components, or drop an iframe over the already existing iframe. In this scenario, the payment may still be completed, but a copy of the cardholder data is sent to the attacker.

**Mitigating the risks:** The risks associated with this integration can be significantly reduced by doing the following:

* Making sure vendor-supplied usernames and passwords are not used within your environment.
* Actively monitoring industry sources for vulnerability information and patching software according to the risk ranking of identified vulnerabilities.
* Using unique user IDs and requiring strong passwords of at least 12 characters.
* Implementing a security policy that includes an incident response plan and defines information security roles and responsibilities for all personnel.
* Performing external vulnerability scans every 3 months. This is a new requirement in PCI DSS v4.0.1.
* Ensure all other iframes loaded into your page follow security best practices, and that the entities loading them are PCI DSS compliant.

Adyen iframes are designed to be isolated, which prevents browser-based malware from spreading to other elements of the webpage or network. Other iframes we load for additional payment methods or partners are vetted during our third-party onboarding process, ensuring the same level of security and PCI compliance.\
Additionally, Adyen is a qualified [PCI Secure Software Lifecycle (SLC) software vendor](https://listings.pcisecuritystandards.org/assessors_and_solutions/software_lifecycle) for the development of payment pages and components, added to its own PCI DSS Attestation of Compliance (AoC) regarding general security controls. Payment components are continuously tested for vulnerabilities and design issues, ensuring the required level of security.

**Validation document and requirements:** Adyen requires that you assess your PCI DSS compliance according to the following requirements of the Self-Assessment Questionnaire A (SAQ A):

* PCI DSS v4.0.1: Requirements 2, 6, 8, 11, and 12.

### Tab: Pay by Link

**Required documents:**

* None

**Integration:** You provide a payment link to your shopper by email, SMS, or QR code. The payment link redirects your shopper to a secure Adyen-hosted payment page to complete the payment. Your responsibility is to provide the shopper with the correct link to the Adyen-hosted payment page.

**Possible risks | Low:** An attacker could gain access to your system that generates the link, through API or the Customer Area, and change the payment link from an Adyen-hosted payment page to a fraudulent payment website where they try to steal your shopper's cardholder data.

**Mitigating the risks:** The risks associated with this integration can be significantly reduced by making sure that vendor-supplied usernames and passwords are not used within your environment, software is patched as soon as released, and strong passwords and unique user IDs are used.

Adyen is a qualified [PCI Secure Software Lifecycle (SLC) software vendor](https://listings.pcisecuritystandards.org/assessors_and_solutions/software_lifecycle) for the development of payment pages and components, added to its own PCI DSS AoC regarding general security controls. Payment pages are continuously tested for vulnerabilities and design issues, ensuring the required level of security.

**Validation document and requirements:** Adyen does not require you to submit any PCI DSS documentation. However, you must be PCI DSS compliant at all times. For more information on PCI DSS requirements, refer to [PCI DSS Quick Reference Guide](https://listings.pcisecuritystandards.org/search_result/documents/pci_ssc_quick_reference_guide). Furthermore, Adyen may occasionally contact you and ask you to provide necessary PCI DSS documentation depending on your risk profile.

### Tab: Hosted Checkout

**Required documents:**

* PCI DSS v4.0.1: [v4.0.1 Self-Assessment Questionnaire A](https://docs-prv.pcisecuritystandards.org/SAQ%20\(Assessment\)/SAQ/PCI-DSS-v4-0-1-SAQ-A.pdf)

You must make sure that you have [eligibility for SAQ A](/development-resources/pci-dss-compliance-guide/saq-a-eligibility).

**Integration:** You redirect your shopper from your website to an Adyen-hosted payment page to complete the payment. After your shopper completes the payment, they return to your website with the result of the payment session.

**Possible risks | Low:** An attacker could gain access to your website and change the redirect from an Adyen-hosted payment page to a fraudulent payment website where they try to steal your shopper's cardholder data.

**Mitigating the risks:** The risks associated with this integration can be significantly reduced by making sure that vendor-supplied usernames and passwords are not used within your environment, software is patched as soon as released, and strong passwords and unique user IDs are used.

Adyen is a qualified [PCI Secure Software Lifecycle (SLC) software vendor](https://listings.pcisecuritystandards.org/assessors_and_solutions/software_lifecycle) for the development of payment pages and components, added to its own PCI DSS AoC regarding general security controls. Payment pages are continuously tested for vulnerabilities and design issues, ensuring the required level of security.

**Validation document and requirements:** Adyen requires that you assess your PCI DSS compliance according to the following requirements of the Self-Assessment Questionnaire A (SAQ A):

* PCI DSS v4.0.1: Requirements 2, 6, 8, 11, and 12.

### Tab: API only

This applies if you use raw card data from shoppers.

**Required document:**

* PCI DSS v4.0.1: [v4.0.1 Self-Assessment Questionnaire D](https://docs-prv.pcisecuritystandards.org/SAQ%20\(Assessment\)/SAQ/PCI-DSS-v4-0-1-SAQ-D-Merchant.pdf)

If you use Adyen's [Custom Card Component](/payment-methods/cards/custom-card-integration), which includes encryption based on our [Card Component](/development-resources/pci-dss-compliance-guide?tab=drop-in__components__plugins_0_1) and securely encrypts card details, the required document is:

* [v4.0.1 Self-Assessment Questionnaire A](https://docs-prv.pcisecuritystandards.org/SAQ%20\(Assessment\)/SAQ/PCI-DSS-v4-0-1-SAQ-A.pdf)

**Integration:** You build your own UI and use only our APIs. This integration is commonly used when you want to be in full control of the payment flow. The checkout page is hosted, served, and controlled by you. You receive cardholder data from your shopper's browser, process the data, and then send the raw card data to Adyen over Transport Layer Security (TLS 1.2), according to PCI DSS requirements.

**Possible risks | High:** This integration requires a wider PCI DSS scope as your system receives, transmits, and potentially stores and processes cardholder data—giving you full control of the payment flow and the payment data. A malicious actor that successfully compromises your website or your systems will potentially be able to access large amounts of cardholder data.

**Mitigating the risks:** The risks associated with this integration are considered higher, since you are completely in control over the collection, transmission, and optional storage of cardholder data. Consequently, you'll have to comply with all eligible PCI DSS requirements, because these functions are not outsourced to Adyen.

**Validation document and requirements:** To mitigate the risks associated with this integration, Adyen requires that you assess your PCI DSS compliance according to *Self-Assessment Questionnaire D* (*SAQ D*), the most extensive form of self-certification. Because SAQ D is the default catch-all SAQ, there may still be parts of it that are not applicable to your environment. We recommend that you ensure that you have sufficient resource and capacity to handle this level of security.

**ASV Network Scan:** Because your network is included or connected to the cardholder data environment, you are also required to perform *quarterly* external vulnerability network scans. This scan has to be performed by an [Approved Scanning Vendor](https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors) ([ASV](#ASV)). The scans are conducted over the internet, as a remote service and do not require on-site presence to execute.

[\* Approved Scanning Vendors Program Guide](https://www.pcisecuritystandards.org/documents/ASV_Program_Guide_v3.0.pdf)

### Tab: Client-Side Encryption

### JSON Web Encryption (JWE)

Use a third-party JWE library to encrypt card details client-side.

**Required document:**

* [v4.0.1 Self-Assessment Questionnaire A](https://docs-prv.pcisecuritystandards.org/SAQ%20\(Assessment\)/SAQ/PCI-DSS-v4-0-1-SAQ-A.pdf)

You must make sure that you have [eligibility for SAQ A](/development-resources/pci-dss-compliance-guide/saq-a-eligibility).

**Integration:** You generate the payment form on your website where shoppers submit their payment details. Cardholder data is encrypted on your shopper's browser using a third-party JWE library, sent to your server, and then transmitted to Adyen.

**Possible risks | Medium:** Because you provide the payment form, your systems are in scope for additional PCI DSS controls. The chances of your system being compromised when using Adyen's CSE integration are potentially higher because you serve the payment form to your shopper. Malicious actors could potentially change your self-hosted CSE JavaScript library and steal your shopper's cardholder data.

**Mitigating the risks:** The risks associated with this integration can be significantly reduced by making sure you apply mandatory PCI DSS controls, such as not using vendor-supplied usernames and passwords, patching software as soon as released, software being developed addressing vulnerabilities, and more.

**Validation document and requirements:** Although a JWE integration carries more risks than Pay by Link, Drop in, and Components, the integration could still be scoped on the Self Assessment Questionnaire A (SAQ A) for PCI DSS compliance because once encrypted, you cannot decrypt the data.

### Client-side encryption library

**The Client-Side Encryption (CSE) Web integrations are being phased out**\
This means we are:

* No longer developing the CSE integration.
* Not accepting new CSE integrations.

Switch to one of our latest [Web integrations](/online-payments/build-your-integration/sessions-flow?platform=Web), to accept payments on your website.

Mobile integrations aren't affected.

To comply with PCI v4.0.1, you must make a modification to your integration to [implement Subresource Integrity](/online-payments/classic-integrations/classic-api-integration/client-side-encryption#client-side).

**Required document:**

* [v4.0.1 Self-Assessment Questionnaire A](https://docs-prv.pcisecuritystandards.org/SAQ%20\(Assessment\)/SAQ/PCI-DSS-v4-0-1-SAQ-A.pdf)

You must make sure that you have [eligibility for SAQ A](/development-resources/pci-dss-compliance-guide/saq-a-eligibility)

**Integration**: You generate the payment form on your website where shoppers submit their payment details. Cardholder data is encrypted on your shopper's browser, sent to your server, and then transmitted to Adyen. The CSE solution works with a JavaScript library, which can be hosted by either yourself or Adyen.

**Possible risks | Medium:** Because you provide the payment form and you can host the CSE library, your systems are in scope for additional PCI DSS controls. The chances of your system being compromised when using Adyen's CSE integration are potentially higher because you serve the payment form to your shopper. Malicious actors could potentially change your self-hosted CSE JavaScript library and steal your shopper's cardholder data.

**Mitigating the risks**:The risks associated with this integration can be significantly reduced by making sure vendor-supplied usernames and passwords are not used within your environment, software is patched as soon as released, and strong passwords and unique user IDs are used.

**Validation document and requirements**: Although a CSE integration carries more risks than Pay by Link, Drop-in, and Components, Adyen only requires you to complete Self-Assessment *Questionnaire A* (*SAQ A*) for PCI DSS compliance because you cannot decrypt cardholder data.

### Additional reading

* [Infographic - Strong Passwords](https://www.pcisecuritystandards.org/documents/Payment-Data-Security-Essential-Strong-Passwords.pdf?agreement=true\&time=1565256423488)
* [Infographic - Patching](https://www.pcisecuritystandards.org/documents/Payment-Data-Security-Essential-Patching.pdf?agreement=true\&time=1565256423505)
* [Best Practices for Securing E-commerce](https://www.pcisecuritystandards.org/pdfs/best_practices_securing_ecommerce.pdf?agreement=true\&time=1565342137625)

## Mobile in-app online payments integration

Select how you implemented your [iOS](/online-payments/ios) or [Android](/online-payments/android) integration below to learn which PCI DSS requirements you must comply with and the corresponding documentation that you should provide:

### Tab: Drop-in or Components

**Required documents:**

* PCI DSS v4.0.1: [v4.0.1 Self-Assessment Questionnaire A](https://docs-prv.pcisecuritystandards.org/SAQ%20\(Assessment\)/SAQ/PCI-DSS-v4-0-1-SAQ-A.pdf)

You must make sure that you have [eligibility for SAQ A](/development-resources/pci-dss-compliance-guide/saq-a-eligibility).

**Integration:** Your app generates the payment form using Adyen's Drop-in or Components solution, and the shopper submits their payment details. Cardholder data is encrypted in the app, sent to your server, and then transmitted to Adyen. The Drop-in or Components solution works with a native library, which is embedded in your mobile app.

**Possible risks | Low:** Because the Drop-in and Components native library is implemented in your app and not on a public website, the risks associated with your integration are considerably low. While malicious actors are not able to target the majority of your app users since the app runs on individual devices, they still could potentially target security vulnerabilities of a specific mobile device.

**Mitigating the risks:** The risks associated with this integration can be significantly reduced by doing the following:

* Making sure vendor-supplied usernames and passwords are not used within your environment.
* Actively monitoring industry sources for vulnerability information and patching software according to the risk ranking of identified vulnerabilities.
* Using unique user IDs and requiring strong passwords of at least 12 characters.
* Implementing a security policy that includes an incident response plan and defines information security roles and responsibilities for all personnel.
* Performing external vulnerability scans every 3 months. This is a new requirement in PCI DSS v4.0.1.

**Validation document and requirements:** Adyen requires that you assess your PCI DSS compliance according to the following requirements of the Self-Assessment Questionnaire A (SAQ A):

* PCI DSS v4.0.1: Requirements 2, 6, 8, 11, and 12.

### Additional reading

* [Infographic - Strong Passwords](https://www.pcisecuritystandards.org/documents/Payment-Data-Security-Essential-Strong-Passwords.pdf?agreement=true\&time=1565256423488)
* [Infographic - Patching](https://www.pcisecuritystandards.org/documents/Payment-Data-Security-Essential-Patching.pdf?agreement=true\&time=1565256423505)
* [Best Practices for Securing E-commerce](https://www.pcisecuritystandards.org/pdfs/best_practices_securing_ecommerce.pdf?agreement=true\&time=1565342137625)

### Tab: API only

Required document:

* PCI DSS v4.0.1: [v4.0.1 Self-Assessment Questionnaire D](https://docs-prv.pcisecuritystandards.org/SAQ%20\(Assessment\)/SAQ/PCI-DSS-v4-0-1-SAQ-D-Merchant.pdf)

**Integration:** You build your own UI and use only our APIs. This integration is commonly used when you want to be in full control of the payment flow. The payment form is hosted, served, and controlled by you. You receive cardholder data through the app - which can be optionally stored - and then you send the raw card data to Adyen over Transport Layer Security (TLS 1.2), according to PCI DSS requirements.

**Possible risks | Medium:** This integration requires a wider PCI DSS scope as your system receives, transmits, and potentially stores and processes cardholder data—giving you full control of the payment flow and the payment data. While malicious actors are not able to target the majority of your app users since the app runs on individual devices, a malicious actor that successfully compromises your systems will still potentially be able to access large amounts of cardholder data.

**Mitigating the risks:** The risks associated with this integration are considered higher, since you are completely in control over the collection, transmission, and optional storage of cardholder data. Consequently, you'll have to comply with all eligible PCI DSS requirements, because these cardholder data functions are not outsourced to Adyen.

**Validation document and requirements:** To mitigate the risks associated with this integration, Adyen requires that you assess your compliance using a *Self-Assessment Questionnaire D (SAQ D)*, the most extensive form of self-certification. Because SAQ D is the default catch-all SAQ, there may still be parts of it that aren't applicable to your environment. We recommend that you ensure that you have sufficient resources and capacity in order to handle this level of security.

### Additional reading

* [Infographic - Strong Passwords](https://www.pcisecuritystandards.org/documents/Payment-Data-Security-Essential-Strong-Passwords.pdf?agreement=true\&time=1565256423488)
* [Infographic - Patching](https://www.pcisecuritystandards.org/documents/Payment-Data-Security-Essential-Patching.pdf?agreement=true\&time=1565256423505)
* [Best Practices for Securing E-commerce](https://www.pcisecuritystandards.org/pdfs/best_practices_securing_ecommerce.pdf?agreement=true\&time=1565342137625)

## In-person payments integration

When implementing an [in-person payments](/point-of-sale) integration, you have the option to use payment terminals with either our default End-to-End Encryption (E2EE), or Point-to-Point Encryption (P2PE). Select the encryption standard below to learn about the PCI DSS requirements you must comply with and the corresponding documentation that you should provide.

### Tab: E2EE

If you are using our [in-person payments](/point-of-sale) integration, you only have to provide Adyen with *Self-Assessment Questionnaire B-IP* if you process over 1 million card-present transactions annually.

Required document:

* PCI DSS v4.0.1: [v4.0 Self-Assessment Questionnaire B-IP](https://docs-prv.pcisecuritystandards.org/SAQ%20\(Assessment\)/SAQ/PCI-DSS-v4-0-1-SAQ-B-IP.pdf)

**Integration:** The payment terminals provided by Adyen are all [PTS-approved ](https://www.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices)Point-of-Interaction ([POI](#POI)) devices. Adyen's [in-person payments integration](/point-of-sale) has been designed to reduce your PCI DSS scope as much as possible through End-to-End Encryption (E2EE). None of your systems, including your POS system, receive cardholder data in unencrypted forms.

**Possible risks | Low:** Adyen ensures End-to-End Encryption and is responsible for the security of your shoppers' cardholder data as soon as we receive the data through the payment terminal. The risks for in-person payments integrations are related to the physical security of the payment terminal. Malicious actors can tamper with or replace payment terminals.

**Mitigating the risks**: Risks associated with this integration, such as skimming attacks, can be significantly reduced by doing the following:

* Implementing policies and procedures to periodically inspect the security of the payment terminals, to confirm that they have not been tampered with and that tamper-evident security packing tape or seals have not been broken.
* Actively monitoring industry sources for vulnerability information and patching software according to the risk ranking of the spotted vulnerabilities. This applies only if you [update your terminals manually](/point-of-sale/release-updating/#manual-updating).
* Implementing a security policy which defines information security roles and responsibilities for all personnel.
* Engaging and maintaining a relationship with only PCI DSS compliant third-party service providers.

**Validation document and requirements:** Adyen requires you to assess your PCI DSS compliance along with any other requirements that might apply to your environment with the following requirements from the *Self-Assessment Questionnaire B-IP* (*SAQ B-IP*):

* PCI DSS v4.0.1: Requirements 9.1, 9.5, and 12.

### Additional reading

* [Best Practices for Merchants: Skimming Prevention](https://www.pcisecuritystandards.org/documents/Skimming_Prevention_BP_for_Merchants_Sept2014.pdf?agreement=true\&time=1574264409741)
* [Comparing Adyen's E2EE and P2PE solutions](/development-resources/e2ee-p2pe-comparison)

### Tab: P2PE

If you are using our [in-person payments](/point-of-sale) integration with Point-to-Point Encryption (P2PE), you are required to implement all the requirements in the [P2PE Instruction Manual (PIM)](https://www.adyen.com/legal/p2pe-instruction-manual).

Required document:

* PCI DSS v4.0.1: [v4.0.1 Self-Assessment Questionnaire P2PE](https://docs-prv.pcisecuritystandards.org/SAQ%20\(Assessment\)/SAQ/PCI-DSS-v4-0-1-SAQ-P2PE.pdf)

**Integration:** The payment terminals provided by Adyen are all validated and listed P2PE-approved solutions. The cardholder data is encrypted from the point of interaction until it reaches Adyen's secure decryption environment, ensuring that you do not have access to clear-text cardholder data on any systems.

**Possible risks | Low:** Adyen ensures P2PE and is responsible for the security of your shopper's cardholder data as soon as we receive the data through the payment terminal. The risks for in-person payments integrations are related to the physical security of the payment terminal. Malicious actors can tamper with or replace payment terminals.

**Mitigating the risks**: Risks associated with this integration, such as skimming attacks, can be significantly reduced by doing the following:

* Implementing policies and procedures to periodically inspect the security of the payment terminals, to confirm that they have not been tampered with and that tamper-evident security packing tape or seals have not been broken.
* Actively monitoring industry sources for vulnerability information and patching software according to the risk ranking of the spotted vulnerabilities. This applies only if you [update your terminals manually](/point-of-sale/release-updating/#manual-updating).
* Implementing a security policy which defines information security roles and responsibilities for all personnel.
* Engaging and maintaining a relationship with only PCI DSS compliant third-party service providers.

**Validation document and requirements:** Adyen requires you to assess your PCI DSS compliance according to the requirements in the Self-Assessment Questionnaire P2PE (SAQ P2PE):

* PCI DSS v4.0.1: Requirements 9.1, 9.5, and 12.

You are also required to implement all requirements in the P2PE Instruction Manual (PIM).

### Additional reading

* [P2PE FAQs](https://docs-prv.pcisecuritystandards.org/P2PE/Standard/PCI-P2PE-v3.x-Technical-FAQs-04Dec2024.pdf)
* [P2PE Security Program Guide](https://docs-prv.pcisecuritystandards.org/P2PE/Program%20Documents/PCI-P2PE-Program-Guide-v3.1.pdf)
* [P2PE Security Requirements and Testing Procedures](https://www.pcisecuritystandards.org/documents/P2PE_v3.0_Standard.pdf)

## Service Providers

Because Adyen processes your payments, Adyen is regarded as a *Service Provider*. Merchants will often engage with a number of different service providers for a variety of reasons. For example, you could engage a service provider to perform recurring payments, provide shopping cart solutions, or to facilitate subscription billing. By using service providers, you are transferring parts of your PCI DSS obligations towards them.

To carry out outsourced functions, service providers need access to your shoppers' cardholder data, making their PCI DSS compliance vital. When engaging a service provider, you are responsible for:

* Making sure that the service provider is PCI DSS-compliant regardless of the type of service they are providing.
* Identifying the functions each service provider is performing.
* Ensuring that the service providers acknowledge their PCI DSS responsibilities.

Adyen has a trusted list of partners, which includes: Zuora, VTEX, and Recurly. Refer to [Adyen's partner page](https://www.adyen.com/partners/network) for our complete list of partners.

### Requirements when using a Service Provider

If you are using a Service Provider who has access to your shoppers' cardholder data, you are outsourcing part of your PCI DSS responsibilities. You are required to:

1. Ask your service provider for their [Service Provider's Attestation of Compliance](https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2_1-AOC-ServiceProviders.pdf).
2. Make sure that the service provider is registered with the schemes and is listed on [Visa's Global Registry of Service Providers](https://usa.visa.com/splisting/splistingindex.html) and [Mastercard's Compliant Service Provider List](https://www.mastercard.us/en-us/merchants/safety-security/security-recommendations/service-providers-need-to-know.html).

After you have collected your Service Provider's AoC and verified that they are registered with the schemes, you then need to provide Adyen with:

1. Names of the service providers, along with the corresponding outsourced functions, clearly stated in part 2F of your Self-Assessment Questionnaire (SAQ) or Attestation of Compliance (AoC).
2. The [Service Provider's Attestation of Compliance](https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2_1-AOC-ServiceProviders.pdf).

The use of service providers does not relieve you of the ultimate responsibility for your own PCI DSS compliance. You must manage the relationship with the service provider as described in **PCI DSS requirement 12.8**, including listing all the service providers you use, maintaining agreements and acknowledgement of responsibilities, carrying out due diligence prior to engagement, and monitoring the service provider's PCI DSS compliance status (by requesting their AoC every year).

## PCI DSS Glossary

* AOC – [Attestation of Compliance](https://www.pcisecuritystandards.org/document_library?category=saqs\&subcategory=saqs_saq_aoc) - A form to attest the results of a PCI DSS assessment, as documented in a Self-Assessment Questionnaire (SAQ) or Report on Compliance (RoC).[]()

* ASV – [Approved Scanning Vendor](https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors) - A company approved by the PCI SSC to conduct external vulnerability network scanning services.[]()

* CDE – Cardholder Data Environment - The people, processes and technology that collect, store, process or transmit cardholder data.[]()

* CHD – Cardholder data - At minimum, cardholder data consist of the full PAN (Personal Account Number), optionally accompanied by the cardholder name, expiration date and/or service code.

* PCI DSS – [Payment Card Industry Data Security Standards](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf?agreement=true\&time=1577114024374).[]()

* PCI SSC – [Payment Card Industry Security Standards Council](https://www.pcisecuritystandards.org/).[]()

* POI - Point of Interaction - The initial point where cardholder data is read from a card, typically a payment terminal.[]()

* PTS - [PIN Transaction Security](https://www.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices) - PTS is a set of modular evaluation requirements managed by PCI Security Standards Council, for PIN acceptance POI terminals

* QSA – [Qualified Security Assessor](https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors) - A company which is qualified by the PCI SSC to perform PCI DSS onsite assessments.[]()

* RoC – [Report on Compliance](https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2_1-ROC-Reporting-Template.pdf?agreement=true\&time=1577114091639) - Report documenting detailed results from an entity's PCI DSS assessment.[]()

* SAD – Sensitive Authentication Data - Security-related information used for authentication or authorization. SAD may refer to the 3- or 4-digit values on a card used to verify card-not-present transactions such as CAV2, CVC2, CID and CVV2.

* SAQ – [Self Assessment Questionnaire](https://www.pcisecuritystandards.org/document_library?category=saqs#results) - Reporting tool used to document self-assessment results from an entity's PCI DSS assessment.[]()

* TLS - Transport Layer Security - A network communications protocol designed with the goal of providing data secrecy and data integrity between two communicating applications. TLS is successor of SSL.

## See also

* [PCI compliance levels](/development-resources/pci-dss-compliance-guide/merchant-levels)
* [Engaging a Qualified Security Assessor](/development-resources/pci-dss-compliance-guide/pci-with-qsa)
* [PCI DSS FAQs](https://help.adyen.com/knowledge/compliance/pci-dss-compliance)
* [Mastercard's Compliant Service Provider List](https://www.mastercard.us/en-us/merchants/safety-security/security-recommendations/service-providers-need-to-know.html)
* [Visa's Global Registry of Service Providers](https://usa.visa.com/splisting/splistingindex.html)
