PCI DSS Compliance and Cybersecurity
PCI DSS standard was developed by the world leading credit card brands to prevent payment card fraud
by imposing mandatory cybersecurity and data protection requirements on companies of all sizes
around the globe that process, store or otherwise handle credit, debit or cash cards.
What is PCI DSS?
The first version of the Payment Card Industry Data Security Standard (PCI DSS) was jointly developed in 2004 by Visa, MasterCard, American Express, JCB International and Discover to combat growing credit card theft, misuse and fraud.
ImmuniWeb can help you comply with PCI DSS cybersecurity requirements. Learn more
The standard is administered by the PCI Security Standard Council (SSC) and applies to all entities, including merchants, processors, acquirers, issuers and service providers that store or process payment card data irrespective of the number of processed transactions. The standard is aimed to accomplish 6 foundational cybersecurity and data protection goals by the covered organizations:
- 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
Differently from the EU GDPR or state laws such as SHIELD Act or CCPA, which are enacted and enforced by governmental entities in their jurisdictions, PCI DSS and the underlying data protection duties are imposed by the virtue of contract law. If a company wishes to accept payments by credit or debit cards, it will be required to bind itself to strict PCI DSS requirements by a contractual agreement with a merchant bank or processing center and credit card brands such as Visa.
Interestingly, some states in the US, including Nevada and Washington, incorporated compliance with PCI DSS into their state legislation, thereby making a violation of PCI DSS also an infringement of their state law.
What are the penalties for PCI DSS violations?
Violations of PCI DSS may be costly and go up to 100,000 USD monthly fine while the penalized non-conformity remains unfixed. Furthermore, violation may even lead to termination of card processing contract and eventually terminate merchant’s ability to accept payments by cards, causing fatal losses to e-commerce and digital businesses.
Frequently, infringement of PCI DSS may be a telling evidence of negligence in case of a data breach, and lead to costly individual and class action lawsuits by aggrieved individuals whose cards were compromised by hackers. Frequently, merchant banks also file lawsuits against breached merchants claiming their damages such as reissuance of the stolen credit cards.
Differently from Singaporean PDPA or Brazilian LGPD personal data protection laws, there are no criminal penalties or sanctions purely for PCI DSS violations. One should, however, attentively examine the applicable national legislation: data breaches may trigger regulatory scrutiny from the FTC or state Attorney Generals in the US, and from the national Data Protection Authorities (DPA) in Europe and other countries, and eventually cause severe monetary penalties, injunction orders and even criminal prosecution.
What is PCI PA-DSS and PCI PTS compliance?
PCI PA-DSS (Payment Application Data Security Standard) applies to software vendors that develop and commercialize card payment applications for third parties. PCI SSC maintains a list of PA-DSS tested and validated payment applications that can be used in conformity with the PCI DSS standard. PA-DSS contains 14 requirements that include, among other things, prohibition to store card verification code (CAV2, CID, CVC2 or CVV2) and PIN block data, protection of stored cardholder data and its wireless transmission, implementation of strong authentication, and robust security testing of the applications to be performed in a continuous manner, including regular penetration testing. PCI SSC maintains a list of PA DSS approved payment applications on its website.
PCI PTS (PIN Transaction Security) covers security of PIN Transaction Security hardware devices that process card payments, such as portable devices or fixed terminals for payment with cards. Merchants that accept payments by credit cards, via a physical contact with the card, must use only the approved PCI PTS devices that were successfully tested and certified by the PCI SSC for PTS compliance. The PTS standard encompasses PIN security requirements, Point of Interaction (POI) modular security requirements and Hardware Security Module (HSM) security requirements. PCI SSC maintains a list of PCI PTS approved payment devices on its website.
Who is covered by PCI DSS compliance?
According to the PCI SSC guidelines for merchants, PCI DSS applies to all entities that store, process, and/or transmit cardholder data. Whereas the “cardholder data” is broadly defined as any information printed, processed, transmitted or stored in any form on a payment card. The following equipment and data, related to payment card information, must be protected in conformity with the PCI DSS requirements:
- Systems performing encryption and/or decryption of cardholder data, and systems performing key management functions, and
- Encrypted cardholder data that is not isolated from the encryption and decryption and key management processes, and
- Encrypted cardholder data that is present on a system or media that also contains the decryption key, and
- Encrypted cardholder data that is present in the same environment as the decryption key, and
- Encrypted cardholder data that is accessible to an entity that also has access to the decryption key.
Thus, all entities engaged in receiving card payments, storing or processing cardholder data, regardless of their geographical location and size of business, must abide by the PCI DSS data security requirements.
There are, however, significant variations in the requisite validation of PCI DSS compliance for merchants of different sizes that are grouped into four merchant levels described below.
What are the merchant levels used in PCI DSS?
There are four consecutive merchant levels that are defined by credit card companies to classify merchants by the annual number of transactions and adopt adequate reporting and validation requirements proportional to the risks. There is a general consistency of merchant levels among different credit card brands, though minor differences may exist. For instance, Visa has the following merchant levels classification:
- Level 1 Merchant: processing over 6 million card transactions annually.
- Level 2 Merchant: processing between 1 and 6 million card transactions annually.
- Level 3 Merchant: processing between 20,000 and 1 million card transactions annually.
- Level 4 Merchant: processing below 20,000 card transactions annually.
Regardless of their level, merchants must comply with all PCI DSS cybersecurity and data protection requirements. The levels just impose different approaches to compliance validation whereas the highest bar is unsurprisingly fixed for the Level 1 merchants, while Level 4 merchants usually enjoy some flexibility and lenity.
Importantly, a merchant may be forcingly re-classified as a Level 1 merchant for one or several years, regardless of the number of processed transactions, if the merchant suffers a data breach caused by non-compliance with PCI DSS.
What is a PCI DSS audit?
The Level 1 merchants (see above) are required to submit annual Report on Compliance (ROC) after performing an onsite audit by a Qualified Security Assessor (QSA), network vulnerability scan reports performed quarterly by an Approved Scanning Vendor (ASV), and Attestation of Compliance (AOC) to their acquiring financial institutions or payment card brands.
The Level 2 and 3 merchants are exempt from submitting ROC but must provide annual Self-Assessment Questionnaire and signed Attestation of Compliance. SAQ may be filled out internally or by an external provider and answer different questions about compliance depending on the SAQ type. There are different types of SAQs adopted for diversified physical and technological environments of card processing. For example, SAQ A type is designed for the so-called Card-Not-Present merchants, who entirely outsource card processing to an external entity, while SAQ B-IP type is intended for merchants with standalone, PTS-approved, payment terminals with IP connection to their payment processor. Full list of SAQs can be found on the PCI SSC website.
Identically to the Level 4 merchants, the Level 2 and 3 merchants are required to submit quarterly network vulnerability scanning reports by an ASV vendor. These reports set a high bar for network security whereas one single vulnerability, except the low-risk ones as per CVSS score, will cause a non-compliance with PCI DSS and require undelayed remediation from the merchant to avoid penalties or even a temporary suspension of its card processing activities.
The Level 4 merchants commonly enjoy some degree of flexibility and lenity from merchant banks and card brands. They are still required to submit a duly filled-in SAQ annually and perform quarterly ASV scanning. Sometimes, however, merchant banks may absolve small merchants from network vulnerability scanning requirement or make it voluntary. Level 4 merchants must nevertheless implement all data protection requirements imposed by PCI DSS.
What is a PCI DSS certification and how much does it cost?
Technically speaking, there is no formal “PCI DSS certification” process by a central certification body or authority. The annual process of self-assessment with SAQ submission (for the Levels 2-4 merchants) and external QSA-driven assessment with ROC submission (for the Level 1 merchants) complemented with Attestation of Compliance and quarterly ASV scan reports is oftentimes referred to as PCI certification.
Some cybersecurity vendors readily provide privately issued certificates of PCI DSS compliance, following an onsite audit of the merchant. Usually, such certification may have value only if the vendor is QSA-certified by the PCI SSC, but there is no such legal requirement except for ROC reports that are accepted only from QSA vendors. The cost of PCI DSS audit greatly varies by sector, country and vendor. Small merchants may spend from 10 to 12 thousand USD per year, while international conglomerates, with complex Cardholder Data Environment (CDE) - discussed below - and branch offices around the globe, should be prepared to spend a seven-digit amount on annual auditing and compliance.
How to comply with PCI DSS?
PCI DSS compliance is not that complicated and burdensome as may appear at the first glance. According to the latest SSC’s Quick Reference Guide, the entire compliance process is composed of 6 foundational steps:
- Scoping: this is the essential and probably the most crucial step during which merchant should define its Cardholder Data Environment that will be audited to comply with PCI DSS.
- Assessing: this is the auditing step during which merchant, or external QSA vendor, performs regular assessment for compliance with PCI DSS requirements of the CDE.
- Reporting: during this post-audit stage, merchant or external auditor fills-in SAQ or ROC and the underlying technical documentation validating conformity with PCI DSS.
- Attesting: a fairly simple phase that requires completing the Attestation of Compliance (AOC) confirming merchant’s conformity with the PCI DSS requirements.
- Submitting: an easy phase during which merchant is required to submit SAQ or ROC, AOC and other requested documentation such as ASV scan reports to the acquirer (for merchants) or to payment brands (for service providers).
- Remediation: an optional phase requisite to address any identified deficiencies or non-conformities with PCI DSS after review of the submitted documentation.
It is important to highlight here that PCI DSS compliance is not an ad hoc exercise but rather an ongoing process. It is aimed to continuously improve cybersecurity resilience and swiftly adjust security controls to shield organization from the rapidly evolving cyber threat landscape.
How to determine PCI DSS Cardholder Data Environment?
The Cardholder Data Environment (CDE) is probably the most determinative and impactful part of PCI DSS compliance process. It may either greatly overcomplicate it or, contrariwise, significantly alleviate the entire process and save a lot of money to merchants.
The PCI standard defines CDE in a broad manner as people, processes and technologies that store, process or transmit cardholder data or sensitive authentication data related thereto. The PCI DSS data protection and cybersecurity requirements apply to all system components within the CDE scope. On their side, the system components include network devices, servers, computing devices and applications – virtually all electronic devices and computer systems. The CDE must be assessed, scoped and documented at least annually or after any significant change in the IT environment.
The concept of CDE scoping is essential for PCI DSS compliance. An overbroad CDE may trigger unnecessary costs and considerably protract the auditing process. On the other side, missed or forgotten systems and applications, that process cardholder data, will make CDE incomplete and will likely lead to a major data breach or a non-compliance with PCI DSS in the best-case scenario.
Under the PCI DSS standard, covered entities are not obliged to secure their entire IT infrastructure and networks – this is not a PCI SSC business at the end of the day – but only the infrastructural segments where cardholder data is present or processed. Proper network segmentation and segregation, usage of VLANs to isolate CDE from all other corporate networks and systems can minimize costs of PCI DSS compliance and auditing.
While determining your CDE scope, it is important to bear in mind modern technologies such as cloud backups. If an engineer connects to a CDE environment remotely to access cardholder data while his or her machine is being backuped to the cloud at this moment, the cloud and all interconnected networks will likely fall into the CDE scope and create a compliance disaster.
What is PCI DSS compliance checklist?
The PCI DSS standard contains 12 interrelated requirements that provide a comprehensive framework for regular risk assessment, asset inventory, implementation of risk-based security controls to adequately mitigate identified or reasonably foreseeable cyber threats, and ongoing security testing accompanied with timely remediation.
- Install and maintain a firewall configuration to protect cardholder data.
- Do not use vendor-supplied defaults for system passwords and other security parameters.
- Protect stored cardholder data.
- Encrypt transmission of cardholder data across open, public networks.
- Protect all systems against malware and regularly update anti-virus software or programs.
- Develop and maintain secure systems and applications.
- Restrict access to cardholder data by business need to know.
- Identify and authenticate access to system components.
- Restrict physical access to cardholder data.
- Track and monitor all access to network resources and cardholder data.
- Regularly test security systems and processes.
- Maintain a policy that addresses information security for all personnel.
Each of the foregoing requirements is composed of numerous sub-requirements, elaborated on 139 pages of the PCI DSS standard (version 3.2.1).
Regardless of its merchant’s Level, the merchant must comply with all of the 12 requirements. Common sense scoping exceptions apply, for instance, if there are no wireless networks in the CDE scope, then wireless security requirements are obviously inapplicable.
What are the application security requirements of PCI DSS?
PCI DSS gives a significant importance to the ongoing application security aimed to ensure resilience to multiplying web attacks of growing complexity and amplitude.
The most important application security requirements come from the PCI DSS Requirements 6 and 11, applicable to all on-premises and cloud systems within the CDE scope:
The Requirement 6.1 directs to “establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.”
The Requirement 6.6 says “for public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes. Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.”
Finally, the Requirement 11.3 instructs to “implement a methodology for penetration testing that includes the following: Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115) Includes coverage for the entire CDE perimeter and critical systems Includes testing from both inside and outside the network Includes testing to validate any segmentation and scope-reduction controls Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5.”
Additionally, the PCI Software Security Framework provides supplementary guidance including regular security testing of software including its external and open-sourced components, implementation of a Secure Software Development Lifecycle (S-SDLC) to ensure security-by-design since the very first step of software creation, and mitigation of the detected security flaws and misconfigurations in a risk-based manner.
In a nutshell, all web applications from the CDE scope must either be protected with a WAF or be scanned for the OWASP Top 10 vulnerabilities in a continuous manner. The automated efforts are to be enhanced with a penetration testing that must be performed at least annually or after any major update.
ImmuniWeb can help you comply with PCI DSS cybersecurity requirements. Learn more
What are the third-party risk management requirements of PCI DSS?
The PCI DSS standard makes it clear that covered merchants should and will likely be held accountable for any omissions, carelessness or negligence of their vendors and suppliers. The standard says that the covered organizations, that outsource their CDE or payment operations management to third parties, are responsible for ensuring that the cardholder data is sufficiently protected by the third party per the applicable PCI DSS requirements.
Moreover, when outsourcing activities, that require PCI DSS compliance, such as processing or storage of cardholder data, the merchant is eventually responsible to verify that the service provider is compliant with the PCI DSS data protection requirements. Finally, an up2date inventory of all third parties, that have access to the CDE environment or cardholder data, must be maintained by the covered entity. Such documentation may be requested as a part of PCI DSS audit.
PCI SSC Guidance on Responding to a Cardholder Data Breach suggests implementing contractual clauses that will require trusted third parties to immediately notify the merchant about any security incidents or data breaches when cardholder data is implicated. Likewise, contracts may allow merchants to perform regular audits, request relevant security documentation or otherwise ascertain third-party compliance with the standard.
Finally, PCI Software Security Framework mandates due diligence on third parties to ensure their factual capacity to ensure the requisite data protection under the PCI DSS requirements. The framework also proposes contracts to define appropriate security measures to be respected by vendors and suppliers who, among other things, should be able to demonstrate their compliance upon request from the merchant.
When does PCI DSS 4.0 come into the effect?
Due to the pandemic, the new version of PCI DSS 4.0 is expected to be released in Q4 2021 and replace the existing PCI DSS 3.2.1 standard.
Among the probable changes one may observe a growing focus on continuous security and ongoing compliance, as well as more flexibility to implement risk-based security controls to adequately mitigate emerging cyber threats.
Alongside the new standard, templates for ROC, SAQ and AOC will also be updated.