PCI DSS as the industry's response: technical requirements for the storage, transmission, and processing of card data (CHD)

[Professor]

Abstract: An educational discussion of the key requirements of the Payment Card Industry Data Security Standard (PCI DSS). An explanation of the need for network segmentation, data encryption in transit (TLS) and at rest, and regular vulnerability testing. An emphasis on creating a culture of security.

Introduction: A Common Language of Security for the Entire Planet​

Imagine if every city in the world had its own unique traffic regulations. A red light in one place meant "stop," in another "yield," and in a third "may you turn?" Chaos and disaster would be inevitable. This is roughly what happened in the world of e-commerce in its early days: every store and every payment gateway stored and processed bank card data differently, creating a patchwork of vulnerabilities.

The answer to this chaos was the Payment Card Industry Data Security Standard (PCI DSS) — a unified, global standard for payment card data security. This is not the law of a single country, but the consolidated will of the industry (Visa, Mastercard, American Express, Discover, JCB), aimed at building trust in the digital economy. PCI DSS is a detailed guide to building a "digital fortress" for the most valuable asset — cardholder data (CHD).

This article isn't a dry list of rules, but a story about how global cooperation created a culture of security, turning data protection from an afterthought into a core business imperative.

Chapter 1. What is Cardholder Data (CHD) and why shouldn't it be touched?​

To understand the standard, it's important to understand what exactly it protects. Cardholder data (CHD) is divided into two categories:

1. Sensitive Authentication Data (SAD):
   • Full magnetic stripe data (Track 1, Track 2).
   • The card authentication code (CAV2, CID, CVC2, CVV2) is the same 3 digits on the back.
   • PIN code and its blocks.
   • PCI DSS Golden Rule: This data should NEVER be stored after a transaction has been authorized (even in encrypted form). Its purpose is one-time authentication, after which it must be securely destroyed.
2. Primary Account Number (PAN):
   • The card number itself (for example, 1234 5678 9012 3456).
   • PANs can be stored, but only under strict standard conditions. A PAN, when combined with the holder's name, expiration date, or security code, creates a vulnerable set.

The standard's philosophy is simple: If you can't protect the data, don't store it. Best practice is tokenization, where the real PAN is replaced with a token that's useless to fraudsters, and only that token is stored.

Chapter 2. Security Pillars: 6 Key Objectives and 12 Main Requirements of PCI DSS​

The standard is structured around six objectives, which are embodied in 12 detailed requirements. Let's review the key ones to understand the logic.

Objective 1: Build and maintain a secure network and systems.

• Requirement 1: Install and maintain a firewall configuration. This is the first line of defense. There should be no direct path from the public internet to the systems storing the map data.
• Requirement 2: Don't use vendor-supplied default values for system passwords and other security settings. The infamous admin/admin are the first thing an attacker checks.

Goal 2: Protect cardholder data.

• Requirement 3: Protect stored cardholder data. The heart of the standard.
  • Mask PAN when displaying on screen (display only the first 6 and last 4 digits: 123456******3456).
  • Cryptographic encryption of stored data using strong algorithms (AES-256) and secure key management. Keys are the new "data" that require even more careful protection.
  • Clear policies for data destruction once it is no longer needed.

Goal 3: Maintain a vulnerability management program.

• Requirement 5: Protect all systems from malware and update antivirus software regularly.
• Requirement 6: Develop and maintain secure systems and applications. This is a requirement for the development process (DevSecOps): secure code, change review, and fixing known vulnerabilities.

Goal 4: Implement robust access control measures.

• Requirement 7: Restrict access to cardholder data on a need-to-know basis. An accountant doesn't need access to the card database, and a developer doesn't need access to financial reports.
• Requirement 8: Identify and authenticate access to system components. Mandatory use of unique identifiers, two-factor authentication (2FA) for remote access, and complex passwords.

Goal 5: Monitor and test networks regularly.

• Requirement 10: Monitor and track all access to network resources and cardholder data. Full audit trail. Who, when, where, and what was done with the data? Logs must be stored and protected.
• Requirement 11: Regularly test security systems and processes.This is not just once a year, but on an ongoing basis:
  • Vulnerability Scanning (ASV Scans) for network perimeters.
  • Penetration testing (Pentest) to simulate a real attack and find vulnerability chains.
  • Intrusion Detection and Response (IDS/IPS).

Goal 6: Maintain information security policy.

• Requirement 12: Maintain a security policy that affects all personnel. This is the most people-centric point. Security is not just technology, but also culture. Employee training, incident management, and risk assessment for suppliers.

Chapter 3. Technical Cornerstones: Segmentation, Encryption, Monitoring​

1. Network Segmentation:
This is the most important technical measure for reducing the compliance scope. The idea is to isolate systems that process cardholder data (CDE - Cardholder Data Environment) from the rest of the corporate network. Imagine a bank within a bank, surrounded by fireproof walls. Even if a hacker penetrates the accounting department's network, they won't be able to directly access the CDE. This dramatically reduces the number of systems that need to be strictly audited according to the standard.

2. Encryption in transit (TLS) and at rest:

• Transmission: Any transmission of CHD over open networks (the internet) must use cryptographically secure protocols (TLS version 1.2 or higher). The lock icon in the browser is a visible manifestation of this requirement.
• Storage: "Data at rest encryption." If data is stored on disk, in a database, or in logs, it must be encrypted. Even if the server is physically stolen, the data will remain inaccessible.

3. Encryption Key Management:
Keys are like the keys to a safe. Storing them on the same server as your data is like writing a PIN on a card. The standard requires dedicated, secure systems for key lifecycle management (HSM – Hardware Security Module), segregation of duties, and regular key rotation.

4. Continuous Monitoring and Logging:
Systems must maintain detailed logs of all events: successful and unsuccessful login attempts, data access, and administrator actions. These logs must be centrally collected, protected from modification, and regularly analyzed. This "black box" provides a means for incident investigation.

Chapter 4: Compliance is a process, not a certificate​

A major misconception is that PCI DSS is a one-time checkbox. Compliance is an ongoing process.

• Merchant Levels: The scope of audits depends on the number of transactions per year. The largest merchants (Level 1) undergo an annual on-site audit by an independent qualified assessor (QSA) and compile a detailed return on asset (ROC) report.
• Quarterly vulnerability scanning (ASV Scan) for the perimeter.
• Annual completion of the Standards Assessment Questionnaire (SAQ) for smaller companies.
• Ongoing internal work: Training, policy updates, vulnerability fixes, log analysis.

Failure to comply with the standard threatens businesses with huge fines from payment systems, increased fees for acquiring, and, worst of all, loss of customer trust in the event of a breach.

Chapter 5. PCI DSS and Security Culture: From Obligation to Advantage​

PCI DSS implementation isn't just a cost. It's a strategic investment that provides:

1. Trust of customers and partners: Compliance with the standard is a public signal of a serious approach to security.
2. Reduce operational risks: Protect against catastrophic breaches, fines, and lawsuits.
3. Improving IT infrastructure: Processes implemented for PCI DSS compliance (change management, access control, monitoring) make the company's entire IT environment more mature and manageable.
4. Competitive advantage: In tenders and when working with large corporations, PCI DSS certification is often a mandatory requirement.

Conclusion: General Immunity of the Digital Economy​

PCI DSS is more than a standard. It's a global agreement to create shared immunity in the electronic payments ecosystem. Just as vaccinations protect society by creating herd immunity, PCI DSS compliance by every store, hosting provider, and bank makes the entire chain more secure.

It's a difficult path, requiring discipline, investment, and constant attention. But it's a journey from chaos to order, from vulnerability to resilience. When you see a lock icon when paying or entrust your card details to an online service, know that behind it lies not just technology, but years of work by thousands of people around the world who, brick by brick, have built the very same common security language that the entire planet now speaks. PCI DSS is the industry's response to the challenges of the times, and this response is clear: customer data is inviolable, and we will do everything to uphold this rule.