What Are the 12 Requirements of PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS) sets standards to keep the global payment card ecosystem trustworthy. Developed and maintained by the PCI Security Standards Council (PCI SSC), PCI DSS is meant to secure debit and credit card transactions to prevent cybersecurity issues like data theft or fraud.

Any merchant or business that accepts customer payment cards and processes this data must comply with PCI DSS requirements. The latest version of PCI DSS is V4.0, which includes 12 requirements. Read onward to understand these 12 requirements and the costs of PCI compliance and non-compliance.

What Is PCI DSS?

Since its introduction in 2004, PCI DSS has evolved into a globally accepted security standard. Any business entity that stores, processes, or transmits Cardholder Data (CHD) or Sensitive Authentication Data (SAD) must comply with PCI DSS standards. Covered businesses include:

• Merchants
• Payment processors
• Acquirers
• Card issuers
• Other service providers

Businesses that could affect the Cardholder Data Environment’s (CDE) security must also comply with the PCI DSS.

As defined by PCI DSS, cardholder data includes:

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

Sensitive authentication data includes:

• Complete track data (magnetic-stripe data or equivalent on a chip)
• Card verification code
• PINs and PIN blocks

The latest version of the standard (V4.0) was released in 2022. PCI DSS v3.2.1 will remain valid until March 31, 2024, when it will be retired. Until that retirement date, PCI DSS version 3.2.1 or 4.0 can be used for assessments.

What Is PCI Compliance?

PCI-compliant organizations have successfully implemented the technical and operational safeguards mandated by the standard’s 12 requirements. These safeguards enable businesses to secure CHD from hackers and earn customers’ trust and loyalty.

PCI DSS compliance is divided into four levels based on the number of card transactions a business processes yearly. That level determines the company’s steps to achieve and maintain PCI DSS compliance.

6 Principles of PCI DSS

The PCI DSS’s six significant principles help create a robust security environment for businesses that process card transactions. These principles are:

1. Build and maintain a secure network to prevent the unauthorized use of CHD.
2. Protect CHD whether that data is stored locally or transmitted to a remote server or service provider.
3. Maintain a vulnerability management program with appropriate security procedures, policies, internal controls, and penetration testing.
4. Implement strong access control measures on a business need-to-know basis.
5. Regularly monitor and test physical and wireless networks to find and fix exploitable vulnerabilities.
6. Maintain a robust information security policy and inform employees about their responsibilities to protect CHD.

The standard then has 12 requirements for PCI DSS compliance, which collectively align with the above six principles.

The 12 Requirements of PCI DSS

The 12 requirements under PCI DSS v4.0 are described below.

1. Install and maintain network security controls.
   All merchants must maintain a secure network through Network Security Controls (NSCs), such as physical or virtual firewalls, routers, strong access control measures for the cloud, etc. The NSCs must control traffic between logical or physical network segments (or subnets) based on predefined policies or rules. The goal is to protect the CDE, a sensitive area within a business entity’s network under PCI DSS.
2. Apply secure configurations to all system components.
   PCI DSS v4.0 adds new requirements for roles and responsibilities regarding secure configurations for wireless networks. By applying these configurations to system components, businesses can reduce the potential attack surface and decrease the probability of system compromise by a threat actor.
   Examples of such configurations include:
   • Configure firewalls properly
   • Change default passwords and other vendor default settings
   • Remove unnecessary software, functions, and accounts
   • Disable or remove unnecessary services
3. Protect Stored Account Data (SAD)
   To protect SAD, businesses must implement protection methods such as encryption, truncation, masking, and hashing.
   They should also minimize risk by:
   • Not storing SAD unless necessary
   • Truncating cardholder data if full PAN is not required
   • Not sending unprotected PANs using end-user messaging technologies such as email or instant messaging

SAD encryption is unnecessary if the data is in non-persistent or volatile memory like RAM. SAD should, however, be removed from the volatile memory once the business purpose is complete. Also, if SAD storage becomes persistent, all PCI DSS requirements will apply, including encryption.

1. Protect cardholder data with solid cryptography during transmission over open, public networks
   Requirement 4 focuses on “strong cryptography” to protect the transmission of cardholder data and maintain its confidentiality, integrity, and non-repudiation. To avoid data compromise, all PAN transmissions must be encrypted by:
   • Encrypting the data before it is transmitted
   • Encrypting the session over which the data is transmitted

Further, the business must evaluate its network security parameters against applicable PCI DSS requirements if the network stores, processes, or transmits CHD.

1. Protect all systems and networks from malicious software.
   PCI DSS v4.0 replaces “anti-virus software” with “anti-malware software” to incorporate a broader range of security technologies to protect systems and networks. Under this requirement, entities must implement anti-malware solutions to secure their systems from current and evolving malware threats, including:
   • Viruses
   • Worms
   • Trojans
   • Spyware
   • Ransomware
   • Malicious code, scripts, links
2. Develop and maintain secure systems and software
   Businesses must apply software patches to all system components to prevent the exploitation and compromise of account data by malicious individuals or malware. This requirement applies to all system components except for section 6.2, which applies only to bespoke and custom software used on any system component. PCI DSS mandates applying Software Lifecycle (SLC) processes and secure coding techniques for customized software.
   All code repositories that store application code, system configurations, or other configuration data that can affect the security of account data or the CDE are in scope for PCI DSS assessments.
3. Restrict access to system components and cardholder data by business’ need to know.
   This requirement specifies the controls businesses must implement to ensure that critical data can be accessed only by authorized personnel. To this end, companies must deploy systems and processes to limit access based on need-to-know and job responsibilities and prevent unauthorized access.
4. Identify users and authenticate access to system components.
   Requirement 8 specifies the processes to identify users and authenticate their access to system components. Proper identification is essential to assure accountability and traceability for actions performed by that identity.
   Both a unique ID and authentication factors must be in place to ensure that an authorized user can access the rights and privileges assigned to them. These requirements apply to all accounts on all system components, including POS accounts, accounts with admin access, and system and application accounts.
5. Restrict physical access to cardholder data.
   Merchants and other businesses must restrict physical access to systems that store, process, or transmit CHD. The goal is to prevent individuals from accessing or removing systems or hard copies containing CHD, resulting in a breach or loss of cardholder privacy.
6. Log and monitor all access to system components and cardholder data.
   Requirement 10 focuses on audit logs, system components, and CHD. Logs and user activity tracking in the CDE and on system components will create audit trails and allow tracking, alerting, and analysis in case of a system compromise. This requirement applies to all user activities, including those by employees, contractors, consultants, and internal and external vendors.
7. Test system and network security regularly
   Under this requirement, businesses must regularly test all system components, processes, and bespoke and custom software to confirm that controls can adequately deal with the changing threat landscape.
8. Support Information Security (IS) with organizational policies and programs.
   Per this requirement, all businesses must implement an information security policy that informs personnel about the sensitivity of payment card data and their responsibilities for protecting it.

The Costs of PCI Compliance and Non-Compliance

Card processors typically pass on their PCI compliance and non-compliance fees to merchants. These fees vary by provider since no industry standards govern the minimum or maximum a business must pay to maintain PCI compliance.

Compliance Fees

Many providers impose annual PCI compliance charges of around $120. These fees compensate the provider for their services to help a merchant achieve PCI compliance. These services include:

• Data security scans conducted by an ASV
• Customer support and education
• Cyber liability or data breach insurance

Paying the PCI fees does not mean that the provider will maintain the merchant’s PCI DSS compliance or that the merchant doesn’t have to do anything to maintain compliance. If anything, the merchant must complete the annual SAQ and satisfy other applicable requirements to remain compliant.

Non-Compliance Fees

Businesses that fail to provide proof of PCI DSS compliance may have to pay the card processor a monthly non-compliance penalty of $20 to $30. The penalty is imposed for not meeting the requirements in the contract between the merchant and the processor. In severe cases, the provider may terminate the merchant’s account if the merchant can’t achieve compliance within the required timeframe.

Legal Enforceability of PCI DSS

Any government does not enforce PCI DSS. Instead, the PCI SSC designs its rules and drives adoption to assure safe payments worldwide. The PCI SSC does not have any legal authority to compel compliance. Nonetheless, the standard is mandatory for any business that accepts or processes credit or debit cards, regardless of business type or location.

Put simply: if you want to process credit card transactions, you must do it on the PCI SSC’s terms.

7-Step Process to Achieve PCI Compliance

PCI DSS protects CHD and an organization’s CDE from fraud and breaches. The Payment Card Industry Data Security Standard: Requirements and Testing Procedures is the official document that specifies the controls and processes merchants must implement to achieve PCI compliance.

If your organization is aiming for PCI compliance, this step-by-step process will be helpful:

1. Determine PCI level. PCI compliance requirements depend on the number of transactions, so you should determine how many transactions you process annually.
2. Map CHD flows. Find out where CHD moves through your applications, systems, and people.
3. Fill out the SAQ. Your SAQ will be used to validate if your business meets all 12 requirements and is, therefore, PCI compliant.
4. Fill out the Attestation of Compliance (AOC). This document ensures that you have completed every step to achieve PCI compliance.
5. Conduct a vulnerability scan. Based on SAQ results, you can either do the scan yourself or hire an ASV.
6. Complete and submit documents. Submit the SAQ, AOC, and ASV reports to the credit card brands you support (or will support).
7. Monitor. Monitor compliance regularly and hire a security team to respond to security vulnerabilities and threats.

Click here to access a more detailed PCI compliance checklist

Leveraging Automation Technology to Meet PCI DSS Compliance Requirements

Meeting PCI DSS compliance requirements can be time-consuming and labor-intensive, especially for organizations handling large volumes of credit card data. However, leveraging automation technology can streamline compliance and reduce the burden on security and compliance teams.

Automation tools can help in several ways:

• Automating vulnerability scanning and patching to find and fix  vulnerabilities across the environment (Requirements 5, 6, 11)
• Automating configuration monitoring to ensure secure configurations are maintained (Requirements 2, 4, 11)
• Automating access controls and privileges to enforce least privilege principles (Requirements 7, 8, 9)
• Collecting and centralizing logs to enable monitoring of suspicious activity and analysis (Requirements 10, 11, 12)
• Automating report generation for validation requirements (Requirements 11, 12)
• Workflow automation for processes like incident response plans

By leveraging automation, organizations can work smarter, reduce human error, and focus their security teams on higher-value tasks. Automation provides consistency, scalability, and efficiency in meeting PCI DSS controls.

The Future of PCI DSS: PCI DSS v4.0

PCI DSS v4.0 contains several updates that point to the future evolution of the standard, including:

• Enhanced security for e-commerce and digital payments, such as additional multi-factor authentication requirements
• Increased focus on securing cloud environments and supply chains
• Emphasis on detecting and responding to emerging threats through enhanced logging and monitoring
• Encouraging organizations to integrate security earlier in the software development lifecycle
• Adding requirements for security awareness and phishing resistance training
• Updating requirements around encryption and key management

PCI DSS will likely evolve as payment technologies, threats, and vulnerabilities change. We can expect more guidance for securing new payment channels like mobile wallets and QR codes. As more payments shift to the cloud, requirements for cloud security will increase.

Artificial intelligence and machine learning also represent an opportunity for PCI DSS to become more adaptive and risk-based. For example, AI could analyze logs and data to find anomalies indicative of a breach. Rather than a checkbox approach, PCI DSS may evolve to focus on detected threats like malware and dynamically adjust controls.

Meet the 12 Requirements of PCI DSS with RiskOptics ZenGRC

PCI DSS compliance can feel overwhelming for experienced compliance teams and even more so for teams that rely on manual processes, spreadsheets, and email communication. ZenGRC brings a faster, easier, and brighter path to PCI DSS compliance.

ZenGRC is an advanced compliance and audit management solution that will give you a unified, real-time view of risk and compliance. It will also accelerate onboarding and give you the insights to improve risk assessments and keep your organization secure.

Talk to our team for a free demo. We can even help you understand how to become PCI DSS certified!