PCI DSS Compliance: Everything You Need to Know
The U.S. Federal Trade Commission (FTC) data shows that credit cards were responsible for 42,545 fraud reports filed in 2022. This alarming statistic clearly points to the importance of protecting cardholder data, especially as economies worldwide move toward cashless and contactless payment systems.
If you accept payment cards for goods or services, you must address the risk of data compromise by adopting effective security procedures laid out in the Payment Card Industry Data Security Standard (PCI DSS). This blog explains everything you need to know about PCI DSS and PCI DSS compliance.
What is PCI DSS?
The PCI DSS is a set of security requirements that must be implemented by all organizations that process, store or transmit cardholder data. Launched on September 7, 2006, the PCI DSS provides the necessary framework for developing a comprehensive payment card data security process for prevention, detection and appropriate reaction to security incidents.
Although the PCI Security Standards Council (PCI SSC) introduced PCI DSS, it’s important to note that organizations are responsible for enforcing PCI DSS compliance, not the PCI SSC.
What is the purpose of PCI DSS?
The objective of the PCI DSS is to optimize the security of credit, debit and prepaid card transactions to protect cardholders against theft or misuse of their sensitive information. The PCI DSS specifies 12 requirements for compliance, organized into six logically related groups called “control objectives.” Each version of the PCI DSS has divided these six requirements into sub-requirements.
The six control objectives are:
- Build and maintain a secure network and systems
- Protect cardholder data
- Maintain a vulnerability management program
- Implement strong access control measures
- Regularly monitor and test networks
- Maintain an information security policy
What data is protected by the PCI DSS?
PCI DSS covers two types of payment information — cardholder data and sensitive authentication data (SAD). The cardholder data constitutes of:
- Primary account number (PAN)
- Cardholder name
- Expiration date of the card
- Service code
SAD refers to:
- Full track data (whether magnetic stripe or chip)
- PINs/PIN blocks
Who regulates PCI DSS?
PCI DSS is regulated by the PCI SSC, which was founded in 2006 by American Express, Discover, JCB International, MasterCard and Visa. Each member has incorporated the PCI DSS as a part of the technical requirements for their respective data security compliance programs. They also recognize assessors qualified by the PCI SSC.
According to the PCI SSC, the standard uses a strategic framework “to enhance global payment account data security by developing standards and supporting services that drive education, awareness and effective implementation by stakeholders.” The framework is built on four pillars:
- Increase industry participation and knowledge
- Evolve security standards and validation
- Secure emerging payment channels
- Increase standards alignment and consistency
What is the current version of PCI DSS?
The PCI SSC released version 4.0 of the PCI DSS on March 31, 2022, to replace version 3.2.1. The latest version better addresses emerging threats and technologies and provides innovative ways to combat new threats. Version 3.2.1 will still be valid until March 31, 2024. This transition period is intended to provide organizations with time to familiarize themselves with the changes in PCI DSS. The new requirements must be implemented by March 31, 2025.
What is PCI DSS compliance?
Compliance requirements vary depending on the type and volume of transactions carried out by the company and are determined by the bank processing the transactions. To demonstrate full compliance with PCI DSS, organizations must implement technical and operational safeguards to secure and protect cardholder data that is transmitted during card processing transactions. You must comply even if cardholder data functions are outsourced.
Is PCI DSS compliance mandatory?
PCI DSS is not a law, as PCI SSC is not a government agency. Therefore, the standard does not fall under the purview of traditional regulatory compliance requirements. However, several state governments, such as Nevada, have included PCI DSS directly into state law. Lastly, PCI DSS compliance is a contractual obligation mentioned in an agreement between the vendor and a card company. The agreement often lists fees for non-compliance.
Who must comply with PCI DSS?
If you accept, handle, store or transmit cardholder data, you must be PCI-compliant. There are no exemptions based on the size of your organization or the number of transactions you process.
Credit, debit and prepaid cards used by customers fall under the purview of cardholder data. Organizations that accept card data online, in the store, over the phone or on an application need to comply — including any that depend on third-party payment gateways.
What are the four levels of PCI DSS compliance?
PCI DSS compliance is divided into four levels. Based on the number of card transactions your organization processes annually, you must comply with one of the four levels. The level determines the rules you must follow to remain compliant.
The four levels of compliance are:
- Level 1: Organizations processing over 6 million transactions per year
- Level 2: Organizations processing 1 million to 6 million transactions per year
- Level 3: Organizations processing 20,000 to 1 million transactions per year
- Level 4: Organizations processing less than 20,000 transactions per year
PCI DSS Level 1
Level 1 mandates an annual report completed by a qualified security assessor (QSA) or an internal security assessor (ISA). A QSA visits on-site to conduct an audit whereas an ISA can be a member of your team trained to conduct an assessment and act as a liaison to external auditors.
During the audit, you must submit an attestation of compliance (AOC) form stating that you have complied with the requirements as listed by PCI DSS standards. Any organization that suffers a data breach is also subject to an external audit, even if they are not categorized as a Level 1 merchant.
You are also required to perform a quarterly vulnerability scan of your network from an approved scanning vendor (ASV). Lastly, you would have to get a penetration test done at least once every year for a more comprehensive understanding of possible vulnerabilities.
PCI DSS Level 2
At this level, your organization is exempt from undergoing an on-site PCI audit. However, you are expected to complete a self-assessment questionnaire (SAQ). Through the SAQ, you state how you have implemented the necessary security measures to keep cardholder data secure. Types of SAQs vary based on the scope of the audit and, subsequently, the number of questions you must answer.
Other requirements for this level are a quarterly scan by an ASV, an internal scan, the completion of an AOC form and an annual penetration test (like in the case of Level 1). Your organization might be subject to an on-site audit and an annual compliance report if you suffer a data breach or if the bank processing your transactions deems it necessary.
PCI DSS Level 3
Like Level 2, Level 3 directs organizations to complete an SAQ, perform a quarterly network vulnerability scan and submit an AOC form. An organization is not required to get a penetration test done.
Please note that JCB International, one of the founding members of the PCI SSC, does not have Level-3 PCI compliance. Organizations processing less than 1 million JCB transactions annually are expected to comply with Level 2.
PCI DSS Level 4
The lowest level of audit set in the PCI DSS, Level 4 requires organizations to complete the appropriate SAQ, run quarterly network vulnerability scans and complete an AOC form. Fulfilling the requirements for this level is equally important since you would still have to attest that you have all the appropriate security measures in place in accordance with the PCI DSS.
What are the 12 requirements for PCI DSS compliance?
The PCI DSS requirements apply to all system components — including people, processes and technologies included in the cardholder data or cardholder data environment — and to the storage, processing or transmission of card data linked to that environment. The 12 requirements are:
- Installing and maintaining a firewall configuration to protect cardholder data
- Changing vendor-supplied defaults for system passwords and other security parameters
- Protecting stored cardholder data
- Encrypting transmission of cardholder data over open, public networks
- Protecting all systems against malware and performing regular updates of antivirus software
- Developing and maintaining secure systems and applications
- Restricting access to cardholder data to only authorized personnel
- Identifying and authenticating access to system components
- Restricting physical access to cardholder data
- Tracking and monitoring all access to cardholder data and network resources
- Testing security systems and processes regularly
- Maintaining an information security policy for all personnel
Let us take a deep dive into all the requirements by grouping some of them together based on their similar goals.
Build and maintain a secure network and systems
The objective for the first two requirements is self-explanatory — building a resilient network and ensuring the systems in it are secure. While the first requirement emphasizes the installation of firewalls, the second one focuses on eliminating an extremely common cause of data compromise.
Requirement 1: Install and maintain network security controls
Properly configured firewalls block foreign or unknown entities from accessing sensitive data. They are often effective as the first line of defense against cyberthreats (external and internal). This requirement directs organizations to build firewalls to limit access to the cardholder data environment (CDE). You can fulfill this requirement by installing both hardware and software firewalls.
Requirement 2: Apply secure configurations to all system components
The second requirement suggests disabling “all unnecessary default accounts before installing a system on the network” since most default passwords provided by vendors are either too easy to crack or already known. You must prevent users in your network from creating accounts using default passwords.
At times, your third-party vendors can use default passwords. However, you must ensure they follow the same steps for fulfilling the second requirement.
Protect account data
The next two requirements are aimed at protecting cardholder data — both when it is stored and in transmission. The key factor in both these requirements is encryption.
Requirement 3: Protect stored account data
This requirement lists steps to prevent malicious actors from accessing cardholder data. It states that stored card data must be encrypted using industry-accepted algorithms and the encryption keys must also be protected.
You must ask all departments whether they receive cardholder data, and then use their answers to determine the flow of card data. You must also identify the location of unencrypted PAN and other sensitive pieces of information so you can delete or encrypt them.
Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks
To fulfill this requirement, you must know how you transmit cardholder data and secure the transmission of the data over open, public networks using encryption and security policies. You can do this by:
- Using trusted keys/certificates, secure transport protocols and proper encryption
- Never sending unencrypted PAN using email, instant messaging, text or chat
- Documenting and distributing security policies and operational procedures for encryption
Maintain a vulnerability management program
Detecting and managing vulnerabilities in a timely manner is equally crucial (if not more) than having an arsenal of security solutions.
Requirement 5: Protect all systems and networks from malicious software
You must protect systems on your network that can be targeted by malware. More importantly, you must pay attention to evolving malware threats and update antimalware programs accordingly. You can meet this requirement by:
- Installing antivirus software on systems and devices commonly targeted by malware
- Keeping antivirus solutions up to date by performing periodic scans and reviewing audit logs
- Keeping antivirus solutions running and preventing users from disabling them
- Documenting and distributing security policies and operational procedures for protection against malware
Requirement 6: Develop and maintain secure systems and software
No application or software is perfect, which is why manufacturers regularly release updates to patch security issues. Therefore, this requirement instructs organizations to install all critical patches within a month of their release.
Implement strong access control measures
Only the right people should be able to access the data — a statement that summarizes the objective of the next three requirements. They focus on restricting and authenticating both physical and virtual access to cardholder data and CDE.
Requirement 7: Restrict access to system components and cardholder data by the business’s need to know
Your organization must make sure that only those who absolutely need to interact with cardholder data have access to it. You must clearly define user roles and the privileges assigned to each role by building and regularly updating a role-based access control (RBAC) system.
Here are some of the crucial steps that you must take:
- Define access according to roles, like user or administrator
- Restrict privileged user IDs according to need
- Assign access based on job classification and function
- Require access request approval documentation
- Use default “deny all” settings
- Document the entire process
Requirement 8: Identify users and authenticate access to system components
This requirement lays down the rules for verifying that all users are authorized and ensuring any activity can be traced to an individual. Organizations are required to assign a unique ID to all users who can access cardholder data and implement multifactor authentication (MFA) to identify every user. This helps prevent internal fraud and detect whether a user’s login information have been hacked.
Requirement 9: Restrict physical access to cardholder data
This requirement mandates organizations to secure the physical environment in which card payments are accepted and where cardholder data is transmitted or stored. They must mandate the physical identification of employees who accept physical card payment and restrict access to areas where on-site personnel handle cardholder data. All documentation with cardholder data must be rendered unreadable and stored in a physically secure location.
Regularly monitor and test networks
“Monitor, test and document” is the mantra of the 10th and 11th PCI DSS requirements. The requirements make organizations turn the process into a habit and not just a one-and-done affair.
Requirement 10: Log and monitor all access to system components and cardholder data
Storing and reviewing audit logs and audit trails helps detect anomalous login activity indicating malicious activity. Requirement 10 provides guidelines for logging, tracking and monitoring all user activities. It also dictates that the audit trail data must be stored for a year without alteration, with at least three months of data being immediately accessible for review.
Complying with this requirement also involves a daily review of the logs to detect errors, anomalies and suspicious activities. You must also build a process to tackle the discovered anomalies.
Requirement 11: Test the security of systems and networks regularly
You open the doors to new and unknown vulnerabilities with every change to your organization’s network. These need to be detected and mitigated before they cause any damage. This requirement provides a detailed overview of how an organization must conduct vulnerability scans and penetration tests, including timelines and schedules.
Maintain an information security policy
Unless your organization has a comprehensive and well-documented information security policy, it can’t protect cardholder data. The final PCI DSS requirement focuses on establishing these policies.
Requirement 12: Support information security with organization policies and programs
The final PCI DSS requirement is related to employee training, risk minimization and establishing a robust security policy that is followed across your organization. You must document policies, procedures and evidence relating to your organization’s security practices. The security policy must be reviewed annually and you must conduct an annual, formal risk assessment to identify critical assets, threats and vulnerabilities.
What are the benefits of complying with PCI DSS?
The benefits of PCI DSS compliance can be:
- Greater customer trust: PCI DSS certification assures customers that you value data protection and have adopted adequate security measures to secure their data.
- Reduced legal risks: By complying with the PCI DSS, you can avoid costly lawsuits that non-compliant organizations can be subjected to.
- Better protection against cyberattacks: Adopting the PCI DSS ensures better protection against cyberattacks and makes you a less likely target.
- Staying clear of hefty fines: Avoid monthly fines between $5,000 and $100,000 — issued based on your transaction volume and the number of violations — by ensuring PCI DSS compliance.
- Avoid higher bank charges: The card companies charge penalties to the merchant banks who then pass them on to you. The banks can charge a higher transaction fee, revoke your right to accept card payments and even close your merchant account over non-compliance.
What happens if a company is not PCI DSS compliant?
The increased risk of experiencing a data breach and being subjected to hefty fines could wipe out any possibility of your organization processing any cardholder data in the future. Your sales plummet as banks and payment companies could simply choose not to do business with you.
How do you maintain PCI DSS compliance?
Your organization’s resilience against cyberthreats is tested every day, if not every minute, so there really is no option but to maintain full compliance with PCI DSS. The requirements and levels of compliance are built in a way to hold organizations accountable if they fail to maintain compliance and prove it. It is imperative that you fulfill every single requirement and follow all the steps needed to achieve and retain the necessary level of compliance.
Manage PCI DSS compliance with Compliance Manager GRC
Compliance Manager GRC automates and simplifies much of the PCI compliance process. Select the PCI DSS SAQ template that applies to your organization and Compliance Manager GRC will pull the required questions from over 1,800 pages of documentation about more than 300 security controls covered by the PCI DSS.
Run a Rapid Baseline Assessment to quickly see where you stand, and/or optionally run the built-in data collectors to answer questions and provide evidence of compliance. Use the dynamic plan of actions and milestones (POA&M) dashboard to address any issue and collect any missing information needed to prove due care in the event of a breach.
Request a demo today and discover how Compliance Manager GRC can make your PCI DSS compliance journey smooth and safe.