PCI DSS 4.0: everything your company needs to know to protect cardholder data

What PCI DSS is and who must comply

PCI DSS — Payment Card Industry Data Security Standard — is a technical standard created in 2004 and maintained by the PCI Security Standards Council (PCI SSC), a consortium formed by Visa, Mastercard, American Express, Discover and JCB. Its goal is to establish a minimum level of protection for the card payment ecosystem on a global scale.

The obligation to comply with PCI DSS does not depend on the size of the company or on a specific regulatory act: it arises from the contract with the acquirer (such as Cielo, Rede or Stone) and from the rules of the card brands themselves. Any organization that stores cardholder data (PAN number, expiration date, cardholder name), processes payment transactions or transmits this data over its networks is in scope — whether a payments startup, an e-commerce, a Central Bank-regulated fintech, a SaaS company that manages billing or a service provider that hosts third-party systems.

In practice, this includes: acquirers, payment gateways, payment facilitators (PayFacs), service providers that touch card data, e-commerce operators with their own checkout and mobile apps that capture card data directly. Outsourcing processing to a PSP or using a certified gateway reduces scope, but does not eliminate liability — the company still needs to demonstrate compliance for the portion of the journey that remains under its control.

The 12 PCI DSS requirements explained

PCI DSS organizes its controls into 12 requirements grouped under six control objectives. The first objective — build and maintain a secure network and systems — covers requirements 1 and 2: install and maintain network security controls (firewall, access lists, segmentation) and apply secure configurations to all system components, eliminating vendor default credentials and unnecessary functionality.

The second objective deals with the protection of account data (requirements 3 and 4). Requirement 3 requires stored cardholder data to be minimized and, when necessary, protected by strong encryption, hashing or truncation — with the storage of the security code (CVV/CVC) after authorization being expressly prohibited. Requirement 4 mandates encryption in transit with modern protocols (TLS 1.2 at a minimum, preferably TLS 1.3) for all transmission of card data over public networks.

The third objective addresses maintaining a vulnerability management program (requirements 5 and 6): protecting all systems against malware with up-to-date solutions, and developing and maintaining secure systems and software, including remediation of identified vulnerabilities within defined timeframes by criticality and verification of the code of internet-facing applications.

The fourth objective covers access controls (requirements 7, 8 and 9). Requirement 7 limits access to account data based on the principle of least privilege. Requirement 8 — deeply reworked in v4.0 — requires unique identification per user, mandatory multi-factor authentication (MFA) for all access to the CDE and passwords with defined complexity and rotation. Requirement 9 controls physical access to systems that store or process card data, including cameras, visitor logs and media protection.

The fifth objective deals with monitoring and testing (requirements 10 and 11): logging of all access to network resources and card data with a minimum retention of 12 months, and regular security testing including quarterly vulnerability scans by an approved ASV and annual penetration tests (internal and external) covering network segmentation. The sixth objective, requirement 12, requires a documented, maintained information security policy communicated to all stakeholders, as well as a formal risk management program, vendor management and incident response.

Merchant levels and the type of validation required

The card brands classify merchants into four levels according to the annual volume of transactions processed. Level 1 comprises companies that process more than 6 million transactions per year with Visa or Mastercard, or those that have already suffered a card data breach — regardless of volume. For this group, compliance must be validated annually by a Qualified Security Assessor (QSA), an external auditor certified by the PCI SSC, who performs a detailed, on-site Report on Compliance (RoC).

Levels 2, 3 and 4 serve companies with smaller volumes — between 1 and 6 million, between 20,000 and 1 million, and below 20,000 annual transactions, respectively. These levels allow self-assessment through Self-Assessment Questionnaires (SAQ), documents segmented by environment type: SAQ A covers merchants that fully outsource processing; SAQ A-EP includes e-commerces with a redirect; SAQ D, the most comprehensive, applies to any merchant that does not fit the other profiles. All levels require quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) and the submission of an Attestation of Compliance (AoC) to the acquirer.

Service providers — companies that process, store or transmit card data on behalf of third parties — follow their own level table and generally face stricter requirements. A level 1 service provider handling more than 300,000 card transactions per year needs a full RoC by a QSA. Correctly identifying the appropriate level and SAQ is the first step of any compliance program.

What's new in PCI DSS 4.0 and 4.0.1

Published in March 2022, version 4.0 of PCI DSS was the largest revision since the standard was created. The main conceptual change is the introduction of the 'Customized Approach': instead of strictly following the prescriptive implementation of each control, the organization can demonstrate to the QSA that it has achieved the security objective through alternative controls, provided it documents the approach, performs a risk analysis and validates its effectiveness. This makes room for companies with modern architectures (cloud-native, zero trust, serverless) to comply without forcing controls designed for traditional on-premises environments.

In the area of authentication, requirement 8 received substantial updates: MFA became mandatory for all interactive access to the CDE — not just for remote administrators, as v3.2.1 provided — and password requirements were tightened. Requirement 6 incorporated specific controls for client-side attacks: payment page scripts must be inventoried, have their integrity verified and be monitored to detect unauthorized modifications — a direct measure against JavaScript skimming attacks (Magecart).

Version 4.0.1, released in June 2024, brought language corrections, scope clarifications and adjustments to requirements marked as 'best practice until 31 March 2025.' As of March 31, 2025, all v4.0 requirements became mandatory. The transition deadlines from v3.2.1 to 4.0 have already expired — companies still validating against the previous version are technically out of compliance.

Scope, segmentation and the relationship with the LGPD and the Central Bank

The concept of scope defines which systems, networks and processes need to be covered by the PCI DSS controls. The primary scope is the Cardholder Data Environment (CDE) — the components that store, process or transmit account data. In addition, any system that may impact the security of the CDE (connected-to or security-impacting) also falls within scope, even if it does not directly handle card data.

Network segmentation is the main strategy for reducing scope. When properly implemented — through firewalls, VLANs or micro-segmentation — it isolates the CDE from the rest of the corporate infrastructure, limiting the attack surface and the number of systems subject to audit. Segmentation must be tested at least annually and whenever significant infrastructure changes occur. Poorly implemented segmentation is one of the most common findings in PCI environment penetration tests and can result in the unexpected expansion of scope during the audit.

In Brazil, PCI DSS coexists with the LGPD (Law 13,709/2018) and with the Central Bank's regulations, especially CMN Resolution 4,893/2021 on cybersecurity policy for financial institutions. The three frameworks are complementary: card data is financial personal data, and the PCI controls — minimization, encryption, access control, incident notification — simultaneously meet the LGPD's requirements. For regulated fintechs, PCI compliance also helps demonstrate to the Central Bank the maturity of the cybersecurity program required. An integrated program that addresses the three frameworks in a unified way is more efficient and less costly than three parallel initiatives.

Penalties, risks and how Decripte supports your compliance

Non-compliance with PCI DSS does not directly generate fines from a government body, but the consequences are equally severe. The card brands may apply monthly fines to the acquirer — which passes them on to the merchant — ranging from US$ 5,000 to US$ 100,000 per month while the non-compliance persists. In the event of a confirmed data breach, the company may lose the right to accept cards of the affected brand, bear the costs of a PFI (PCI Forensic Investigator) forensic investigation, pay for the reissuance of compromised cards and be held liable for fraud in a massive chargeback process.

Beyond the immediate financial impact, a card data breach causes long-lasting reputational damage, civil liability toward data subjects (under the LGPD) and potential regulatory liability toward the Central Bank for fintechs. For e-commerces, the loss of accreditation is equivalent to the total interruption of online sales.

Decripte offers full support for the PCI DSS compliance cycle: scope and segmentation assessment, gap assessment against the v4.0 requirements, penetration testing of the cardholder data environment performed by certified professionals, support in building policies and evidence for the QSA, and continuous monitoring of the compliance posture. We serve companies of all sizes — from the early-stage e-commerce to the level 1 service provider — with plans that fit the transaction volume and the complexity of the environment. To get started, access the free threat management plan or explore the complete compliance plans.

How to comply

1. 1

   1. Determine your scope and merchant level

   Map all card data flows in your organization — where they are captured, how they travel, where they are stored or processed — and identify all systems that touch or may influence the CDE. Based on the annual transaction volume, determine your level (1 to 4) and the type of validation required (RoC by QSA or a specific SAQ). This mapping is the foundation of the entire compliance program.

2. 2

   2. Implement network segmentation to isolate the CDE

   Separate the CDE systems from the rest of the corporate network with well-documented firewalls, VLANs or micro-segmentation. Reduce the authorized flows between the CDE and other networks to a minimum, and document each firewall rule with a business justification. Correct segmentation can reduce PCI DSS scope from dozens of systems to only those strictly necessary for payment processing.

3. 3

   3. Apply secure configurations and manage vulnerabilities

   Eliminate default credentials, disable unnecessary services and apply a documented hardening baseline to all CDE components. Establish a formal patch management process with remediation deadlines based on vulnerability criticality — critical ones within 30 days. Hire an approved ASV to perform quarterly external scans and fix all findings before submitting the results to the acquirer.

4. 4

   4. Strengthen authentication and access control

   Implement MFA for all interactive access to the CDE — administrators, developers, support analysts and any account with remote access. Adopt the principle of least privilege: each user or service should have only the permissions strictly necessary. Ensure unique IDs per user (never shared accounts), robust password policies and a formal process for reviewing and revoking access.

5. 5

   5. Protect data at rest and in transit

   Assess which card data is genuinely necessary to store — the CVV must never be retained after authorization. Data that needs to be stored must be protected with strong encryption (AES-256) or tokenization. All card data transmissions over public networks must use TLS 1.2 or higher. Inventory all certificates and monitor their validity to avoid inadvertent expiration.

6. 6

   6. Enable logging, monitoring and perform penetration testing

   Configure centralized logging of all access, authentication events and configuration changes in the CDE, with a minimum retention of 12 months. Implement alerts for suspicious events and review logs regularly. Perform annual penetration tests covering the external network, the internal CDE network and — mandatorily — the effectiveness of segmentation. Hire professionals who use recognized methodologies (PTES, OWASP) and produce traceable reports for the audit.

7. 7

   7. Document, train and validate with a QSA or SAQ

   Produce and keep up to date the information security policies, operating procedures and risk analyses required by requirement 12. Train all employees who interact with card data at least annually. With all documentation and evidence in hand, complete the SAQ corresponding to your profile or undergo the audit by the QSA. Submit the signed AoC to the acquirer within the deadline defined in the contract.

Frequently asked questions