Take the lead in data protection best practices with our unified SIEM solution!
What is PCI DSS compliance?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards developed to ensure the protection of cardholder data during credit card transactions. It aims to establish a secure environment for organizations that handle credit card payments, reducing the risk of data breaches, fraud, and unauthorized access to sensitive information.
In 2006, the Payment Card Industry Security Standards Council (PCI SSC) was established by leading payment brands such as American Express, Discover Financial Services, JCB International, Mastercard, and Visa. This marked a significant milestone in the development of unified security standards. Presently, the council boasts over 700 member organizations spanning more than 60 countries. Its primary mission is to promote adherence to, and enhance comprehension of, these vital security principles within the financial industry.
What data does the PCI DSS protect?
The PCI DSS specifically protects cardholder data and sensitive authentication data. Below are the details on what comprises these categories:
1. Cardholder data
Cardholder data refers to any information printed, processed, transmitted, or stored in any form on a payment card. According to the PCI DSS, cardholder data includes:
- Primary Account Number (PAN): This is the most critical piece of cardholder data and is always considered sensitive and must be protected if stored.
- Cardholder Name: The name as it appears on the front of the payment card.
- Expiration Date: The month and year the payment card expires, as shown on the card.
- Service Code: A set of numbers and/or letters that appear on the payment card which define the card attributes and permissions.
2. Sensitive authentication data
Sensitive authentication data includes security-related information which is used to authenticate cardholders and authorize payment card transactions. The PCI DSS requires that this data should never be stored after authorization, even if encrypted. This includes:
- Full t rack d ata ( m agnetic s tripe d ata or equivalent on a chip): This data is found in the magnetic stripe or chip used to authenticate card data and includes PAN, cardholder name, expiration date, and service code.
- CAV2/CVC2/CVV2/CID: These are the three or four-digit numbers found on the front (American Express) or back (Visa, Mastercard, and Discover) of the card that are used to secure "card-not-present" transactions.
- PIN/PIN b lock: The personal identification number (PIN) entered by the cardholder during a card-present transaction and the encrypted PIN block present within the transaction message.
Why protect this data?
Protecting this data is essential for several reasons:
- Preventing fraud: Secure handling of cardholder and sensitive authentication data reduces the risk of card fraud.
- Avoid ing d ata b reaches: Proper security measures help prevent data breaches that can be costly for businesses to address.
- Build ing t rust: Ensuring the security of payment data helps build trust between merchants and their customers.
- Comply ing with l egal r equirements: Compliance with the PCI DSS is not optional for businesses that handle card payments. Noncompliance can result in hefty fines and penalties.
Who must comply?
The PCI DSS applies universally to any entity (i.e., participants involved in payment card processing, including merchants, service providers, financial instituitions, etc.) engaged in the storage, processing, or transmission of cardholder data. It encompasses both technical and operational aspects of system components associated with cardholder data or connected to it. Therefore, if you are a merchant involved in the acceptance or processing of payment cards, adherence to the PCI DSS is mandatory.
Who are merchants?
A merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of the PCI SSC, which includes Visa, Mastercard, American Express, Discover, and JCB, as payment for goods or services. Merchants come in various sizes and types, from small, local stores to large, multinational corporations, and they must comply with the PCI DSS to varying degrees based on the volume of transactions they process.
Categories of merchants
- Level 1: Processes over six million transactions per year across all channels, or has suffered a data breach/data compromise that resulted in account data being compromised.
- Level 2: Processes one to six million transactions per year across all channels.
- Level 3: Processes 20,000 to one million e-commerce transactions per year.
- Level 4: Processes fewer than 20,000 e-commerce transactions per year, or up to one million transactions annually across all channels.
Depending on transaction volume and the specific requirements laid out by their acquiring bank, merchants must validate their compliance annually either through an external qualified security assessor (QSA) or via a Self-Assessment Questionnaire (SAQ).
Who are service providers?
A service provider refers to an organization that handles cardholder data for another entity or has the potential to influence the security of the cardholder data environment. This encompasses activities such as processing, storing, or transmitting cardholder data. Managed service providers offering services like managed firewalls, intrusion detection systems, and other security services are typical examples.
Categories of service providers
- All service providers included in the PCI DSS scope are required to be compliant with the PCI DSS and validate compliance annually, usually through a Report on Compliance (ROC), which is an official document that verifies an entity's adherence to the PCI DSS requirements, typically completed by a QSA for larger organizations processing high volumes of transactions.
Service providers play a critical role in the payment ecosystem as they often handle sensitive cardholder data or sensitive authentication data, making their compliance with the PCI DSS critical to the overall security of the payment system.
Who is a PCI DSS QSA?
A QSA is an individual working for a QSA company, which is certified by the PCI SSC to conduct PCI DSS assessments. QSAs must meet specific requirements set by the Council, and both the individual assessors and their companies undergo certification and re-certification to ensure they adhere to the Council's standards for performing assessments. It's recommended to verify the current qualification status of a QSA each time their services are engaged.
What is an SAQ?
The Self-Assessment Questionnaire (SAQ) is a tool used by PCI DSS to help merchants and service providers report the results of their PCI DSS self-assessment. The SAQ includes a series of questions corresponding to the PCI DSS requirements that are applicable to their payment card operation. The purpose of the SAQ is to assist entities in evaluating their compliance with PCI DSS standards.
Types of SAQs
There are several types of SAQs, all designed to meet different scenarios depending on how an organization handles payment card data:
- SAQ A: For merchants with all cardholder data functions outsourced. This could be to e-commerce, mail, or telephone order merchants who have completely outsourced all cardholder data functions.
- SAQ A-EP: For e-commerce merchants who partially outsource their cardholder data processing to third-party service providers but do not store, process, or transmit any cardholder data on their systems or premises.
- SAQ B: For merchants using only standalone, dial-up payment terminals and do not store cardholder data electronically.
- SAQ C: For merchants with payment application systems connected to the internet, without electronic cardholder data storage.
- SAQ D: For those who do not fit the descriptions of the prior SAQ types and are often service providers whose operational models include storing, processing, or transmitting cardholder data.
What are the four PCI DSS levels?
PCI compliance is categorized into four levels based on the annual volume of card transactions handled:
- PCI Level 1 : Businesses processing over six million transactions annually.
- PCI Level 2 : Businesses processing one million to six million transactions annually.
- PCI Level 3 : Businesses processing 20,000 to one million transactions annually.
- PCI Level 4 : Businesses processing fewer than 20,000 transactions annually. Merchants can ascertain their PCI compliance level by coordinating with their service providers or utilizing reporting tools. It is advisable to verify the specific merchant levels applicable to the credit card companies used.
For businesses aiming to achieve PCI DSS compliance and establish themselves as reliable brands, the initial and crucial step is determining their current PCI DSS compliance level.
What are the 12 PCI DSS requirements?
PCI DSS outlines 12 requirements that organizations must adhere to in order to protect cardholder data and achieve compliance. These requirements are designed to establish a secure environment for credit card transactions and mitigate the risk of data breaches.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
This requirement involves setting up firewalls to create a barrier between the cardholder data environment and other networks, such as the internet. The purpose is to prevent unauthorized access to the network and the sensitive data it contains. Companies must have formal policies for firewall and router configurations to ensure they are properly set up and maintained.
Use case: A retail company implements a stateful firewall to monitor and control all incoming and outgoing network traffic based on predetermined security rules to prevent unauthorized access to its network where payment systems reside.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Default passwords and settings provided by vendors are often well known and pose a significant security risk. This requirement emphasizes changing default passwords and settings to secure configurations, disabling unnecessary services and accounts, and removing unnecessary functionality to minimize potential vulnerabilities.
Use case: A restaurant chain customizes all passwords and security settings on its new point-of-sale (POS) systems upon installation, changing default passwords and disabling unnecessary services to enhance security.
Requirement 3: Protect stored cardholder data
This involves employing data protection methods such as encryption, truncation, masking, and hashing to safeguard stored cardholder data at rest and transit. Data at rest refers to inactive data that is stored physically in any digital form (e.g., databases, hard drives, off-site backups). Protecting data at rest involves ensuring unauthorized users cannot access or modify it, typically using encryption, strong access controls, and data masking techniques. Data in transit is any data that is moving across a network, including transfers from local storage to a remote server or between locations on the web. Data in transit is susceptible to interception, eavesdropping, or manipulation, thus requiring strong encryption protocols like TLS or VPN services to secure it. The aim is to render the data unreadable and useless to unauthorized individuals, even if they manage to gain access to it. This requirement says organizations must encrypt cardholder data when stored, whether on disk, in databases, or other storage mediums. They must also implement strong cryptography and key management practices.
Use case: An e-commerce site encrypts database records containing cardholder data using strong cryptographic algorithms to ensure that cardholder data is unreadable and protected against unauthorized access.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Cardholder data that is transmitted over open, public networks (like the internet) must be encrypted to protect against interception by malicious actors. Secure transmission technologies such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS), Internet Protocol Security (IPSec), and Secure Shell (SSH) are typically used to meet this requirement.
Use case: An online book store uses TLS to encrypt data transmissions between its customers’ web browsers and its servers when processing credit card payments to prevent the interception of data.
Requirement 5: Protect all systems against malware and regularly update antivirus software or programs
This requirement mandates the use of antivirus software on all systems that are commonly affected by malware (including personal computers and servers). One of the primary functions of antivirus software is to prevent, detect, and remove malware infections. Malware, or malicious software, includes viruses, worms, Trojans, ransomware, spyware, and other harmful computer programs that can be used to gain unauthorized access to systems, steal sensitive information, and disrupt computer operations. By installing and regularly updating antivirus software, businesses can reduce the risk of malware infections that might compromise cardholder data.
Use case: A financial services provider deploys antivirus software across all its desktops and servers, ensuring it is set to update automatically to protect against malware specifically targeting cardholder data.
Requirement 6: Develop and maintain secure systems and applications
This requirement is comprehensive, including directives for secure development practices, vulnerability management, and the deployment of security patches, which are crucial for closing security gaps that could be exploited by cyberattackers. Specifically, it involves ensuring that all system components and software are protected from known vulnerabilities by installing applicable security patches within one month of release, employing secure coding practices (validated by industry standards like OWASP), performing security assessments, and executing code reviews.
This requirement also calls for the development of secure applications by using a formalized software development process, integrating information security throughout the life cycle, and training developers in secure coding guidelines. The goal is to minimize the risks associated with software vulnerabilities, which can lead to unauthorized access or attacks such as data breaches, ensuring that the integrity and confidentiality of cardholder information are maintained at all times.
Use case: A mobile payment app developer regularly applies patches from vendors and conducts security reviews of their software code before release to spot potential vulnerabilities like SQL injection flaws.
Requirement 7: Restrict access to cardholder data by business need-to-know
This requirement ensures that access to cardholder data is given only to individuals whose job requires such access. The principle of least privilege is applied to minimize the number of people who have access to sensitive information, thereby reducing the risk of data exposure.
Use case: A health insurance company implements role-based access controls to ensure that only billing department staff have access to cardholder data based on their job responsibilities.
Requirement 8: Identify and authenticate access to system components
This involves implementing measures to authenticate and uniquely identify each person with access to the cardholder data environment, such as assigning a unique ID to each user and adopting strong authentication methods (e.g., passwords, tokens, biometrics, MFA).
Use case: A hotel assigns individual user IDs to each of its employees who interact with their payment processing systems to enable tracking of actions on critical data systems.
Requirement 9: Restrict physical access to cardholder data
Physical access to systems and media containing cardholder data must be controlled and restricted to authorized individuals. This includes secure management of physical media (e.g., paper records, hard drives), proper disposal of media containing cardholder data, and maintaining strict control over the physical access to data processing facilities.
Use case: A data center housing servers storing cardholder data uses biometric authentication (e.g., fingerprint scanners) at all entry points to secure its facilities and prevent unauthorized physical access.
Requirement 10: Track and monitor all access to network resources and cardholder data
Audit and monitor accesses and activities of users using an automated and centralized log management solution. This requirement is pivotal for detecting, preventing, and responding to security breaches that could compromise cardholder data. It encompasses a set of specific protocols for creating audit trails that are critical in providing a historical security record to help identify the source of a data compromise.
Use case: A large retail company implements logging mechanisms that record and monitor all access to network resources and cardholder data to detect and respond to security incidents promptly.
Requirement 11: Regularly test security systems and processes
Regular testing of security systems and processes is required to ensure they are effective and to identify vulnerabilities. This can include penetration testing, vulnerability scans, and testing of security controls to ensure they function correctly and protect the cardholder data environment as intended.
Use case: An IT services firm conducts monthly vulnerability scans and annual penetration testing on its networks that store cardholder data to identify and remediate security weaknesses.
Requirement 12: Maintain a policy that addresses information security for all personnel
This requirement emphasizes the importance of maintaining a strong security policy that is communicated to and understood by all personnel. This includes the establishment of an information security policy, regular security awareness training, and an incident response plan in case of a data breach.
Use case: A law firm develops comprehensive security policies that are reviewed annually and provides regular security training to its employees to ensure they understand and can implement these security measures.
Resources
How to be PCI DSS compliant
To comply with PCI DSS requirements, entities involved in storing, processing, or transmitting cardholder data must follow a structured approach. This involves a series of steps that help ensure all aspects of the PCI DSS are addressed effectively. Here is a detailed breakdown of each step:
- Step 1 : Defining the scope The first step is to accurately determine the scope of compliance by identifying all system components, processes, and networks that are involved in handling cardholder data. This includes any systems that can impact the security of the cardholder data environment (CDE). It's essential to clearly define the CDE to focus the compliance efforts on the relevant parts of the network, reducing complexity and cost.
- Step 2: Assessing the environment Once the scope is defined, the next step involves assessing the compliance of all in-scope system components against the PCI DSS requirements. This assessment can be carried out internally using a SAQ or performed by an external auditor or QSA. Either way, the goal is to identify any gaps in compliance and understand the level of adherence to each of the requirements.
- Step 3: Generating the compliance report After the assessment, the entity must complete the necessary documentation, which varies based on the entity's size and transaction volume. Smaller merchants may be eligible to complete a SAQ, while larger merchants and service providers might require a more detailed ROC. This documentation includes details of the PCI DSS requirements, how the entity complies with each requirement, and any compensating controls that are in place.
- Step 4: Getting attestation Following the completion of the required reports, the entity must complete an Attestation of Compliance (AOC), which is a formal declaration of the entity's compliance status with the PCI DSS. This attestation is signed by an officer of the company, asserting the accuracy and completeness of the PCI DSS assessment.
- Step 5: Submission of reports The SAQ or ROC, along with the AOC and other requested supporting documentation like scan reports from an Approved Scanning Vendor (ASV), must be submitted to the relevant parties. For merchants, this usually means submission to their acquirer (the bank or financial institution that processes their card payments). For service providers, the documentation is typically submitted to the payment brand or requestor that requires the compliance validation.
- Step 6: Taking remedial actions If the assessment uncovers any areas of noncompliance, the entity must address these through a process of remediation. This involves fixing the issues that were identified during the assessment to bring the system components into compliance. Remediation efforts should be documented, including the actions taken and the timelines for resolution. After remediation, it may be necessary to reassess the affected areas to ensure they now comply with PCI DSS requirements.
By methodically following these steps, entities can ensure they meet PCI DSS requirements, thereby protecting cardholder data and reducing the risk of data breaches.
The following table outlines security controls and processes required to meet the PCI DSS requirements.
Build and maintain a secure network and systems
| Requirement | Description | Security controls and processes | How ManageEngine can help | |
|---|---|---|---|---|
| 1. | Install and maintain a firewall configuration to protect cardholder data | Firewalls serve as gatekeepers, regulating the flow of digital traffic entering and exiting an organization's network, as well as managing access to restricted zones within its internal infrastructure. The capabilities of a firewall can be integrated into various system components. |
Establishing configuration standards
|
ManageEngine's unified SIEM solution, Log360, can monitor firewall configuration changes and log firewall activities to check for system issues. |
Network segmentation and firewall rule configuration
|
Log360 can help you regularly review the firewall rules, monitor and get alerts upon changes to the rules, and provides you with insights and analytics to verify if the firewall rule changes are authorized. | |||
| 2. | Do not use vendor-supplied defaults for system passwords and other security parameters | Mandates changing default configurations to secure systems from unauthorized access. |
|
Log360 audits changes to system configurations and permissions, alerting administrators to unauthorized modifications to security settings. |
Protect cardholder data
| Requirement | Description | Security controls and processes | How ManageEngine can help | |
|---|---|---|---|---|
| 3. | Protect stored cardholder data | Storing cardholder data increases risk.Therefore, it must be done securely using stringent controls. |
|
Log360 helps ensure data storage is compliant by providing reports for data handling and storage mechanisms and alerting on unauthorized access attempts. |
| 4. | Encrypt transmission of cardholder data across open, public networks | Data is particularly vulnerable during transmission over unsecured networks, such as the internet. |
|
Maintain a vulnerability management program
| Requirement | Description | Security controls and processes | How ManageEngine can help | |
|---|---|---|---|---|
| 5. | Use and regularly update antivirus software or programs | Malware can infect numerous systems and access or corrupt sensitive data. |
|
Log360 integrates with antivirus systems to centralize logging information, providing alerts and detailed reports on detected threats and update statuses. |
| 6. | Develop and maintain secure systems and applications | Vulnerabilities in systems and applications can be exploited to gain unauthorized access to cardholder data. |
|
Log360 can monitor vulnerability scanners and patch management software to check logs from security systems and applications for signs of misconfiguration or unpatched vulnerabilities. It can also track patch installations and alert on systems that are missing critical security updates. |
Implement strong access control measures
| Requirement | Description | Security controls and processes | How ManageEngine can help | |
|---|---|---|---|---|
| 7. | Restrict access to cardholder data by business need to know | Only those with a legitimate business need should have access to sensitive data. |
|
Log360 provides real-time monitoring and auditing of access controls and user activities, ensuring that only authorized users can access sensitive data. |
| 8. | Assign a unique ID to each person with computer access | Tracking and monitoring individual user activities require a unique identifier for each user. |
|
Log360 ensures that all user activities are logged and traceable back to individual user IDs. AD360 supports MFA implementation and monitors compliance with user authentication policies. |
| 9. | Restrict physical access to cardholder data | Physical security controls protect against unauthorized personnel access. |
|
Regularly monitor and test networks
| Requirement | Description | Security controls and processes | How ManageEngine can help | |
|---|---|---|---|---|
| 10. | Track and monitor all access to network resources and cardholder data | Continuous monitoring of all network and data access activities is essential for security. |
|
Log360 offers extensive logging capabilities, real-time alerts, and automated log analysis tools to ensure that all access is monitored and recorded, facilitating quick detection of security incidents. |
| 11. | Regularly test security systems and processes | Regular testing helps identify vulnerabilities in security systems and processes. | Regular testing, including vulnerability scans and penetration testing, should be conducted to assess the robustness of security measures. Security systems should be tested to ensure they are functioning as intended and are effective against threats. | Log360 facilitates continuous security testing by providing tools for scheduling regular scans and by integrating with external testing solutions to enhance security oversight. |
Maintain an information security policy
| Requirement | Description | Security controls and processes | How ManageEngine can help | |
|---|---|---|---|---|
| 12. | Maintain a policy that addresses information security for all personnel | A strong security policy is foundational to maintaining secure operations. |
|
Use cases
PCI DSS checklist
- Use strong passwords : User passwords need to be difficult to exploit, which is achieved by using special characters, avoiding character patterns, creating longer passwords, and using all allowed character types. Passwords are also required to be regularly changed to maintain their strength.
- Encrypt sensitive information: To protect sensitive data, such as credit card information, it's important to encrypt it both while it's stored and while it's transmitted.
- Use firewalls: Firewalls are a crucial component of network security . They prevent unauthorized access to a network by controlling incoming and outgoing network traffic.
- Get secure payment gateways: Secure payment gateways ensure the protection of sensitive payment information during transactions by using encryption and other security measures.
- Use antivirus software: Antivirus software helps protect the system from malware attacks , which can cause serious harm to the network.
- Limit remote and physical access: Limiting remote and physical access to network resources is a key step in protecting sensitive data from unauthorized access.
- Have a security assessment policy: A security assessment policy outlines the steps taken to protect sensitive information and ensures that all staff members are aware of the importance of data protection.
- Restrict traffic to payment systems: To ensure the security of payment systems, it's important to restrict traffic to only what is necessary and block any unwanted traffic.
Non-compliance implication
The PCI DSS provides guidelines for securing sensitive information, but compliance with these guidelines is not a legal requirement. The regulations are managed and upheld internally by the industry through vendor agreements. Adherence to the 12 requirements set forth by PCI DSS will save organizations from a range of consequences, including fines from $5,000 to $100,000 and the possibility of legal action, insurance claims, cancelled accounts, and the withdrawal of credit processing services if a security incident occurs.
The damage from compromised data can be widespread and long-lasting, impacting consumers, merchants, and financial institutions alike and potentially causing irreparable harm to a company's reputation and future success.
The aftermath of a breach might also involve the following outcomes:
- In-person evaluation by a QSA.
- Detailed forensic investigation.
- Reissuing credit and debit cards.
- Free credit monitoring for impacted customers.
- Technology repairs and upgrades.
- Notifying the public about the breach.
ManageEngine solutions that can help with compliance
Log360
Log360 is a unified SIEM solution with integrated DLP and CASB capabilities that detects, prioritizes, investigates and responds to security threats. Vigil IQ, the solution's TDIR module, combines threat intelligence, an analytical Incident Workbench, ML-based anomaly detection and rule-based attack detection techniques to detect sophisticated attacks, and it offers an incident management console for effectively remediating detected threats. Log360 provides holistic security visibility across on-premises, cloud and hybrid networks with its intuitive and advanced security analytics and monitoring capabilities.
Try us out for 30 daysAD360
ManageEngine AD360 is a unified identity and access management (IAM) solution that helps manage identities, secure access, and ensure compliance. It comes with powerful capabilities like automated identity life cycle management, access certification, risk assessment, secure single sign-on, adaptive MFA, approval-based workflows, UBA-driven identity threat protection and historical audit reports of AD, Exchange Server and Microsoft 365. AD360's intuitive interface and powerful capabilities make it the ideal solution for your IAM needs, including fostering a Zero Trust environment.
Try us out for 30 daysDisclaimer: This guide has been created with reference to official documents on PCI DSS published by relevant government authorities. It is intended to provide a clear and comprehensive explanation of PCI DSS Requirement 2. The contents are for informational purposes only and should not be considered as legal advice. Organizations should consult with a qualified PCI DSS consultant to ensure compliance.
