PCI DSS

PCI DSS Guide

PCI council
Last updated:September 23, 2024

Imagine a world where your customers’ payment data is always secure, transactions are seamless, and trust is never compromised. That’s the peace of mind PCI DSS brings. It safeguards cardholder data, reduces fraud, and ensures your business remains compliant and trustworthy.

PCI DSS Essentials

Introduction to PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) is a global security standard established by major credit card companies—Visa, Mastercard, American Express, Discover, and JCB—through the Payment Card Industry Security Standards Council (PCI SSC) in 2006. It aims to protect cardholder data and ensure trust in the payment ecosystem.

Importance of PCI DSS

PCI DSS applies to any organization that stores, processes, or transmits cardholder data. Compliance helps protect cardholder data, reduce fraud, and minimize the risk of data breaches. It also helps maintain customer trust and avoid significant penalties and costs associated with non-compliance.

PCI DSS Requirements

PCI DSS includes 12 main requirements and over 300 sub-requirements, covering:

Build and Maintain a Secure Network and Systems
  • Requirement 1Install and maintain network security controls.
  • Requirement 2Apply secure configurations to all system components.
Protect Cardholder Data
  • Requirement 3Protect stored cardholder data.
  • Requirement 4Use strong cryptography during transmission over open, public networks.
Maintain a Vulnerability Management Program
  • Requirement 5Protect systems and networks from malicious software.
  • Requirement 6Develop and maintain secure systems and software.
Implement Strong Access Control Measures
  • Requirement 7Restrict access to system components and cardholder data by business need to know.
  • Requirement 8Identify users and authenticate access to system components.
  • Requirement 9Restrict physical access to cardholder data.
Regularly Monitor and Test Networks
  • Requirement 10Log and monitor all access to system components and cardholder data.
  • Requirement 11Test security of systems and networks regularly.
Maintain an Information Security Policy
  • Requirement 12Support information security with organizational policies and procedures.

PCI DSS Compliance Levels

Compliance levels are based on the volume of credit card transactions processed annually:

  • Level 1: Over 6 million transactions or any organization that has experienced a data breach.
  • Level 2: 1 to 6 million transactions.
  • Level 3: 20,000 to 1 million online transactions.
  • Level 4: Fewer than 20,000 online transactions or up to 1 million total transactions.

PCI DSS Self-Assessment Questionnaire (SAQ)

Different SAQ types apply based on the payment integration method:

  • SAQ A: Card-not-present merchants outsourcing all account data functions.
  • SAQ A-EP: Ecommerce merchants partially outsourcing payment processing.
  • SAQ B: Merchants using imprint machines or standalone, dial-out terminals.
  • SAQ B-IP: Merchants using standalone, PTS-approved payment terminals with an IP connection.
  • SAQ C-VT: Merchants manually entering payment data via a virtual terminal.
  • SAQ C: Merchants with internet-connected payment application systems.
  • SAQ P2PE: Merchants using a validated, PCI-listed point-to-point encryption solution.
  • SAQ SPoC: Merchants using a mobile device with a secure card reader.
  • SAQ D: All other merchants and service providers.

PCI DSS Roles and Responsibilities

Implementing PCI DSS can be complex and costly, especially for merchants without an existing security framework. Payment Service Providers (PSPs) offer integrations that handle most PCI DSS requirements, simplifying compliance. However, merchants still need to ensure cardholder data is secure before it reaches the PSP.

  • PSP’s Responsibility: Secure cardholder data once received through the payment interface.
  • Merchant’s Responsibility: Secure cardholder data before it reaches the PSP and comply with storage requirements if applicable.

Evolution to PCI DSS 4.x

Welcome to the future of payment security with PCI DSS 4.x! This latest version brings groundbreaking changes designed to enhance security, flexibility, and risk management. Here’s what you need to know:

  • Stronger Authentication: Expanded multi-factor authentication (MFA) requirements ensure robust protection for all access points.
  • Password Upgrades: Say goodbye to weak passwords with new minimum complexity requirements.
  • Customizable Controls: Tailor security measures to fit your unique environment with flexible implementation options.
  • Continuous Vigilance: Embrace ongoing risk assessments to stay ahead of evolving threats.
  • Advanced Monitoring: Enhanced logging and detection capabilities for swift incident response.
  • Tech-Ready: Adapt seamlessly to emerging technologies like mobile payments and cloud environments.

Effective March 31, 2024, PCI DSS 4.x will be the new standard, setting a higher bar for payment security. Get ready to elevate your security posture and protect your cardholder data like never before!

Admin compliance

Ensure seamless compliance with PCI DSS 4.x for master user account administrators.

How it works

1

Updates in PCI DSS 4.x

Discover the new requirements introduced in PCI DSS 4.x.

2

How to comply

Learn how our product meets these new requirements.

3

Actions required

Find out what actions you need to take as a merchant or Payment Service Provider (PSP).

1. Updates in PCI DSS 4.x

PCI DSS 4.x introduces new requirements designed to ensure that access to system components and data is appropriately defined and assigned.

Requirement 7.2.1An access control model is defined and includes granting access as follows:
  • Appropriate access depending on the entity’s business and access needs.
  • Access to system components and data resources that is based on users’ job classification and functions.
  • The least privileges required (for example, user, administrator) to perform a job function.

Show requirement details

Purpose
Defining an access control model that is appropriate for the entity’s technology and access control philosophy supports a consistent and uniform way of allocating access and reduces the possibility of errors such as the granting of excessive rights.

Good practice
A factor to consider when defining access needs is the separation of duties principle. This principle is intended to prevent fraud and misuse or theft of resources. For example:

  • dividing mission-critical functions and information system support functions among different individuals and/or functions
  • establishing roles such that information system support activities are performed by different functions/individuals (for example, system management, programming, configuration management, quality assurance and testing, and network security)
  • ensuring security personnel administering access control functions do not also administer audit functions.
In environments where one individual performs multiple functions, such as administration and security operations, duties may be assigned so that no single individual has end-to-end control of a process without an independent checkpoint. For example, responsibility for configuration and responsibility for approving changes could be assigned to separate individuals.

Requirement 7.2.2Access is assigned to users, including privileged users, based on:
  • Job classification and function.
  • Least privileges necessary to perform job responsibilities.

Show requirement details

Purpose
Assigning least privileges helps prevent users without sufficient knowledge about the application from incorrectly or accidentally changing application configuration or altering its security settings. Enforcing least privilege also helps to minimize the scope of damage if an unauthorized person gains access to a user ID.

Good practice
Access rights are granted to a user by assignment to one or several functions. Access is assigned depending on the specific user functions and with the minimum scope required for the job. When assigning privileged access, it is important to assign individuals only the privileges they need to perform their job (the “least privileges”).

Requirement 7.2.4All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows:
  • At least once every six months.
  • To ensure user accounts and access remain appropriate based on job function.
  • Any inappropriate access is addressed.
  • Management acknowledges that access remains appropriate.

Show requirement details

Purpose

  • Regular review of access rights helps to detect excessive access rights remaining after user job responsibilities change, system functions change, or other modifications. If excessive user rights are not revoked in due time, they may be used by malicious users for unauthorized access.
  • This review provides another opportunity to ensure that accounts for all terminated users have been removed (if any were missed at the time of termination), as well as to ensure that any third parties that no longer need access have had their access terminated.

Good practice

  • When a user transfers into a new role or a new department, typically the privileges and access associated with their former role are no longer required. Continued access to privileges or functions that are no longer required may introduce the risk of misuse or errors. Therefore, when responsibilities change, processes that revalidate access help to ensure user access is appropriate for the user’s new responsibilities.
  • Entities can consider implementing a regular, repeatable process for conducting reviews of access rights, and assigning “data owners” that are responsible for managing and monitoring access to data related to their job function and that also ensure user access remains current and appropriate. As an example, a direct manager could review team access monthly, while the senior manager reviews their groups’ access quarterly, both making updates to access as needed. The intent of these best practices is to support and facilitate conducting the reviews at least once every 6 months.

2. How to comply

To comply with PCI DSS v4.x, specifically the 7.2.x requirements, all user accounts and access privileges, including those of third-party vendors, must be reviewed at least every six months to ensure they are appropriate for the user’s job function. These reviews must be conducted by your organization’s administrators.

3. Actions required

As a master user account administrator, you are responsible for managing and reviewing all user accounts under your organization’s master account starting March 31, 2025. It is advisable to begin this process sooner. Your responsibilities include:

  • Reviewing user accounts and access privileges at least every six months.
  • Ensuring access remains appropriate based on job functions.
  • Promptly addressing any inappropriate access.
  • Obtaining management acknowledgment that access remains appropriate.
Managing and reviewing your organization’s user accounts, and adhering to the above guidelines, is essential for maintaining the security and integrity of your systems and data.

Scripts compliance

Ensure seamless compliance with PCI DSS 4.x for payment scripts.

How it works

1

Updates in PCI DSS 4.x

Discover the new requirements introduced in PCI DSS 4.x.

2

How to comply

Learn how our product meets these new requirements.

3

Actions required

Find out what actions you need to take as a merchant or Payment Service Provider (PSP).

1. Updates in PCI DSS 4.x

PCI DSS 4.x introduces new requirements to enhance control over how payment pages manage loaded scripts, aiming to detect and prevent e-commerce skimming attacks, a major cause of cardholder data breaches. The new requirements focus on two main areas:

  • Protecting public-facing web applications against attacks.
  • Detecting and responding to unauthorized changes on payment pages.
Requirement 6.4.3All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:

  • A method is implemented to confirm that each script is authorized.
  • A method is implemented to assure the integrity of each script.
  • An inventory of all scripts is maintained with written justification as to why each is necessary.

Show requirement details

Purpose

  • Scripts loaded and executed in the payment page can have their functionality altered without the entity’s knowledge and can also have the functionality to load additional external scripts (for example, advertising and tracking, tag management systems).
  • Such seemingly harmless scripts can be used by potential attackers to upload malicious scripts that can read and exfiltrate cardholder data from the consumer browser.
  • Ensuring that the functionality of all such scripts is understood to be necessary for the operation of the payment page minimizes the number of scripts that could be tampered with.
  • Ensuring that scripts have been explicitly authorized reduces the probability of unnecessary scripts being added to the payment page without appropriate management approval. Where it is impractical for such authorization to occur before a script is changed or a new script is added to the page, the authorization should be confirmed as soon as possible after a change is made.
  • Using techniques to prevent tampering with the script will minimize the probability of the script being modified to carry out unauthorized behavior, such as skimming the cardholder data from the payment page.

Good practice

  • Scripts may be authorized by manual or automated (e.g., workflow) processes.
  • Where the payment page will be loaded into an inline frame (iframe), restricting the location that the payment page can be loaded from, using the parent page’s Content Security Policy (CSP) can help prevent unauthorized content being substituted for the payment page.
  • Where an entity includes a TPSP’s/payment processor’s embedded payment page/form on its webpage, the entity should expect the TPSP/payment processor to provide evidence that the TPSP/payment processor is meeting this requirement.
Examples: The integrity of scripts can be enforced by several different mechanisms including, but not limited to:
  • Sub-resource integrity (SRI), which allows the consumer browser to validate that a script has not been tampered with.
  • A CSP, which limits the locations the consumer browser can load a script from and transmit account data to.
  • Proprietary script or tag-management systems, which can prevent malicious script execution.

Requirement 11.6.1A change- and tamper-detection mechanism is deployed as follows:
  • To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.
  • The mechanism is configured to evaluate the received HTTP header and payment page.
  • The mechanism functions are performed at least weekly or periodically (at the frequency defined in the entity’s targeted risk analysis.

Show requirement details

Purpose

  • Many web pages now rely on assembling objects, including active content (primarily JavaScript), from multiple internet locations. Additionally, the content of many web pages is defined using content management and tag management systems that may not be possible to monitor using traditional change detection mechanisms.
  • Therefore, the only place to detect changes or indicators of malicious activity is in the consumer browser as the page is constructed and all JavaScript interpreted.
  • By comparing the current version of the HTTP header and the active content of payment pages as received by the consumer browser with prior or known versions, it is possible to detect unauthorized changes that may indicate a skimming attack, or an attempt to disable a control designed to protect against, or to detect, skimming attacks.
  • Additionally, by looking for known indicators of compromise and script elements or behavior typical of skimmers, suspicious alerts can be raised.

Good practice

  • Where an entity includes a TPSP’s/payment processor’s embedded payment page/form on its webpage, the entity should expect the TPSP/payment processor to provide evidence that the TPSP/payment processor is meeting this requirement.
Examples: Mechanisms that detect and report on changes to the headers and content of the payment page could include, but are not limited to, a combination of the following techniques:
  • Violations of the Content Security Policy (CSP) can be reported to the entity using the report-to or report-uri CSP directives.
  • Changes to the CSP itself can indicate tampering.
  • External monitoring by systems that request and analyze the received web pages (also known as synthetic user monitoring) can detect changes to JavaScript in payment pages and alert personnel.
  • Embedding tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behavior is detected.
  • Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel.
The above list of mechanisms is not exhaustive, and the use of any one mechanism is not necessarily a full detection and reporting mechanism. Often, these mechanisms are subscription or cloudbased, but can also be based on custom and bespoke solutions.

2. How to comply

To meet PCI DSS v4.x Requirement 6.4.3, merchants have the following options:

While it is possible to adopt third party's solutions, with SecurePay the authorization and integrity of the script is always available using traditional methods.

3. Actions Required

Authorization of the scripts

Content Security Policy (CSP) can be used to specify which sources of content are allowed to be loaded on the page, including scripts, images, and other resources. This ensures that only authorized scripts are loaded on the payment page.

The steps are:

  1. Add CSP: Configure a CSP header to specify allowed sources for scripts and other resources on your page. The CSP header to be used for SecurePay can be found at the following link
  2. Test CSP: The recommendation is to start with Report-Only CSP to monitor violations without enforcing them. Use tools like CSP Evaluator to refine your policy.

Verify scripts integrity

Subresource Integrity (SRI) can be used to verify the integrity of scripts. SRI ensures that resources loaded are delivered without being manipulated or tampered with by malicious actors. The SRI hash is added to the integrity attribute when specifying a <script> element on the page. If the browser detects that the file’s hash does not match the specified hash, the browser will not load the resource.

How to Verify the Integrity of SecurePay

SecurePay is a script dynamically generated and unique for each payment session. The SRI hash must be generated and returned for each checkout. For this reason implements SecurePay provides a Dynamic SRI feature. A new parameter has been added and must be included in Step 1 Create Checkout call to generate the SRI hash. The hash will be returned in the response, allowing integrators to support a smooth transition for existing integrations.

The steps to follow are:

  1. Generate SRI Hash: Include a new parameter in the Step 1 Create Checkout call to generate the SRI hash. The hash will be returned in the response.
  2. Add SRI: Add the SRI hash to the integrity attribute of the <script> element on the payment page.
  3. Verify Integrity: The browser ensure that the SRI hash matches the fetched resource to prevent loading tampered scripts.

Example of Request and Response with the new parameter

Request 
curl https://eu-test.oppwa.com/v1/checkouts
-d "entityId=8a8294175d602369015d73bf009f1808"
-d "amount=92.00"
-d "currency=EUR"
-d "paymentType=DB"
-d "integrity=true"
-H "Authorization: Bearer OGE4Mjk0MTc1ZDYwMjM2OTAxNWQ3M2JmMDBlNTE4MGN8ZE1xNU1hVEQ1cg=="
Response 
{
	"result":{
		"code":"000.200.100",
		"description":"successfully created checkout"
	},
	"buildNumber":"577c5667d790266430da6bb4c0effd313f92bb8a@2024-08-28 00:42:29 +0000",
	"timestamp":"2024-08-29 10:44:20+0000",
	"ndc":"52252F000AA2C1BEB0A0F728B5119AB0.uat01-vm-tx01",
	"id":"52252F000AA2C1BEB0A0F728B5119AB0.uat01-vm-tx01"
	"integrity":"sha384-Uz9kJ7MP7hR4osV9qZgnqzAUaqeNOjwtCvpcQYvXmi61KPRg1EwdT+G1gYpVuEok"
}

Adding the Widget to the Payment Page

To render the widget on the payment page and verify its integrity, include the SRI hash retrieved from the integrity parameter in the response in the integrity attribute of the <script> element. 
<script 
	src="https://eu-test.oppwa.com/v1/paymentWidgets.js?checkoutId={checkoutId}"
	integrity="sha384-Uz9kJ7MP7hR4osV9qZgnqzAUaqeNOjwtCvpcQYvXmi61KPRg1EwdT+G1gYpVuEok"
	crossorigin="anonymous">
</script>

The browser will check the integrity of the script, and if it finds that the script was manipulated or tampered with, it will not load it.

Scripts inventory

To fully comply with Requirement 6.4.3, merchants must keep an inventory of all the scripts that load on the website with the reason for each script. The following scripts are the ones that SecurePay loads from third parties:

ReasonScript
Device Fingerprint https://*.iovation.com/snare.js
Klarna https://*.klarnacdn.net/kp/lib/v1/api.js
PayPal https://*.paypal.com/da/r/fb.js
Affirm https://*.affirm.com/js/v2/affirm.js
Amazon Pay https://*.payments-amazon.com/checkout.js
Oney https://*.oney.io/build/loader.min.js
After Pay https://*.afterpay.com/afterpay.js
Mastercard https://src.mastercard.com/srci/integration/2/lib.js,
https://src.mastercard.com/srci/integration/components/src-ui-kit/src-ui-kit.esm.js
RatePay https://d.ratepay.com/*/di.js
RocketFuel https://d3rpjm0wf8u2co.cloudfront.net/static/rkfl.js
SamsungPay https://d35p4vvdul393k.cloudfront.net/sdk_library/us/stg/ops/pc_gsmpi_web_sdk.js,
https://d16i99j5zwwv51.cloudfront.net/sdk_library/us/prd/ops/pc_gsmpi_web_sdk.js
Sezzle https://checkout-sdk.sezzle.com/checkout.min.js
Yandex https://yookassa.ru/checkout-widget/v1/checkout-widget.js
Google https://pay.google.com/gp/p/js/pay.js
Apple https://applepay.cdn-apple.com/jsapi/v1.1.0/apple-pay-sdk.js
Alirisk https://cdn10.ebuckler.com/ebuckler.widget.js,https://stats.ebuckler.com/js/ebuckler.widget.js
Masterpass https://*.masterpass.com/lightbox/Switch/integration/MasterPass.client.js

Please note that, depending on the integration, this list is related only to SecurePay and may not be the full list of scripts that are loaded on the website.

Monitoring and Detection

Customers need to implement monitoring and detection themselves to be PCI SAQ-A compliant with the payment widget.

  • Implement Monitoring: Set up monitoring tools to detect any unauthorized access or anomalies.
  • Regular Reviews: Conduct regular reviews of the monitoring logs to identify and address potential security issues.

Credentials compliance

Ensure seamless PCI DSS 4.x compliance for UI passwords and API Bearer tokens.

How it works

1

Updates in PCI DSS 4.x

Discover the new requirements introduced in PCI DSS 4.x.

2

How to comply

Learn how our product meets these new requirements.

3

Actions required

Find out what actions you need to take as a merchant or Payment Service Provider (PSP).

1. Updates in PCI DSS 4.x

PCI DSS 4.x introduces new requirements to better protect credentials (passwords or API tokens), including the establishment and management of strong authentication for users and administrators.

Requirement 8.3.6If passwords/passphrases are used as authentication factors, they meet the following minimum level of complexity:
  • A minimum length of 12 characters.
  • Contain both numeric and alphabetic characters.

Show requirement details

Purpose
Strong passwords/passphrases may be the first line of defense into a network since a malicious individual will often first try to find accounts with weak, static, or non-existent passwords. If passwords are short or easily guessable, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID.

Good practice
Password/passphrase strength is dependent on password/passphrase complexity, length, and randomness. Passwords/passphrases should be sufficiently complex, so they are impractical for an attacker to guess or otherwise discover its value. Entities can consider adding increased complexity by requiring the use of special characters and upper- and lower-case characters, in addition to the minimum standards outlined by this requirement. Additional complexity increases the time required for offline brute force attacks of hashed passwords/passphrases.

2. How to comply

To meet PCI DSS v4.x Requirement 8.3.6, our product enhances password security and transitions to hashed credentials.

  • We have already improved password complexity and update frequency. UI user account passwords must be at least 12 characters long, containing both numeric and alphabetic characters, and must be updated every 42 days in both UAT and Production environments.
  • To further enhance security, we are working on hashing credentials for both passwords and API Bearer tokens. This transition from encryption to hashing will ensure that passwords are complex, lengthy, and random, preventing attackers from easily guessing or discovering them.

3. Actions Required

  • UI User Passwords: Users must save their UI user account passwords securely (e.g., in a key store). If the password is not properly and securely saved, the user will need to request a new one from the master user account administrator.
  • API Bearer Tokens: Customers must securely store the API Bearer token upon creation of a merchant entity via UI or merchant onboarding API. If the access token is not properly and securely saved, the user will need to create a new SYSTEM user to generate a new API Bearer token. There is always a 1-to-1 mapping between a SYSTEM user used in processing and the API Bearer token.
Please prepare for the upcoming transition to hashed credentials to stay ahead of compliance requirements.