Table of contents

Electronic payment methods are increasingly prevalent, spanning from credit cards to online shopping. Ensuring the security of transactions and safeguarding cardholder data (CD) necessitates merchants and financial institutions to fortify cardholder data environments (CDE). Among the stringent security compliance mandates, the Payment Card Industry Data Security Standard (PCI DSS) stands out for its comprehensive guidelines. Understanding the 12 PCI DSS compliance requirements is crucial for organizations seeking to safeguard the sensitive CD they handle throughout collection, storage, transmission, and processing.

Increased Use of Digital Payments

The use of digital payment methods is expansive. According to a 2023 study by McKinsey, more than nine out of 10 consumers say they have used some form of digital payment over the course of the year.

COVID also led to a greater use of credit cards by consumers. The Federal Reserve Bank of Boston reports that pre-pandemic in 2019, credit card use was at 24% but rose to a 31% share in 2022, becoming the top payment choice. And Pew Research Center reports that approximately four in 10 Americans say none of their purchases in a typical week are paid for with cash, up from 29% in 2018.

The dominance of digital transactions as a primary payment method will persist. To uphold ongoing security standards, it is imperative for merchants and financial institutions to reassess their adherence to PCI DSS, especially with the advent of PCI DSS 4.0, and ensure full compliance with its requirements.

Who is the Payment Card Industry Security Standards Council (PCI SSC)?

In 2006, five payment card companies (American Express, Discover, JCB International, MasterCard and Visa) founded PCI SSC to develop and drive adoption of data security standards. Since then, the organization has expanded to include Founding Members, Strategic Members, a Board of Advisors, Management Committee, Strategic Regional Members, Affiliate Members, and Participating Organizations.

The PCI Security Standards Council (PCI SSC) is a global forum for the industry to come together to develop, enhance, disseminate, and assist with the understanding of security standards for payment account security. The PCI SSC maintains, evolves, and promotes the Payment Card Industry Security Standards. It also provides critical tools needed for implementation of the standards, such as assessment and scanning qualifications, self-assessment questionnaires, training and education, and product certification programs.

According to their website, PCI DSS is a global forum for the industry to come together to develop, enhance, disseminate, and assist with the understanding of security standards for payment account security. Their standards and resources are instrumental in safeguarding individuals, processes, and technologies throughout the payment ecosystem, ensuring the global security of transactions. The four main ways they help secure payments include:

  • Managing global payment security standards
  • Validating and listing products and solutions that meet PCI SSC standards and program requirements
  • Training, testing, and qualifying security professionals and organizations
  • Providing free best practices and payment security resources

Unlike laws set out by governmental legislative bodies, PCI DSS is not a law. Additionally, since the PCI SSC is not a governmental agency, the standard does not fall under traditional regulatory compliance requirements.

On the other hand, PCI DSS is more than a traditional industry standard, like ISO 27000 series. While organizations can choose to be certified to an industry standard, noncompliance has no penalties or fines.

What Are the Fines and Penalties for PCI Noncompliance?

At their discretion, the payment brands can choose to impose fines on acquiring banks for PCI compliance violation, ranging from $5,000 to $100,000 per month. Generally, banks that need to pay this fine pass them along to the merchant.

For example, according to the NetDiligence 2023 Cyber Claims Study PCI DSS-related fines assessed over the five-year period ranged from $1,000 to $2.3 million. PCI DSS fines typically include:

  • Assessed penalties
  • Costs for card brand-ordered assessments
  • Forensic investigations
  • Card replacement costs

Additionally, a bank may decide to end its relationship with the merchant or increase transaction fees.

What Types of Data Does PCI DSS Cover?

PCI DSS covers two different types of payment information: Cardholder Data and Sensitive Authentication Data (SAD).

Cardholder data consists of:

  • Primary Account Number (PAN)
  • Cardholder name
  • Expiration date
  • Service code

Sensitive authentication data consists of:

  • Full track data (whether magnetic-stripe or chip)
  • PINs/PIN blocks

According to PCI DSS, the PAN decides the protection level required. Environments that store, process, or transmit PAN along with any of the other cardholder data types or even contain both types must be PCI DSS compliant. Additionally, sensitive authentication data must never be stored.

What Are the 12 PCI DSS Compliance Requirements?

Regular updates have been made over the years with the last major update taking place almost 10 years ago. Nothing in the standard’s history has been as significant a change as the release of PCI DSS 4.0. With a focus on better tackling emerging and new threats, addressing technology developments, and creating flexibility in compliance, PCI DSS 4.0 should move data security to being part of a business-as-usual mindset.

PCI DSS’s 12 compliance requirements fall into six categories:

  • Build and maintain a secure network and systems
  • Protect account data
  • Maintain a vulnerability management program
  • Implement strong access control measures
  • Regularly monitor and test networks
  • Maintain an information security policy

Although these six categories might seem manageable, the “Detailed PCI DSS Requirements and Security Assessment Procedures” section of the standard is 160 pages long. Buried within each of the 12 requirements are multiple subparts, and many subparts consist of more subparts.

Following is a summary overview of PCI DSS 4.0 requirements as stated in the PCI DSS Quick Reference Guide: Understanding the Payment Card Industry Data Security Standard version 4.0. More information is available in the Guide.

Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain network security controls

Network security controls (NSCs), such as firewalls and other network security technologies, are network policy enforcement points that typically control network traffic between two or more logical or physical network segments (or subnets) based on pre-defined policies or rules. Traditionally this function has been provided by physical firewalls; however, now this functionality may be provided by virtual devices, cloud access controls, virtualization/container systems, and other software-defined networking technology.

1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood.

1.2 Network security controls (NSCs) are configured and maintained.

1.3 Network access to and from the cardholder data environment is restricted.

1.4 Network connections between trusted and untrusted networks are controlled.

1.5 Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

Requirement 2: Apply secure configurations to all system components

Malicious individuals, both external and internal to an entity, often use default passwords and other vendor default settings to compromise systems. These passwords and settings are well known and are easily determined via public information. Applying secure configurations to system components reduces the means available to an attacker to compromise systems. Changing default passwords, removing unnecessary software, functions, and accounts, and disabling or removing unnecessary services all help to reduce the potential attack surface.

2.1 Processes and mechanisms for applying secure configurations to all system components are defined and understood.

2.2 System components are configured and managed securely.

2.3 Wireless environments are configured and managed securely.

Protect Account Data

Requirement 3: Protect stored account data

Payment account data should not be stored unless it is necessary to meet the needs of the business. Sensitive authentication data must never be stored after authorization. If your organization stores PAN, it is crucial to render it unreadable. If your company stores sensitive authentication data prior to completion of authorization, that data must also be protected.

3.1 Processes and mechanisms for protecting stored account data are defined and understood.

3.2 Storage of account data is kept to a minimum.

3.3 Sensitive authentication data (SAD) is not stored after authorization.

3.4 Access to displays of full PAN and ability to copy cardholder data are restricted.

3.5 Primary account number (PAN) is secured wherever it is stored.

3.6 Cryptographic keys used to protect stored account data are secured.

3.7 Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.

Requirement 4: Protect stored cardholder data with strong cryptography during transmission over open, public networks

To protect against compromise, primary account numbers (PANs) must be encrypted during transmission over networks that are easily accessed by malicious individuals, including untrusted and public networks. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targeted by malicious individuals aiming to exploit these vulnerabilities to gain privileged access to cardholder data environments (CDE). PAN transmissions can be protected by encrypting the data before it is transmitted, or by encrypting the session over which the data is transmitted, or both.

4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.

4.2 PAN is protected with strong cryptography during transmission.

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems and networks from malicious software

Malicious software (malware) is software or firmware designed to infiltrate or damage a computer system without the owner’s knowledge or consent, with the intent of compromising the confidentiality, integrity, or availability of the owner’s data, applications, or operating system. Examples include viruses, worms, Trojans, spyware, ransomware, keyloggers, rootkits, malicious code, scripts, and links. Malware can enter the network during many business-approved activities, including employee e-mail (for example, via phishing) and use of the internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities.

5.1 Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.

5.2 Malicious software (malware) is prevented, or detected and addressed.

5.3 Anti-malware mechanisms and processes are active, maintained, and monitored.

5.4 Anti-phishing mechanisms protect users against phishing attacks.

Requirement 6: Develop and maintain secure systems and software

Security vulnerabilities in systems and applications may allow criminals to access payment data. Many of these vulnerabilities are eliminated by installing vendor-provided security patches, which perform a quick-repair job for a specific piece of programming code. All system components must have the most recently released critical security patches installed to prevent exploitation. Entities must also apply patches to less-critical systems in an appropriate timeframe, based on a formal risk analysis. Applications must be developed according to secure development and coding practices, and changes to systems in the cardholder data environment must follow change control procedures.

6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.

6.2 Bespoke and custom software are developed securely.

6.3 Security vulnerabilities are identified and addressed.

6.4 Public-facing web applications are protected against attacks. 6.5 Changes to all system components are managed securely.

Implement Strong Access Control Measures

Requirement 7: Restrict access to system components and cardholder data by business need to know

Unauthorized individuals may gain access to critical data or systems due to ineffective access control rules and definitions. To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. “Need to know” refers to providing access to only the least amount of data needed to perform a job. “Least privileges” refers to providing only the minimum level of privileges needed to perform a job.

7.1 Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood

7.2 Access to system components and data is appropriately defined and assigned.

7.3 Access to system components and data is managed via an access control system(s).

Requirement 8: Identify users and authenticate access to system components

Assigning a unique identification (ID) to each person with access ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users. Unless otherwise stated in the requirement, these requirements apply to all accounts, including point-of-sale accounts, those with administrative capabilities, and all accounts used to view or access payment account data or systems with those data. These requirements do not apply to accounts used by consumers (cardholders).

8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.

8.2 User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle.

8.3 Strong authentication for users and administrators is established and managed.

8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE.

8.5 Multi-factor authentication (MFA) systems are configured to prevent misuse.

8.6 Use of application and system accounts and associated authentication factors is strictly managed.

Requirement 9: Restrict physical access to cardholder data

Physical access to cardholder data or systems that store, process, or transmit cardholder data should be restricted so that unauthorized individuals cannot access or remove systems or hardcopies containing this data.

9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood.

9.2 Physical access controls manage entry into facilities and systems containing cardholder data.

9.3 Physical access for personnel and visitors is authorized and managed.

9.4 Media with cardholder data is securely stored, accessed, distributed, and destroyed.

9.5 Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution.

Regularly Monitor and Test Networks

Requirement 10: Log and monitor all access to system components and cardholder data

Logging mechanisms and the ability to track user activities are critical for detection of anomalies and suspicious activities, and for effective forensic analysis. The presence of logs in all environments allows thorough tracking and analysis if something goes wrong. Determining the cause of a compromise is difficult, if not impossible, without system activity logs.

10.1 Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.

10.2 Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.

10.3 Audit logs are protected from destruction and unauthorized modifications.

10.4 Audit logs are reviewed to identify anomalies or suspicious activity.

10.5 Audit log history is retained and available for analysis.

10.6 Time-synchronization mechanisms support consistent time settings across all systems.

10.7 Failures of critical security control systems are detected, reported, and responded to promptly.

Requirement 11: Test security of systems and networks regularly

Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and bespoke and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.

11.1 Processes and mechanisms for regularly testing security of systems and networks are defined and understood.

11.2 Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.

11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.

11.4 External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.

11.5 Network intrusions and unexpected file changes are detected and responded to.

11.6 Unauthorized changes on payment pages are detected and responded to.

Maintain an Information Security Policy

Requirement 12: Support information security with organizational policies and programs

12.1 A comprehensive information security policy that governs and provides direction for protection of the entity’s information assets is known and current.

12.2 Acceptable use policies for end-user technologies are defined and implemented.

12.3 Risks to the cardholder data environment are formally identified, evaluated, and managed.

12.4 PCI DSS compliance is managed.

12.5 PCI DSS scope is documented and validated.

12.6 Security awareness education is an ongoing activity.

12.7 Personnel are screened to reduce risks from insider threats.

12.8 Risk to information assets associated with third-party service provider (TPSP) relationships is managed.

12.9 Third-party service providers (TPSPs) support their customers’ PCI DSS compliance.

12.10 Suspected and confirmed security incidents that could impact the CDE are responded to immediately.

Are You Ready for PCI DSS 4.0?

On March 31, 2024, PCI DSS 3.2 was retired and v4.0 became the active DSS version. Organizations have until March 31, 2025, to phase in the new requirements identified as best practices in v4.0. After this date, these new requirements will be mandatory for compliance with PCI DSS 4.0.

In total, there are 64 new requirements, but assessments conducted from March 31, 2024, to March 31, 2025, only need to focus on 12. It’s noteworthy that 10 of these focus on documentation and communication of assigned roles and responsibilities. The 12 requirements are:

PCI DSS Requirements

One of the most significant changes with PCI DSS 4.0 is the introduction of the customized approach. With the revised standard, organizations can choose from one of two approaches to determine which works better with their security posture to achieve and maintain compliance. There’s the traditional defined approach and the new more flexible customized approach:

  • Defined Approach: With this approach, organizations implement security controls as prescribed in the PCI DSS’s Requirements and Testing Procedures, and the assessor then follows the defined testing procedures to ensure requirements are met. This approach provides more direction on how to meet security objectives. If an organization already has controls in place that meet PCI DSS requirements and is comfortable with its current approach, there is no need to change to the customized approach.
  • Customized Approach: Organizations can create a customized implementation, giving them flexibility to implement controls. With this approach, there are no defined testing procedures; it will be up to the assessor to develop validation testing procedures. In creating this approach, the intent was for it to be used by “risk-mature entities that demonstrate a robust risk-management approach to security, including, but not limited to, a dedicated risk management department or an organization-wide risk management approach.”

Meet Compliance Requirements with Alert Logic

Managing PCI DSS compliance is challenging for any organization because they include practices, processes, and technology requirements. Fortra’s Alert Logic MDR, Fortra EDR, and Fortra Managed WAF ease many of the administrative and technical burdens associated with PCI DSS by providing:

  • Cybersecurity professionals who ensure 24/7 monitoring and incident responses across on-premises and cloud environments.
  • Assessment, detection, and alerting capabilities that reduce operational and technology burdens associated with security controls like access and encryption.
  • Intrusion Detection Systems (IDS) that continuously monitor environments to identify potential threats like brute force attacks, command and control exploits, and lateral movement with privilege escalation.
  • Risk and threat mitigation solutions like automated log management and web application monitoring tools that can improve key cybersecurity metrics like Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR).
  • While web application firewalls were not an explicit requirement in PCI DSS 3.2, with PCI DSS 4.0 and requirement 6.4.2, a WAF is mandated to “continuously detect and prevent web-based attacks” made against your applications and APIs. Fortra Managed WAF goes further, with automated controls for mitigating client-side risks to help satisfy requirements 6.4.3 and 11.6.1, reducing tool sprawl and simplifying compliance.
  • PCI DSS requires organizations to conduct regular vulnerability scans on their networks, systems, and applications. ASVs play a pivotal role in this process. An Approved Scanning Vendor (ASV) is an organization approved by PCI SSC to conduct external vulnerability scans in adherence for PCI DSS compliance requirements. Fortra’s Alert Logic is a PCI SSC ASV and the vulnerability scans we perform validate customers are not vulnerable to the increasingly sophisticated attacks on their systems.

Schedule a demo today to learn how Alert Logic can support your PCI DSS 4.0 compliance goals.

Additional Resources:

Blog: Understanding PCI ASV: A Crucial Component in Securing Payment Card Data

Blog: PCI DSS 4.0: Understanding the Expanded Role of Web Application Firewalls

PCI DSS 4.0 Compliance Guide: Tips to Avoid Last-Minute Panic










Antonio Sanchez
About the Author
Antonio Sanchez
Antonio Sanchez is Fortra’s Principal Evangelist. He has over 20 years of experience in the IT industry focusing on cyber security, information management, and disaster recovery solutions to help organizations of all sizes manage threats and improve their security posture.

Related Post

Ready to protect your company with Alert Logic MDR?