PCI DSS Compliance and Security Guide

Security in electronic transactions is essential to protect businesses and consumers in the digital environment. This guide presents best practices and standards that ensure secure transactions and regulatory compliance, strengthening user trust and mitigating operational and reputational risks.

Payment Processing Compliance: What You Need to Know

The rapid growth of digital payments has opened up a world of opportunities for businesses but also introduced new risks. As online transactions increase, it becomes critical for companies to comply with international data security and protection standards. This compliance is not only a legal requirement—it is a fundamental pillar for building user trust and ensuring business continuity.

Why Is Compliance with Standards Essential?

In an environment where electronic payments move trillions of dollars each year, threats like fraud and data breaches are increasingly frequent and sophisticated. Failing to comply with regulations can lead to serious consequences: financial penalties, loss of credibility, service disruption, and even legal actions.

Protecting cardholder information, especially financial data, is not optional—it’s a shared responsibility among merchants, payment processors, and technology platforms.

PCI DSS 4.0 Fundamentals

Complying with international standards such as PCI DSS 4.0 (Payment Card Industry Data Security Standard) is essential to ensure transaction security and avoid legal sanctions.

Key PCI DSS Requirements

The PCI DSS standard establishes a set of mandatory measures that organizations must adopt to protect payment card data. These requirements are designed to strengthen security infrastructure, reduce fraud risks, and ensure the integrity of electronic transactions.

  1. Secure network: Implementation of firewalls and secure passwords.
  2. Cardholder data protection: Encrypted data storage and restricted access to authorized personnel.
  3. Vulnerability management: Regular software updates to prevent attacks.
  4. Access control: Only necessary staff have access to card data, and access is monitored.
  5. Ongoing monitoring and testing: Periodic audits to identify and address vulnerabilities.
  6. Comprehensive security policy: Implementation of security policies and continuous training for all personnel handling sensitive data.

Scoping and Segmentation in PCI DSS

With the release of PCI DSS version 4.0, organizations face new challenges and opportunities in their compliance strategies. Digital transformation has brought increasingly dynamic environments: multi-cloud infrastructures, Zero Trust architectures, and network virtualization—all requiring a reevaluation of PCI DSS scoping and technical measures to protect cardholder data.

Scoping in PCI DSS v4.0

In previous versions, PCI DSS scope focused mainly on systems that processed, stored, or transmitted card data. PCI DSS v4.0 takes a broader and more precise approach:

  • It includes systems and processes that may impact the security of card data, even if they do not handle the Primary Account Number (PAN) or Sensitive Authentication Data (SAD) directly.
  • Systems with direct connectivity to the Cardholder Data Environment (CDE) are considered in scope.
  • Components excluded from scope must be effectively isolated and validated through network segmentation testing.
  • This validation must be documented and renewed periodically as part of the compliance lifecycle.

Segmentation to Reduce PCI Scope

Network segmentation remains a key tool to limit compliance scope and reduce risks, but it must be adapted to modern technology environments. Several strategies exist, depending on the architecture type:

  1. Traditional segmentation (physical or logical network)
  • Use of firewalls, routers, VLANs, ACLs, etc.
  • Still valid in on-premise, hybrid, or cloud environments.
  1. Segmentation in Zero Trust architectures
  • Based on granular access policies, microsegmentation, and identity, device, and context-based control.
  • Every access is dynamically evaluated—trust is not assumed based on network location.
  • Requires continuous monitoring, device validation, and strong identity management.
  1. Segmentation in multi-cloud environments
  • Involves controlling traffic between different CSPs (Cloud Service Providers) using VPNs, private links, cloud-native firewalls, proxies, and service mesh.
  • It’s recommended to apply host- or app-level controls (e.g., microservices, containers, API gateways, etc.).
  • Centralized visibility into data flows, configuration, and changes (Infrastructure as Code - IaC) is vital.
  1. Mandatory penetration testing
  • Any segmentation used to reduce scope must be tested through pentesting.
  • Penetration tests must be performed from outside systems capturing card data (e.g., e-commerce platforms, gateways).

Data Tokenization: Protecting the PAN

Tokenization is a security technique that replaces the real card number (PAN) with a token that has no intrinsic value. This allows transactions to be processed or references to be stored without compromising the PAN and protects sensitive data in case of a token leak.

According to the Tokenization Product Security Guidelines, there are two main types of tokens:

Irreversible Tokens

  • Generated using one-way mathematical functions.
  • Cannot be reverted to the original PAN.
  • Useful when PAN recovery is not needed (e.g., for analytics or backoffice storage).

Reversible Tokens

  • PAN recovery is possible if certain security requirements are met.
  • Used in centralized tokenization models requiring detokenization (e.g., for reconciliations or refunds).
  • Require secure key management and multi-factor authentication to access original data.
  • FIPS 140-2 Level 2 or 3 validation, depending on whether it’s a software or hardware solution.
  • Clear separation between tokens and original PAN data.
  • Access monitoring, event auditing, and cryptographic protection of tokens.
  • Strong authentication, role-based access control, and isolation of token vaults.

PCI DSS Compliance Levels and Methods

Compliance with the PCI DSS standard varies depending on the type of entity (merchant or service provider) and its annual transaction volume. The standard classifies organizations into different levels, each with specific assessment requirements such as external audits, self-assessments, or technical scans.

A key element to validate technical compliance is using an ASV (Approved Scanning Vendor)—a PCI Security Standards Council–certified organization that performs vulnerability scans on internet-exposed systems. These scans help:

  • Detect insecure configurations or vulnerable software.
  • Validate compliance with PCI DSS v4.0 requirement 11.3.2.
  • Issue official reports used in evaluation processes such as the AOC (Attestation of Compliance) or SAQ (Self-Assessment Questionnaire).

Below are the different compliance levels and applicable evaluation methods.

Compliance Levels for Merchants

Organizations that process card transactions are grouped into four levels based on annual transaction volume, which determines their compliance requirements.

Compliance Level Annual Transaction Volume Assessment Requirements
Level 1 More than 6 million Visa/MasterCard transactions or more than 2.5 million American Express transactions
  • Annual external audit (QSA)
  • Quarterly vulnerability scan (ASV)
  • Annual compliance report (AOC and ROC)
  • Level 2 Between 1 and 6 million transactions
  • Annual self-assessment (SAQ) or external audit
  • Quarterly vulnerability scan (ASV)
  • Level 3 Between 20,000 and 1 million transactions
  • Annual self-assessment (SAQ)
  • Quarterly vulnerability scan (ASV)
  • Level 4 Fewer than 20,000 transactions
  • Annual self-assessment (SAQ)
  • Quarterly vulnerability scan (ASV, as required by the acquiring bank)
  • Compliance Levels for Service Providers

    Service providers are grouped into two levels based on relevance and transaction volume:

    Compliance Level Annual Transaction Volume Assessment Requirements
    Level 1 More than 300,000 transactions or considered critical
  • Annual audit by a QSA or ISA
  • Quarterly vulnerability tests (ASV)
  • Annual penetration testing
  • Level 2 Fewer than 300,000 transactions
  • Self-assessment questionnaire (SAQ)
  • Quarterly vulnerability tests (ASV)
  • Evaluation Methods

    • Self-Assessment Questionnaire (SAQ): Self-assessment to validate compliance for lower-level merchants and providers.
    • Report on Compliance (RoC): Annual audit for Level 1 providers, documenting compliance.
    • Attestation of Compliance (AoC): Signed document confirming PCI DSS compliance after audit or self-assessment.

    Comprehensive Data Security Strategies

    Online fraud is a constant threat for any electronic transaction platform. To minimize risks and protect customer data, implement these key security practices:

    • Reinforce authentication with 2FA: Require an additional layer of authentication (such as a code sent to a mobile device or MFA method) to prevent unauthorized access and fraudulent transactions.
    • Secure communications with advanced encryption: Ensure all client-server communications are encrypted with TLS 1.2 or 1.3 to protect sensitive data like credit card information from interception.
    • Actively monitor suspicious transactions: Use fraud detection algorithms to identify unusual patterns, such as frequent transactions in a short period or from atypical locations.
    • Protect sensitive data with tokenization: Replace sensitive data, like card numbers, with alphanumeric tokens with no intrinsic value. This safeguards the information in case of unauthorized access.

    Ensuring Customer Data Integrity

    Implementing best security practices, in addition to complying with standards, is essential to maintain the integrity and confidentiality of customer data. Key measures include:

    • Frequent backups: Enable system restoration with minimal data loss in the event of an incident.
    • Role-Based Access Control (RBAC): Limit access to data based on employee roles, reducing misuse risk.
    • Transparent privacy policy: Clearly explain to customers how their information is handled and protected to build trust in your platform.

    Additional Resources

    Last modified July 18, 2025: Documentation updates (4f4830fa0)