Payment card breaches are among the costliest incidents an organization can face. With over $500 billion in card fraud losses globally each year, the financial and reputational damage from a data breach extends far beyond the initial incident. A single breach can result in forensic investigations costing millions, customer notification obligations, regulatory fines, litigation, and loss of customer trust. In 2024 and 2025, major organizations including retailers, financial institutions, and payment processors experienced breaches that exposed millions of cardholder records, each incident demonstrating how quickly trust and revenue can evaporate.
In response to escalating breach risk, the five major payment card networks — Visa, Mastercard, American Express, Discover, and JCB — came together in 2004 to create a single, unified security standard. Rather than having merchants and service providers follow separate requirements for each network, these five brands created the Payment Card Industry Data Security Standard (PCI DSS) as a contractually mandated baseline for anyone handling cardholder data. PCI DSS is not a law. It is not a regulation. But it is, in practical terms, as binding as law — because acceptance of card payments is conditional on compliance, and non-compliance can result in fines, increased transaction fees, and termination of card acceptance privileges.
What PCI DSS Actually Is
PCI DSS stands for Payment Card Industry Data Security Standard. It is a set of technical and organizational security requirements developed by the PCI Security Standards Council, which was formed by Visa, Mastercard, American Express, Discover, and JCB in 2004. The standard has evolved over time, with major revisions approximately every three to four years. The current version, PCI DSS v4.0, was released in March 2022 and became the sole active standard on March 31, 2024, when the previous version (v3.2.1) was retired.
The defining characteristic of PCI DSS is that it is enforced not through government regulation but through commercial contract. Card networks embed PCI DSS compliance requirements into their rules for acquiring banks and payment processors. Those acquirers, in turn, embed compliance requirements into their merchant service agreements and service provider contracts. If a merchant or service provider fails to maintain PCI DSS compliance, the acquiring bank faces fines and penalties from the card networks. Almost universally, these costs are passed directly to the non-compliant merchant or service provider, along with increased interchange rates, mandatory security monitoring, or outright termination of card acceptance.
| KEY IDEA | PCI DSS is not a law — it is a contractual obligation embedded in your merchant or service provider agreement with your acquiring bank and card network. Non-compliance can result in fines, increased transaction fees, and loss of the ability to accept card payments. |
Who Must Comply with PCI DSS
Any organization that stores, processes, or transmits cardholder data (the 16-digit card number, or PAN) must comply with PCI DSS. This includes three primary categories of entities: merchants (organizations that directly accept card payments from customers), service providers (organizations that store, process, or transmit cardholder data on behalf of merchants or other organizations), and other entities operating within the payment ecosystem such as payment processors, gateways, and acquiring banks.
The scope of PCI DSS is not organization-wide. Rather, it applies specifically to the Cardholder Data Environment (CDE) — the systems, networks, and processes that handle cardholder data. An organization might have extensive IT infrastructure, but only the systems and networks that touch payment card data are subject to PCI DSS requirements. This scoping distinction is critical because it can mean the difference between a focused compliance project affecting a few systems and a massive undertaking affecting an entire organization.
| Entity Type | Example | PCI DSS Obligation |
|---|---|---|
| Merchant | Retail store, e-commerce site, restaurant | Must comply and validate based on transaction volume |
| Service Provider | Payment gateway, processor, cloud hosting for CDE | Must comply and validate — often stricter Level 1 requirements |
| Sub-Merchant | Marketplace seller, franchise operator | Compliance managed through parent or aggregator |
| Issuing Bank | Bank that issues cards to consumers | Card network rules apply; PCI DSS scope limited to CDE |
The Six Control Objectives and 12 Requirements
PCI DSS is organized around six broad control objectives, each supported by two specific requirements (for a total of 12 requirements). These control objectives represent the key domains of security that the card networks consider essential to protect cardholder data. Each requirement contains detailed sub-requirements (called testing procedures in PCI DSS v4.0) that describe specific controls, configurations, and evidence that must be in place.
| # | Requirement | Control Objective |
|---|---|---|
| 1 | Install and maintain network security controls | Build and Maintain a Secure Network |
| 2 | Apply secure configurations to all system components | Build and Maintain a Secure Network |
| 3 | Protect stored account data | Protect Account Data |
| 4 | Protect cardholder data with strong cryptography during transmission | Protect Account Data |
| 5 | Protect all systems and networks from malicious software | Maintain a Vulnerability Management Program |
| 6 | Develop and maintain secure systems and software | Maintain a Vulnerability Management Program |
| 7 | Restrict access to system components and cardholder data by business need to know | Implement Strong Access Control Measures |
| 8 | Identify users and authenticate access to system components | Implement Strong Access Control Measures |
| 9 | Restrict physical access to cardholder data | Implement Strong Access Control Measures |
| 10 | Log and monitor all access to system components and cardholder data | Regularly Monitor and Test Networks |
| 11 | Test security of systems and networks regularly | Regularly Monitor and Test Networks |
| 12 | Support information security with organizational policies and programs | Maintain an Information Security Policy |
How PCI DSS Is Enforced
The enforcement chain begins with the card networks (Visa, Mastercard, etc.), which set the PCI DSS requirements and enforce them through contracts with acquiring banks. Acquiring banks then sign agreements with merchants and service providers, embedding PCI DSS compliance requirements into those commercial relationships. When the card networks discover non-compliance—through breach investigations, QSA reports, or direct assessments—they assess fines against the acquiring bank. Those fines are almost always passed through to the non-compliant merchant or service provider.
In Indonesia, the central banking regulator Bank Indonesia (BI) has recognized PCI DSS compliance through Peraturan Bank Indonesia (PBI) No. 23/2021 on payment system operators. The Financial Services Authority (OJK) has also incorporated PCI DSS expectations into POJK No. 11/2022 for banking security. For payment service providers and fintech companies, compliance with PCI DSS is increasingly a requirement for business licensing and operation.
| IMPORTANT | Non-compliance consequences are real: Visa and Mastercard can impose fines of $5,000–$100,000 per month on acquirers for non-compliant merchants. These costs are almost always passed directly to the non-compliant merchant, along with potential increases in interchange rates and eventual termination of card acceptance. |
What PCI DSS Is Not
PCI DSS is not a guarantee of security. Compliance with PCI DSS requirements does not mean an organization will never experience a breach. PCI DSS sets a baseline standard for organizations that handle cardholder data, but it is not a comprehensive information security program. Many breaches occur at organizations that are fully compliant with PCI DSS, usually due to factors outside the standard's scope: zero-day vulnerabilities, advanced persistent threats, social engineering, or misconfigurations that slip through gaps in testing or monitoring.
PCI DSS is also not a one-time project. Some organizations treat compliance as a checkbox exercise — pass an annual assessment and move on. In reality, PCI DSS requires continuous monitoring, regular testing, and ongoing maintenance of controls. Requirements like vulnerability scanning (quarterly), penetration testing (annually), and log review (daily) are continuous activities, not one-time events.
Additionally, PCI DSS is not only for large organizations. Some merchants believe that PCI DSS applies only to national retailers or large payment processors. This is a dangerous misconception. Any organization—from a single-person consulting firm accepting credit cards to a startup e-commerce site—is in scope for PCI DSS if it handles cardholder data. Smaller organizations often face proportionally greater compliance burdens because they lack dedicated security staff and mature infrastructure.
PCI DSS in the Indonesian Payment Ecosystem
Indonesia's digital payment sector is one of the fastest-growing in the world. With over 200 million active card and digital wallet users, and transaction volumes growing at double-digit rates annually, the security of Indonesia's payment infrastructure is increasingly critical. The Indonesian payment ecosystem includes traditional banks, fintech payment startups, payment service providers (PSPs), and digital wallet operators—all of which handle or store cardholder data.
Bank Indonesia's National Payment System (SNP) strategy recognizes international security standards as foundational. Payment system operators are required to demonstrate compliance with security frameworks aligned with PCI DSS. The Gerbang Pembayaran Nasional (GPN), Indonesia's national payment gateway, operates under rigorous security standards that track closely with PCI DSS expectations. For payment aggregators and fintech players operating across Indonesia, demonstrating PCI DSS compliance to QSAs or through SAQ assessments has become a standard requirement in vendor security assessments and licensing processes.
| Bitlion works with Indonesian payment organizations, PSPs, and fintech companies across the PCI DSS compliance lifecycle. The most common gap we see is not in technical controls but in documentation and evidence management — organizations that have strong security practices but cannot demonstrate them to a QSA. |
The Bottom Line
PCI DSS is the baseline security standard for any organization that stores, processes, or transmits payment card data. It is not optional—it is mandated by the card networks through acquiring bank contracts. Compliance requires not just technical controls (firewalls, encryption, secure configurations) but also organizational practices (policies, training, incident response, vendor management). The 12 requirements of PCI DSS v4.0 cover every aspect of cardholder data protection, from network security to physical access controls to incident response planning. Understanding PCI DSS scope, the 12 requirements, the different validation levels, and the distinction between PCI DSS v4.0's Defined and Customized Approaches is the essential foundation for building and maintaining a compliant cardholder data environment.