PCI-DSS

PCI DSS (Payment Card Industry Data Security Standard) is a set of rules that any company handling card data must follow. It is developed and maintained by the PCI Security Standards Council (PCI SSC) — a council founded by Visa, Mastercard, American Express, Discover, and JCB. The standard says how to protect cardholder data at companies that store, process, or transmit it. The current version is PCI DSS v4.0.1, published on June 11, 2024; it replaced v4.0, which was retired on December 31, 2024. All the rules are organized into 12 requirements grouped under 6 control objectives (goals).

What is PCI DSS and who enforces it?

PCI DSS is not law — it is a standard that applies through contracts. A company has to follow it because it agreed to in its contract with a card brand and an acquiring bank (acquirer). The PCI SSC writes and updates the standard, but enforcement and penalties are handled by the individual card brands (Visa, Mastercard, and others) and acquirers.

The standard applies to two groups. Merchants are sellers that accept card payments. Service providers are companies that affect the security of card data — for example payment gateways, transaction processors, and hosting providers.

A key concept is the CDE (Cardholder Data Environment). It covers all systems, networks, and components that store, process, or transmit card data (the card number plus sensitive authentication data), as well as systems directly connected to them or able to affect them. Every assessment starts by carefully defining the boundaries of the CDE (this is called scoping).

What data does PCI DSS protect?

The standard splits protected data into two categories:

• Cardholder data (CHD) — the full card number (PAN, Primary Account Number), cardholder name, expiration date, and service code. The PAN may only be stored in an unreadable form — masked, tokenized, or encrypted per Requirement 3.
• Sensitive authentication data (SAD) — full track data, the card verification code (CAV2/CVC2/CVV2/CID), and the PIN or PIN block. SAD must not be stored after authorization of the transaction — not even encrypted.

What are the 12 PCI DSS requirements and 6 goals?

PCI DSS v4.0.1 requirements are grouped under six overarching goals:

Goal 1 — Build and maintain a secure network and systems

1. Requirement 1: network security controls (firewalls and segmentation).
2. Requirement 2: secure configurations for all system components (remove vendor defaults).

Goal 2 — Protect account data

1. Requirement 3: protect stored account data (encryption, masking, tokenization, key management).
2. Requirement 4: protect data with strong cryptography while it travels over open, public networks (e.g., TLS).

Goal 3 — Maintain a vulnerability management program

1. Requirement 5: protect systems and networks from malicious software.
2. Requirement 6: develop and maintain secure systems and software (patch management, secure development).

Goal 4 — Strong access control

1. Requirement 7: give access to systems and card data only to those who genuinely need it (need-to-know).
2. Requirement 8: identify users and authenticate access (including MFA, multi-factor authentication).
3. Requirement 9: restrict physical access to cardholder data.

Goal 5 — Regularly monitor and test networks

1. Requirement 10: log and monitor all access to systems and card data (logging, audit trails, event correlation).
2. Requirement 11: test security regularly (vulnerability scanning, penetration testing, change detection).

Goal 6 — Maintain an information security policy

1. Requirement 12: support security with organizational policies and programs (risk assessment, training, incident response, third-party oversight).

What changed in PCI DSS v4.0 and v4.0.1?

Version v4.0 (March 2022) was a major change over v3.2.1. It introduced, among others:

• Customized approach: alongside the classic defined approach (meeting requirements literally), a company may reach the security objective through its own controls, as long as it backs this up with a targeted risk analysis.
• Expanded multi-factor authentication (MFA): MFA is required for all access into the CDE, not only for remote administrative access.
• Future-dated requirements: some new requirements were best practice until March 31, 2025, becoming mandatory from that date — e.g., expanded MFA, longer passwords, targeted risk analyses, and change/tamper detection on payment pages.

Version v4.0.1 is a limited maintenance revision. It adds no new requirements — it corrects editorial errors, clarifies applicability notes (e.g., for Requirements 3, 6, 8, and 12), refines service-provider obligations toward customers, and moves sample templates to the PCI SSC document library. After v4.0 was retired at the end of 2024, v4.0.1 is the only active version.

How is compliance validated: merchant levels, SAQ, ROC, and AOC?

The method used to validate compliance depends on the merchant level. The level is determined mainly by annual transaction volume, although detailed thresholds are defined by individual payment card brands. A commonly used classification is:

• Level 1: more than 6 million transactions per year, regardless of sales channel (or following a data breach). Requires an annual assessment by a QSA (Qualified Security Assessor) or internal auditor (ISA) and preparation of a ROC.
• Level 2: between 1 million and 6 million transactions per year, regardless of sales channel.
• Level 3: between 20,000 and 1 million e-commerce transactions per year.
• Level 4: fewer than 20,000 e-commerce transactions per year; this level may also include merchants with a lower total transaction volume, depending on the rules of the relevant payment card brand.

Validation documents:

• SAQ (Self-Assessment Questionnaire) — a self-assessment for smaller entities (typically Levels 2–4). It comes in several types (A, A-EP, B, B-IP, C, C-VT, P2PE, D), chosen by acceptance method and CDE scope.
• ROC (Report on Compliance) — a full assessment report produced by a QSA, usually required for Level 1.
• AOC (Attestation of Compliance) — the formal attestation of compliance. It results from either an SAQ or a ROC and is the document submitted to the acquirer or partners.

Regardless of level, many companies must also run quarterly vulnerability scans by an ASV (Approved Scanning Vendor) for internet-facing systems.

Why does PCI DSS matter for security and network monitoring?

From a security team’s perspective, PCI DSS turns business and contractual requirements into concrete technical controls. Many of them can be checked directly in a SOC/NDR context and through network monitoring:

• Segmentation and traffic control (Req. 1): good segmentation shrinks the CDE and makes an attacker’s lateral movement harder. Flow data and firewall logs let you confirm that only authorized traffic crosses CDE boundaries — and reveal attempts to bypass them.
• Logging and monitoring (Req. 10): requires recording access to card data, time synchronization, log protection, and daily review. In practice this is done with SIEM and event correlation. It underpins abuse detection and post-breach analysis.
• Testing and change detection (Req. 11): vulnerability scanning, penetration testing, IDS/IPS, and detection of unauthorized changes — including swapped scripts on payment pages (protection against e-skimming/Magecart attacks).
• Exfiltration detection: watching the network for unusual outbound connections and data transfers helps catch attempts to extract card data, which the standard forbids storing in readable form.

Compliance is not the same as security. Meeting PCI DSS describes a single point in time, while real protection requires continuous visibility and monitoring of the environment — something the standard itself invokes in Requirements 10 and 11.

What are the consequences of non-compliance with PCI DSS?

Penalties do not come from PCI SSC rules but from agreements with card brands and acquirers. In practice they may include: fines imposed by card brands on the acquirer (and passed on to the merchant), higher transaction fees, and in extreme cases loss of the ability to accept cards. After a breach there are additional costs for forensic investigation, notifications, card reissuance, plus possible civil liability and penalties under separate regulations (e.g., GDPR).

Learn more

• Data Loss Prevention (DLP) — DLP helps protect card data by detecting and blocking unauthorized data transfers under PCI-DSS.
• DORA — DORA overlaps with PCI-DSS in requiring strong security controls and incident response for sensitive data.
• Volumetric Attack — Volumetric attacks can disrupt payment systems, making PCI-DSS availability protections important.