PCI DSS

What is PCI DSS?

PCI DSS stands for the Payment Card Industry Data Security Standard a set of security requirements established by the Payment Card Industry Security Standards Council (PCI SSC) that governs how organisations store, process, and transmit payment card data. Compliance is contractually mandated by the major card brands including Visa, Mastercard, American Express, Discover, and JCB for any organisation that handles cardholder data.

Unlike GDPR or HIPAA, PCI DSS is not a government regulation. It's an industry-enforced contractual requirement. Non-compliance doesn't directly produce regulatory fines, but it can result in card brand penalties, increased transaction fees, suspension of card processing privileges, and significant financial liability following a breach particularly if a forensic investigation determines that PCI DSS controls were inadequate at the time.

That distinction matters for understanding the enforcement mechanism. PCI DSS compliance is validated through a combination of annual assessments, self-assessment questionnaires, and quarterly vulnerability scans. The consequence of failing isn't a government fine it's losing the ability to accept card payments, or bearing full liability for breach-related losses.

What PCI DSS protects: cardholder data vs sensitive authentication data

PCI DSS governs two categories of payment card information with different storage and handling rules.

Cardholder data (CHD) includes the primary account number (PAN) the 16-digit card number plus the cardholder name, expiration date, and service code. The PAN is the primary protection target: it's what makes cardholder data valuable to attackers and what most PCI controls are designed to protect.

Sensitive authentication data (SAD) includes full magnetic stripe data, card verification codes (CVV/CVV2/CVC/CID), and PINs. SAD cannot be stored after transaction authorisation under any circumstances, even if encrypted. The prohibition is absolute and does not depend on encryption or tokenisation status.

The distinction creates a practical compliance architecture: cardholder data may be stored if adequately protected, but sensitive authentication data must never be retained post-authorisation. Many PCI enforcement actions involve organisations that stored CVV codes or full magnetic stripe data without realising that post-authorisation retention of those elements is categorically prohibited.

The 12 PCI DSS requirements

PCI DSS v4.0 (the current version as of 2024) organises its requirements across six goals and 12 requirements. Understanding the structure helps practitioners map their programme against the standard.

Build and maintain a secure network and systems

Requirement 1 covers installing and maintaining network security controls — firewalls and equivalent technology that separate the cardholder data environment from untrusted networks. Requirement 2 covers applying secure configurations to all system components, eliminating vendor defaults, and disabling unnecessary functionality.

Protect account data

Requirement 3 covers protecting stored account data through encryption, truncation, or tokenisation. PAN must be rendered unreadable anywhere it's stored. Requirement 4 covers protecting cardholder data with strong cryptography during transmission over open, public networks — TLS 1.2 or higher is the current standard.

Maintain a vulnerability management programme

Requirement 5 covers protecting all systems against malware with anti-malware solutions. Requirement 6 covers developing and maintaining secure systems and software, including patch management and security testing for in-house developed applications.

Implement strong access control measures

Requirement 7 covers restricting access to system components and cardholder data by business need to know — the principle of least privilege applied to PCI scope. Requirement 8 covers identifying users and authenticating access to system components with unique IDs, strong authentication, and MFA for remote access. Requirement 9 covers restricting physical access to cardholder data.

Regularly monitor and test networks

Requirement 10 covers logging and monitoring all access to system components and cardholder data. Audit logs must be retained for at least 12 months with three months immediately available for analysis. Requirement 11 covers testing security systems and processes through vulnerability scanning, penetration testing, and intrusion detection.

Maintain an information security policy

Requirement 12 covers supporting information security with organisational policies and programmes, including risk assessment, security awareness training, incident response planning, and third-party risk management.

PCI DSS compliance levels: what applies to your organisation

PCI DSS compliance requirements and validation methods vary based on transaction volume. Four merchant levels apply.

Level 1 merchants process more than 6 million card transactions annually. They require an annual on-site assessment by a Qualified Security Assessor (QSA) producing a Report on Compliance (ROC), quarterly network scans by an Approved Scanning Vendor (ASV), and penetration testing.

Level 2 merchants process 1 to 6 million transactions annually. They may complete an annual Self-Assessment Questionnaire (SAQ) or choose an annual on-site assessment, along with quarterly ASV scans.

Level 3 merchants process 20,000 to 1 million e-commerce transactions annually. They complete an annual SAQ and quarterly ASV scans.

Level 4 merchants process fewer than 20,000 e-commerce transactions or up to 1 million total transactions annually. They complete an annual SAQ and quarterly ASV scans, though specific requirements may vary by acquirer.

Service providers — organisations that process, store, or transmit cardholder data on behalf of merchants — have their own tiering based on transaction volume and the sensitivity of their role in the payment chain.

The scope problem: why PCI compliance is harder than it looks

The single most important concept in PCI DSS compliance for practitioners is scope. Every system, network segment, person, and process that stores, processes, or transmits cardholder data or that could affect the security of that data is in scope for PCI DSS. Every requirement in the standard applies to every in-scope component.

Scope is where PCI compliance programmes succeed or fail. An organisation that correctly implements all 12 requirements against a well-defined, accurate scope achieves compliance. An organisation that implements all 12 requirements but has cardholder data appearing in out-of-scope systems — shadow data in a development database, PAN appearing in log files, card numbers captured in a customer support ticketing system fails compliance regardless of how well-controlled the formal CDE is.

That's the scope creep problem. Cardholder data appears in places it wasn't supposed to. A developer exported a sample of transaction records to test a new feature. An application writes card numbers to a debug log that nobody thought to check. A legacy system that was supposed to be decommissioned is still receiving card data from an old integration. A customer service agent copied a card number into a support ticket.

Each of these creates an out-of-scope system that is now actually in scope because it contains cardholder data. If the QSA discovers it during an assessment, or if a forensic investigator finds it following a breach, the compliance programme has a material gap.

The solution: continuous discovery specifically looking for PAN appearing in systems outside the defined CDE. Pattern-based PCI data discovery scans for 16-digit numbers matching card formats across all environments not just the production payment systems where card data is supposed to live. Finding card data where it shouldn't be before the QSA does, or before an attacker does, is the most operationally valuable PCI capability beyond the 12 requirements themselves.

What PCI DSS compliance requires for data security

The 12 requirements translate into specific data security programme needs that go beyond implementing firewall rules and patching schedules.

Accurate, current cardholder data inventory

Knowing exactly which systems contain PAN is the foundation of scope definition. That inventory must be current new systems are provisioned, new integrations appear, and data moves continuously. Periodic scanning catches what existed at the time of the scan. Continuous automated discovery catches cardholder data appearing in systems between scans.

PAN discovery outside the CDE

Scanning for PAN in development environments, analytics platforms, log files, support systems, and collaboration tools everywhere card data might have drifted is the operational control that keeps scope boundaries defensible. Discovery that only covers the defined CDE confirms what's in the CDE. Discovery that covers the entire environment confirms what's outside it.

Immutable audit logging with sufficient retention

Requirement 10's logging provisions require retaining audit logs for at least 12 months with three months immediately available. Logs must be tamper-resistant, centrally managed, and reviewed regularly. The logging requirement creates the evidence base for both compliance validation and breach investigation.

Access reviews demonstrating least privilege

Requirement 7's need-to-know requirement needs operational validation: who currently has access to which systems containing cardholder data, is that access scoped to their business function, and has access been revoked when roles change or individuals leave. Manual access reviews that run annually miss the access drift that occurs between reviews.

Continuous posture monitoring for configuration drift

PCI requirements include secure configurations, encryption of stored PAN, network security controls, and access controls. Those configurations change as systems are updated and infrastructure is provisioned. A system that was compliant at assessment time may drift out of compliance before the next assessment. Continuous monitoring that detects configuration changes affecting PCI scope is the control that closes that gap.

Frequently asked questions

What does PCI DSS stand for?

PCI DSS stands for Payment Card Industry Data Security Standard. It's a set of security requirements established by the PCI Security Standards Council founded by Visa, Mastercard, American Express, Discover, and JCB governing how organisations store, process, and transmit payment card data.

Who must comply with PCI DSS?

Any organisation that stores, processes, or transmits payment cardholder data must comply with PCI DSS. This includes merchants of all sizes, payment processors, acquirers, issuers, and service providers involved in payment card transactions. Compliance requirements and validation methods vary by transaction volume through four merchant levels.

What are the 12 PCI DSS requirements?

The 12 requirements cover network security controls, secure configurations, protecting stored account data, encryption of data in transit, malware protection, secure software development, least-privilege access control, user identification and authentication, physical access controls, audit logging and monitoring, security testing, and organisational security policies.

What is the cardholder data environment (CDE)?

The cardholder data environment is the combination of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data including any system components, network infrastructure, or third parties that could affect the security of that data. All 12 PCI DSS requirements apply to every component in the CDE.

What are the penalties for PCI DSS non-compliance?

PCI DSS non-compliance can result in card brand penalties imposed through acquirers (typically ranging from $5,000 to $100,000 per month depending on the severity and duration of non-compliance), increased transaction processing fees, and suspension of card processing privileges. Following a breach, non-compliant organisations may bear full liability for fraud losses and forensic investigation costs that would otherwise be shared with card brands.