PCI DSS Compliance: Guide to the Payment Card Industry Standard

PCI DSS is the common cybersecurity standard established by major credit and debit card companies. It was first established in 2004 by JCB, Visa, Discover, MasterCard and American Express as a way to unify their previous, proprietary standards and help protect sensitive card data such as the card holder’s name, credit card number, expiration date, verification code and PIN.

The rise of online and ecommerce transactions around the time had, unfortunately, led to a similar increase in fraud and theft. Consequently, all major players agreed on the need for increased security wherever card data was processed or stored. Since this first iteration, the members of PCI’s Security Standards Council (SSC) have continued to update the document with new and revised requirements.

As of today, PCI DSS consists of 12 major chapters:

Of course, these sections only represent overarching goals that organizations have to meet, with each chapter divided into a wide range of specific criteria and demands. All in all, there are roughly 250 different requirements included in PCI DSS, though not all of them are applicable to all organizations.

PCI DSS compliance is not technically mandatory, but it is required in order to process payments from issuers such as Visa and Mastercard. Since virtually all credit card companies are PCI members, there is simply no way around PCI DSS compliance for merchants, vendors and service providers who want to meet customer expectations and support card payments.

PCI applies to card data such as the credit card number, card holder and security code. This information is collectively referred to as account data, which is further divided into two categories: cardholder data (CHD) and sensitive authentication data (SAD). IT systems used to store or process this data are known as the cardholder data environment (CHD). Certain PCI requirements apply exclusively to cardholder data or authentication data, such as the rule that authentication data cannot be stored after a transaction has been completed.

All entities that store, process or transmit at least one of the forms of data covered by PCI DSS are required to comply with the security standard. However, a company or vendor that processes payments exclusively through third-party payment services or approved devices (such as point-of-sale terminals and scanners) can effectively outsource certain PCI requirements.

For example, an online store that forwards customers to a compliant payment service during checkout and does not itself store or process account data does not fall under the payment card industry’s third requirement: Protect Stored Account Data. However, they are still responsible for protecting their web server from attacks and manipulation, since hackers that break into your server could redirect customers to fraudulent sites.

Some PCI requirements do not apply if your business processes payments through third-party services only. Adobe Stock, (c) Mymemo

The PCI Document Library provides official information and self-assessment questionaires for various payment setups, such as terminals with or without an internet connection, payment applications, virtual terminals or third-party websites. The specific compliance requirements for each of these technical implementations can be found in separate documents.

PCI DSS not only differentiates between the way payments are processed, but also the number of total transactions per year. Shops, merchants, vendors etc. are divided into 4 levels based on their yearly transactions. An organization’s PCI level does not affect the required safety measures, merely the assessment process: While small businesses only have to submit a self-assessment questionnaire (SAQ), companies that process a large amount of card payments need to verify their PCI DSS compliance through an external review by a qualified security assessor (QSA).

PCI DSS Level Overview

PCI DSS 4.0, published in March 2022, is the latest version of the security standard, bringing with it a number of changes. The main focus of the new and updated requirements is on data encryption and cryptography, assigning roles and responsibilities as well as access control and authentication.

For example, multi-factor authentication is now required for all accounts with access to the cardholder data environment (CDE). Additionally, organizations must conduct access reviews every six months in order to prevent privilege creep and outdated permissions. You can find more information in the official Summary of Changes.

The publication of PCI DSS 4.0 in March 2022 marks the beginning of a two year transition period until the previous iteration PCI DSS 3.2.1 is officially retired on March 31 2024. During the two year transition, organizations can use either PCI DSS 4.0 or 3.2.1 for compliance assessments depending on their preference. More information on the PCI DSS 4.0 timeline.

The full text of the Data Security Standard is available for download on the website of the Security Standards Council (SSC). The document library includes the standard itself, as well as guidelines for implementation, self-assessment questionnaires and templates for written statements such as the attestation of compliance (AOC).

At roughly 400 pages in length, PCI DSS can appear overwhelmingly complex at first glance. To help you get started, we’ve compiled a summary of the key requirements outlined in each of the 12 PCI DSS chapters.

The first section of PCI DSS concerns the installation and maintenance of network security controls (NSC), i.e. firewalls and similar safety measures. The overarching goal of this chapter is to restrict incoming and outgoing network traffic to secure, necessary and authorized connections.

In order to achieve this, organizations are required to configure network security controls following established IT best practices, review the configuration every six months and create a network diagram that details devices within the PCI DSS scope and the data flow of protected information between them. Additionally, organizations must implement anti-spoofing measures and monitor network settings for unauthorized changes.

To prevent attackers from exploiting default passwords and known weaknesses, this requirement demands organizations securely configure all system components (also known as hardening). This includes removing unused default accounts, changing default passwords and deactivating unnecessary features. Another requirement is to isolate key functions that require different levels of security from one another, for example by separating web servers from application and database servers.

In order to safeguard critical information, PCI DSS generally requires organizations to keep both the amount of data and duration of storage to the minimum needed for legal and business purposes. Sensitive authentication data (SAD) cannot be stored after a transaction has been successfully authorized. Stored cardholder data must be protected using encryption and strict access controls. In particular, the primary account number (PAN) must be masked when displayed, showing only bank identification and the last four digits of the account. The full PAN is only available to personnel with a legitimate need.

Card holder and authentication data must be protected both during transmission and when stored. Adobe Stock, (c) xiaoliangge

The use of strong encryption is mandated not only for stored data, but also during the transmission of information over open, public networks. The specific requirements outlined in this section cover the management of cryptographic keys and certificates, as well as the use of secure protocols. For more details on encryption standards, the Security Standards Council refers to publications such as NIST 800-57 and ISO/IEC 18033.

To protect against malicious software, PCI DSS mandates the use of anti-malware solutions on all at-risk devices. Requirements for implementing malware protection include automatic updates to combat the latest threats, as well as either continuous surveillance or regular automated scans. How often malware scans must be performed on a given device depends on the results of the targeted risk analysis required by section 12. Removable storage media such as flash drives must likewise be scanned before use.

The requirements for secure software development apply mainly to organizations that use custom or self-developed software. However, this chapter also lays out criteria for vulnerability management, such as maintaining an inventory of all currently used software products, applying security patches and staying up to date on new threats like zero day vulnerabilities.

In order to prevent the theft or misuse of cardholder data, access to protected information as well as any systems which impact the security of the CDE must be strictly limited. PCI DSS defines appropriate access in terms of business need to know and least privilege, two concepts that are often used interchangably, but here refer to two separate ideas:

To put it more simply, the idea behind this requirement is that accounts should only be given access rights that are strictly necessary in order to perform their intended role. This applies not only to user accounts, but also to service, device and system accounts. Additionally, organizations must pay attention to segregation of duties to prevent a single user from holding permissions that could lead to abuse or conflicts of interest. The easiest way to assign appropriate access to users across various positions and departments is through a model known as role-based access control, which defines standard privileges for various roles within an organization.

Since the tasks and responsibilities of users are constantly changing, the only way to ensure that least privilege access is maintained long-term is through regular access reviews. The payment card industry requires businesses to review all user accounts and permissions every six months. Inappropriate access, such as outdated permissions and orphaned accounts, must be addressed during this process.

Before access is granted, users must verify their identity. In order to attribute actions to specific individuals, each user must be assigned a unique ID. The use of shared accounts is only permissable in a few, limited cases. Any accounts with access to the cardholder data environment must be secured using multi-factor authentication (MFA). To prevent fraudulent logins, accounts must be locked down after a maximum of ten failed login attempts. A session timeout of 15 minutes is required to prevent device misuse.

Protecting accounts requires managing the entire user lifecycle, from creation to deletion. To qualify for PCI DSS compliance, accounts can only be created or updated by authorized users, with all changes being documented for admin review. When an employee leaves your organization, access must be revoked immediately. Inactive accounts, such as unused accounts of current employees, must be deleted within 90 days.

Aside from logical access to car holder data, PCI DSS also requires compliant organizations to limit physical access to records and IT systems. Here, the standard differentiates between sensitive areas such as server rooms and the cardholder data environment on the whole. Among the requirements put forth in this chapter are access restrictions, video monitoring systems, safeguards for network access points, and the safe storage and destruction of physical media and records. Further, payment devices must be periodically inspected to prevent tampering through card skimmers and similar devices.

In order to detect suspicious activity and support forensic analysis, audit logs must be enabled for all relevant systems. To protect against tampering, audit logs must be stored safely and under strictly limited access. Events that should be captured, logged and monitored include:

Since rigorous tracking produces an enormous amount of data, the SSC recommends the use of an automated security information & event management (SIEM) solution to assist with log analysis and the detection of anomalies and significant changes. Regardless of method, organizations must review security events daily. The same applies to the logs of components that 1) store, process or transmit protected data, 2) perform critical functions or 3) perform security functions.

Since both researchers and attackers continuously discover new weaknesses and exploits, PCI DSS mandates regular security checks in the form of vulnerability scans and penetration tests. External and internal vulnerability scans must be conducted every three months as well as following significant changes to your IT environment. The scan is repeated until all vulnerabilites with a CVSS score of 4.0 or higher have been resolved. Vulnerabiliites that fall below this threshold must be documented and addressed in a timeframe appropriate to the targeted risk analysis of chapter 12.

Internal scans can be conducted by qualified members of your own staff, as long as you take steps to avoid conflicts of interest. For example, a system should not be tested by the same employee who is responsible for its ongoing operation and maintenance. External scans can only be performed by approved scanning vendors (ASV). Internal and external penetration tests must be conducted every 12 months following the same criteria.

PCI DSS compliance is a complex endeavor that requires not only technical security measures, but also staff awareness, training and cooperation. To this end, companies are required to maintain an information security policy that communicates objectives and responsibilites to their own staff, as well as vendors and business partners. To guard against insider threats, companies must screen also screen staff before hiring. Background checks must, of course, follow local privacy and employment laws.

The information security policy must be reviewed every 12 months and updated as necessary in regards to scope, the inventory of software and hardware products, as well as agreements with third-party service providers (TPSP). This includes checking whether TPSPs are still PCI-compliant themselves. Additionally, organizations must prepare emergency plans and prodedures in order to adequately respond to attacks and data breaches.

The organizational requirements of PCI DSS closely mirror the demands of security standards such as ISO 27001 or the NIST cybersecurity framework. A company that has completed a similar certification can therefore focus on implementing PCI-specific requirements such as yearly reviews of the PCI status of third-party services.

PCI-compliant user management? No problem with tenfold IAM! Adobe Stock, (c) thodonal

The steps required to achieve PCI DSS compliance depend on your organizations IT infrastructure and role of card data in your daily operations. Businesses that process payments exclusively through compliant external services and devices will have an easier time meeting requirements of the Security Standards Council than companies that store cardholder data on their own servers.

However, it’s important to note that PCI DSS compliance can never be fully outsourced. Not only is a merchant or vendor still responsible for managing agreements with third-party services and tracking their provider’s compliance status: They must also secure their own network against data breaches. Even systems that do not store or process credit card data can still fall under the scope of PCI DSS. This is due to the fact that attacks on your company’s IT can indirectly affect the safety of card information – for example if attackers steal login data or security logs.

As a result, organizations still need to meet the security requirements of payment card industry in any parts of their network that can impact the security of cardholder data or devices with access to the cardholder data environment. Requirements such as secure configuration, malware protection and user and access management.

The payment card industry’s goal with PCI DSS is to make sure credit card data doesn’t fall into wrong hands despite its widespread use for both online and offline payments. In IT systems, the question of who can view or edit sensitive data is governed through access rights that determine which users hold which permissions for which assets. In other words, when it comes to preventing unauthorized access from within and without, identity and access management plays a fundamental role. There’s a reason why PCI DSS requires organizations to implement strong access control measures.

However, without a dedicated IAM solution, enforcing appropriate access for large groups of users is a nigh impossible task. Accounts and permissions must be individually updated as employees join, switch roles or leave. Privileges must be painstakingly documented and regularly reviewed in order to ensure that all access rights meet the least privilege/need to know standard.

The good news? tenfold can do all of that for you! By offering automated user management, permission reporting and access reviews, tenfold guarantees appropriate access for all users across all systems. Maximum security, minimal effort.

PCI DSS Requirements covered by tenfold

As a central platform for identity and access management, tenfold helps organizations automate account creation and deletion, user provisioning, permission reporting, access reviews and much more! Thanks to its deep integration with Microsoft and third-party systems, as well as a user-friendly self-service interface, tenfold not only lowers your IT workload, but ensures that sensitive data remains safe from prying eyes.

tenfold will help you both achieve PCI DSS compliance and prepare for assessment audits thanks to its detailed reporting and comprehensive change tracking. Not convinced yet? Check out our demo video for a tour of tenfold‘s most important features. Or sign up for a free trial to experience our intuitive IAM solution firsthand and learn more about the advantages of tenfold.