PCI DSS

Name: Payment Card Industry Data Security Standard (PCI DSS)

Type: Framework

Authoritative Source: PCI Security Standards Council

Certification Available: No. However, the PCI Security Standards Council has a conformity program that it maintains, where a Quality Security Assessor (QSA) may issue a Report on Compliance (ROC) for Level 1 merchants and service providers (and some Level 2 merchants under certain circumstances).

Too Long / Didn’t Read (TL/DR): While not a government-mandated regulation, PCI DSS is a contractual obligation enforced by the major card brands (e.g., Visa, MasterCard, American Express, Discover and JCB) via the PCI Security Standards Council (PCI SSC). Its requirements are not optional for organizations that handle payment card data. Whether a merchant, service provider, or third-party processor, compliance with PCI DSS is critical to minimizing financial liability, protecting consumer trust and reducing the risk of data breaches.

GRC-Focused Overview of PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) is one of the most established and globally recognized cybersecurity compliance frameworks. It was developed to protect cardholder data from compromise and ensure that all entities involved in payment card processing maintain robust security controls.

This page provides a cybersecurity-focused summary of PCI DSS from a GRC practitioner's perspective, including:

  • The history of these frameworks;
  • Practical compliance strategies; and
  • The role of high-quality documentation to be secure, compliant and resilient.

PCI DSS - Origins and Purpose

The early 2000s witnessed a dramatic rise in credit card fraud and large-scale data breaches targeting merchants and payment processors. In response, individual card brands introduced proprietary security programs, such as Visa’s Cardholder Information Security Program (CISP) and MasterCard’s Site Data Protection (SDP) program. However, these separate efforts led to confusion and inconsistent application of security standards.

To consolidate and unify data protection requirements across the industry, the PCI Security Standards Council (PCI SSC) was founded in September 2006 by the five major card brands. The Council is an independent body charged with managing the development and evolution of PCI security standards, including:

  • PCI DSS (Data Security Standard);
  • PA-DSS (Payment Application Data Security Standard);
  • PTS (PIN Transaction Security); and
  • PCI P2PE (Point-to-Point Encryption).

PCI DSS Version Milestones

  • Version 1.0 (2004): Joint standardization of security requirements across card brands
  • Version 2.0 (2010): Clarified ambiguous requirements and improved guidance
  • Version 3.0–3.2.1 (2013–2018): Strengthened controls, multi-factor authentication, service provider accountability
  • Version 4.0 (Published March 2022): Major overhaul introducing flexible, objective-based requirements, risk-based validation and modernization for evolving threats

Common Methods to Achieve and Maintain Conformity With PCI DSS

Any organization that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD) must comply with PCI DSS. This includes:

Merchants

Defined as any entity that accepts payment cards as a form of payment. Merchants are categorized into four levels based on annual transaction volume:

  • Level 1: Over 6 million transactions/year
  • Level 2: 1 to 6 million
  • Level 3: 20,000 to 1 million (e-commerce)
  • Level 4: Fewer than 20,000 (e-commerce) or up to 1 million (other)

Level 1 merchants face the most stringent reporting and validation requirements.

Service Providers

This includes third-party organizations that:

  • Store or process payment card data on behalf of merchants
  • Manage payment infrastructure (e.g., data centers, cloud hosting, call centers)
  • Provide tokenization, fraud monitoring, or managed security services

Service providers are subject to annual third-party assessments and must meet more rigorous oversight and logging requirements under PCI DSS 4.0.

Other Entities

Even entities not directly processing payments, such as software vendors, hardware integrators, or fintech firms, may be considered in scope if their systems can affect the security of cardholder data or the cardholder data environment (CDE).

Structure of the PCI DSS Framework

PCI DSS defines 12 core requirements organized under six overarching objectives. These requirements represent a minimum baseline of technical, operational and administrative controls needed to protect cardholder data.

Build and Maintain a Secure Network and Systems

  1. Install and maintain network security controls (NSCs)
  2. Apply secure configurations to all system components

Protect Account Data

  1. Protect stored account data
  2. Protect cardholder data with strong cryptography during transmission

Maintain a Vulnerability Management Program

  1. Protect systems and networks from malicious software
  2. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

  1. Restrict access to cardholder data by business need to know
  2. Identify users and authenticate access to system components
  3. Restrict physical access to cardholder data

Regularly Monitor and Test Networks

  1. Log and monitor all access to network resources and cardholder data
  2. Test security of systems and networks regularly

Maintain an Information Security Policy

  1. Support information security with organizational policies and programs

Each requirement includes multiple sub-requirements, control testing procedures and intent statements. The standard mandates both technical security controls (e.g., firewalls, encryption, anti-malware) and administrative measures (e.g., training, policy enforcement, incident response).

Compliance with PCI DSS is not a one-time task, where it is an ongoing, lifecycle-driven process that includes assessment, remediation and validation. The approach to compliance varies depending on merchant level, service provider status and complexity of the cardholder data environment.

  • Define the Cardholder Data Environment (CDE). Reducing the size of the CDE through network segmentation and tokenization is a common strategy to limit audit scope and reduce risk. The first and most important step is to determine the scope of the CDE. This includes identifying:
    • Systems that store, process, or transmit cardholder data;
    • Systems that are connected to the CDE; and
    • People, processes and technologies involved in card handling.
  • Conduct a Gap Assessment. Organizations typically perform a self-assessment or engage a Qualified Security Assessor (QSA) to identify gaps between current practices and PCI DSS requirements. This includes:
    • Control mapping;
    • Vulnerability identification;
    • Risk prioritization; and
    • Remediation planning.
  • Implement or Remediate Controls. Based on the gap analysis, organizations must:
    • Deploy or configure technical controls (e.g., encryption, firewalls, MFA);
    • Update security policies and procedures;
    • Train staff and enforce acceptable use policies; and
    • Remediate any vulnerabilities or findings.
  • Validate Compliance Annually. Depending on the entity type and level, validation may involve:
    • Self-Assessment Questionnaire (SAQ): For lower-level merchants;
    • Report on Compliance (ROC): For Level 1 merchants and all service providers; performed by a QSA; and
    • Attestation of Compliance (AOC): Formal declaration of PCI DSS conformance.
  • Maintain Continuous Compliance. Failure to maintain ongoing compliance can invalidate prior attestations and reintroduce liability. PCI DSS compliance is not a point-in-time certification. Key continuous activities include:
    • Quarterly vulnerability scanning (with an Approved Scanning Vendor);
    • Annual penetration testing and segmentation validation;
    • Real-time logging and monitoring; and
    • Periodic policy reviews and employee training.

Understanding The Value of Quality Cybersecurity Documentation To Conform With PCI DSS

While PCI DSS emphasizes control implementation and validation, documentation is integral to nearly every requirement. High-quality, accurate and current documentation:

  • Demonstrates Operational Governance
    • Security policies (Req. 12) outline expectations for system configuration, access, monitoring and acceptable use;
    • Incident response plans (Req. 12.10) define processes for breach containment, escalation and recovery; and
    • Network diagrams and data flow maps (Req. 1.1.2, 1.1.3) clarify scope and control placement.
  • Satisfies Evidence Requirements
    • QSAs and acquirers require written proof that controls exist and are effective;
    • Documentation supports audit trails, proving ongoing control operation (e.g., logs, vulnerability scans, access records); and
    • Training logs, risk assessments, vendor agreements and encryption key management logs are all common audit targets.
  • Enables Repeatability and Continuous Improvement
    • Repeatable procedures for patch management, access provisioning and change control reduce human error and audit risk;
    • Written standards enforce consistency across decentralized teams and systems; and
    • Documentation creates institutional knowledge and reduces key-person risk.
  • Reduces the Risk of Scope Creep
    • Clear scoping documents help isolate the CDE and justify segmentation controls; and
    • Updated network and data flow diagrams provide evidence that non-CDE systems are truly out of scope.

Outdated, or boilerplate documentation, is a top reason for PCI DSS audit findings. QSAs are trained to distinguish between real evidence and compliance theater. Organizations that treat documentation as part of the security lifecycle are far more likely to pass assessments with minimal remediation.

** SPONSORED CONTENT **

ComplianceForge GRC importable policies standards procedures