PCI-DSS Cybersecurity Requirements for Financial Transactions

PCI DSS cybersecurity requirements are relevant for all sorts of organizations, whether you’re a financial institution or a business with customers and transactions. And, while there are already many laws, regulations, and standards designed to protect personal data, this standard is particularly focused on card transactions. 

In this blog post, we explain the PCI-DSS, its standards, requirements, levels, and certification. 

What Does PCI-DSS Stand For? 

PCI-DSS stands for the Payment Card Industry Data Security Standards. These standards were established for all businesses that process and store cardholder data. The standards relate to payment cards such as: 

• Debit and credit cards 
• ATM (automatic teller machine) and POS (point of sale) cards 

The reasoning is that the data they hold and transmit impacts financial institutions and other transactions industries – not to mention the personal data of the owners of these individual cards. 

The PCI Security Standards Council (SSC) 

The Payment Card Industry (PCI) needed a methodology for helping to prevent payment data breaches, payment card fraud, and identity theft. So, the Payment Card Industry Security Standards Council (PCI SSC) was formed in 2006 by major American and Japanese multinational payment card companies. Their purpose was to create and administer an information security card standard for global use.  

PCI DSS Standards

PCI Data Security Standard (PCI-DSS) 

The PCI-DSS is the main security standard created by the SSC. It provides baseline requirements and other directives that enable businesses to measure their own security policies and procedures. Its purpose is to encourage global and consistent data security measures for the better protection of payment account data and the prevention of data breaches. 

PCI-DSS Version 4 

This is the most recent version of the PCI DSS. It was made available in 2022 and came into force onin March 2024. Version 4 is distinguished from its predecessors with updates on firewalls, multifactor authentication (MFA), and targets risk analysis. PCI DSS 4.0 is still undergoing updates and reorganization to deal with emerging threats and technologies.  

For further information, see PCI DSS v4.0 Resource Hub.  
It has its own Resource Hub. 

Other PCI Standards 

There are other PCI security standards beyond the PCI-DSS. These have been developed to cater for different types of organizations and services, or roles. Here are two that are relevant to software developers, technology vendors ,and solution providers: 

• The PCI Secure Software Standard
• The Secure Software Lifecycle (Secure SLC) standard 

Both are part of a Software Security Framework that covers the secure design, development, and maintenance of existing and future payment software. Other PCI standards cover topics like point-to-point encryption (P2PE) and Personal Identification Number (PIN) security, among others. 

PCI DSS Requirements 

PCI DSS provides 12 operational and technical compliance requirements to protect payment account data. These requirements are mandatory for any business that processes payment card transactions and are designed to safeguard sensitive cardholder data. This data must be handled securely at every stage, from processing to storage and transmission. 

In each case, we’ve added some links to our Payara Server Enterprise documentation to act as pointers for ways in which our application server can help you work toward compliance with PCI-DSS. 

1. Install and maintain network security controls (NSC) – firewalls and other network security technologies (see Network Listeners) 
2. Apply secure configurations to all system components – the means available to an attacker to compromise systems (start with our The Security Guide Overview) 
3. Protect stored account data – using cryptography to protect stored account data and sensitive authentication data (SAD) (see Ciphers, Certificates, Security Tokens and Security Mechanisms, SSL Certificate Management, Eclipse MicroProfile JWT Authentication API, Initial Configuration Tasks, Supported Security Realms, and Security) 
4. Protect cardholder data with strong cryptography during transmission over open, public networks – meaning primary account numbers (PANs) must be encrypted during transmission over networks that are easily accessed by bad actors (see cryptograph links in the bullet point above and Data Grid Encryption) 
5. Protect all systems and networks from malicious software – including using anti-malware and anti-phishing mechanisms to protect users against attacks 
6. Develop and maintain secure systems and software – involving identifying security vulnerabilities and eliminating them by installing vendor-provided security patches (see Release Notes, Security Advisories and Upgrade Tool) 
7. Restrict access to system components and cardholder data to those who need to know it – by putting processes in place to limit access based on the principle of least privilege (PoLP) (see Administering User Security for information on authentication and authorization policies for realms, users, and groups) 
8. Identify users and authenticate access to system components – this requires assigning a unique identification (ID) to each person with access and implementing MFA (see Administering User Security) 
9. Restrict physical access to cardholder data – ensuring that unauthorized individuals can access neither computer systems nor hard copies containing data 
10. Log and monitor all access to system components and cardholder data – achieved by mechanisms that track user activities for anomaly detection and forensic analysis (see Diagnostics Tool and OpenTracing) 
11. Test security of systems and networks regularly – with frequent tests to discover fresh internal and external vulnerabilities 
12. Support information security with organizational policies and programs – keeping all employees informed about their duties related to security (see Running in a Secure Environment) 

Some or all these 12 requirements may be applicable to a business depending on whether and how it stores card data. The purpose of these requirements is to achieve set security goals (‘control objectives’): 

• Build and maintaining a secure network and systems (Requirements 1-2) 
• Protect account data (3-4) 
• Maintain a vulnerability management program (5-6) 
• Implement strong access control measures (7-9) 
• Monitor and test networks regularly (10-11) 
• Maintain an information security policy (12) 

Each requirement has hundreds of sub-requirements, adding further layers and levels of detail. 

PCI DSS Compliance Levels 

Not all organisations are required to comply with the PCI DSS in the same way. The number of transactions an organization manages annually determines its level of implementation and the strictness of reporting requirements. These are the PCI DSS compliance levels (also known as ‘reporting or merchant’ levels): 

• Level 1 – Merchants that process over 6 million card transactions per year and Service Providers that store, process, transmit, or have an impact on more than 300,000 card transactions per year 
• Level 2 – Merchants that process 1 to 6 million transactions per year and Service Providers that store, process, transmit, or have an impact on fewer than 300,000 card transactions per year
• Level 3 – Merchants that process 20,000 to 1 million transactions per year 
• Level 4 – Merchants that process fewer than 20,000 transactions per year 

However, other factors beyond annual transaction numbers may shift an organisation to a different level. These include whether they have experienced a recent cyber-attack, or work in an area that poses a particular data security risk. The higher the level, the greater the risk. Correctly understanding the compliance level relating to your organization is the first step to PCI certification. 

PCI DSS Certification 

Typically, to achieve compliance, higher levelled organizations require external audits performs by registered assessors, whereas lower organizations complete self-assessment questionnaires (SAQs).  

The higher the level, the more stringent the reporting requirements for compliance. For example, there are some requirements that Level 1 organizations can satisfy with SAQs too. But Level 1 merchants must complete an annual Report on Compliance (RoC) and complete an Attestation of Compliance (AoC). 

Organizations need to validate their compliance on a yearly basis to achieve compliance. They are also expected to maintain this compliance at all times during the year. For example, all four compliance levels require the completion of quarterly network scans as well as annual penetration testing. 

Also, any third-party service providers (TPSPs) used to process payment care data on behalf of a service provider need to be compliant. TPSPs may include: 

• Electronic point of sale (EPoS) solutions 
• Payment service providers 
• Software providers 
• Till vendors 
• Web-hosting companies 

PCI DSS Fines and Penalties 

Non-compliance may result in fines for the acquiring bank – the financial institution that processes credit and debit card payments for businesses – who bear the brunt of financial penalties. However, banks can hold the merchants and organizations that use their services accountable and pass the fines along to those who have offended. There are also initial and per item penalties. 

Financial consequences may be heaviest for organizations that process large volumes of sensitive data, such as financial institutions. Data breaches can also result in financial loses through fraud, legal fees, and covering the costs of forensic investigations. Then there are non-monetary penalties through loss of trust and reputation, and consequent reduction in income. 

PCI DSS and Cybersecurity 

The PCI DSS was specifically designed to focus on environments with payment card account data. However, it can also be used to protect against threats and secure other elements in the payment and financial ecosystems. 

For further reading on your responsibilities around the PCI-DSS and cybersecurity resources, see: 

• PCI Threat Center – This is a list of resources to help with a range of cybersecurity threats, such as malware, phishing, remote access, weak passwords, outdates software and skimming
• PCI Data Security Essentials – These are resources for guidance on how to keep customer data safe, including a helpful Glossary of Payment and Information Security Terms  
• List of PSI Approved Scanning Vendors (ASV) – External and internal vulnerability scanning and penetration testing are an intrinsic part of PCI DSS compliance 

What is Payara Services Doing to Help You Develop More Secure Applications? 

In addition to the links and pointers already supplied in the PCI-DSS Requirements section above, we recommend you start finding out more about how Payara Services Enterprise’s cybersecurity measures: 

• The Security Guide Overview provides a great place to start  
• Products are released monthly with regular security fixes and patches 
• A full list of Security Advisories is maintained and Payara Services also operates as a CVE Numbering Authority 

Read our Tech Blog, to keep up to date with the latest data security legislation, regulations, and standards. And follow the links to find out how your development team can try one of our products: 

• Payara Server Enterprise for a free trial of our application server for containerized Jakarta EE applications 
• Payara Cloud for a free trial of our cloud native application runtime