All merchants handling credit card data must comply with the Payment Card Industry Data Security Standards (PCI DSS), encompassing those who collect, store, process, or transmit such information. The PCI Security Standards Council (SSC) outlines mandatory compliance requirements tailored to e-commerce merchants, including detailed guidelines, considerations, and reporting procedures. Given the extensive reach of PCI DSS requirements and their diverse applications, many merchants operating e-commerce websites seek clear guidance on achieving PCI compliance.
A Comprehensive Guide to PCI Compliance for E-Commerce Websites
Achieving PCI compliance for e-commerce merchants involves implementing and annually reporting on precise cybersecurity measures and operational procedures designed to safeguard cardholder data (CHD). However, the compliance requirements can vary widely depending on how merchants interact with CHD. Navigating these differences poses a significant challenge for all merchants. To assist with this, this guide provides:
- The 12 PCI DSS Requirements
- The different payment processing methods and how they affect merchant responsibilities
- eCommerce PCI Compliance reporting
- eCommerce PCI Compliance best practices
For more thorough advisory, contact a PCI approved cybersecurity and compliance vendor, such as RSI Security.
PCI DSS Requirements
To grasp how e-commerce merchants can maintain PCI DSS compliance, it’s essential to comprehend the 12 Requirements (and their respective sub-requirements) applicable to all merchants. Each requirement outlines distinct cybersecurity measures or organizational processes that merchants must adhere to in order to safeguard cardholder data (CHD).
It’s crucial for merchants to understand the entire PCI DSS and uphold full compliance, even if they outsource payment processing to a third party. Regardless of the division of compliance responsibilities among involved parties, e-commerce merchants are accountable for detailing all efforts in their reporting documentation.
PCI DSS: The 12 Requirements and Their Sub-Requirements
The PCI DSS consists of six goals, each comprising 12 Requirements with multiple sub-requirements. Each Requirement may encompass up to 11 collated sub-requirements.
The PCI DSS’s six goals and 12 Requirements are as follows:
- Goal 1 – Build and maintain a secure network and systems.
- Requirement 1 – Install and maintain firewall configurations to protect CHD.
- Requirement 2 – Don’t use vendor-supplied defaults for system passwords or other security parameters.
- Goal 2 – Protect CHD.
- Requirement 3 – Protect stored CHD.
- Requirement 4 – Encrypt transmission of CHD across open, public networks.
- Goal 3 – Maintain a vulnerability management program.
- Requirement 5 – Protect all systems against malware and regularly update antivirus software or programs.
- Requirement 6 – Develop and maintain secure systems and applications.
- Goal 4 – Implement strong access control measures.
- Requirement 7 – Restrict access to CHD by business need to know (i.e., only roles that require access should have it granted).
- Requirement 8 – Identify and authenticate access to system components.
- Requirement 9 – Restrict physical access to CHD.
- Goal 5 – Regularly monitor and test networks.
- Requirement 10 – Track and monitor all access to network resources and CHD.
- Requirement 11 – Regularly test security systems and processes.
- Goal 6 – Maintain an information security policy.
- Requirement 12 – Maintain a policy for all personnel that addresses information security.
Payment Processing Options
E-commerce merchants have the option to develop their own payment platform, though many opt to outsource processing to a third-party vendor. The method of processing chosen by the merchant dictates the content of their compliance reporting documentation. The PCI SSC’s compliance guidance categorizes these third-party vendors as payment services providers (PSPs).
Outsourcing offers significant benefits such as reduced ongoing management and simplified PCI DSS compliance efforts. Organizations can opt to outsource either some (i.e. shared management) or all (i.e. wholly outsourced) of their payment processing functionalities.
Nevertheless, even when e-commerce merchants outsource their payment processing functions, thereby delegating some compliance efforts, their responsibilities do not diminish entirely. Organizations are still accountable for identifying which PCI DSS requirements and sub-requirements are managed by third parties, and they must provide comprehensive explanations of any responsibilities retained internally.
Merchant-Managed Processing for E-Commerce
The PCI SSC identifies two payment processing categories that describe self-managed platforms for e-commerce merchants:
- Proprietary or custom-developed (online) shopping carts and payment
- Third-party implementation fully managed by the merchant
Merchants who maintain management and maintenance responsibilities for their payment processing platforms bear full responsibility for PCI DSS compliance related to them. While the platform itself may address certain aspects of PCI DSS adherence, organizations overseeing their management must ensure that all configurations and activities performed with the solution remain compliant.
Shared Management Payment Processing
Organizations that outsource payment processing functionality to PSPs are generally provided with the following options:
- URL Redirects – This processing method redirects customers to a PSP-hosted webpage to enter their credit card information when paying for purchases. CHD is not collected, stored, processed, or transmitted by the e-commerce merchant with URL redirects. Therefore, compliance responsibility and impact are lower, and fewer systems will require security controls.
- iFrame – This processing method mirrors that of URL redirects, although the PSP-provided functionality is embedded on the e-commerce merchant’s webpage within an “iFrame.” CHD is not collected, stored, processed, or transmitted, but should cyber-attackers compromise the merchant’s site, they can embed false content within the iFrame, so merchants must adopt strict website security.
- Direct Post Method (DPM) – This processing method sends the entered credit card information directly to a PSP from a merchant-managed webpage. While no CHD is stored, processed, or transmitted via merchant systems, the payment form that collects information must follow PCI DSS security controls. Larger e-commerce merchants generally use DPM to retain more control over their payment processing presentation.
- JavaScript Form – This processing method mirrors DPM, with the same PCI compliance efforts required for CHD collection. Also similar to DPM, larger e-commerce merchants generally use JavaScript Forms to retain more control over their payment processing presentation.
- Application Programming Interface (API) – This processing method operates via system-to-system transmission. With APIs, e-commerce merchants control transaction progress, hosting and supplying the CHD collection form and processing submitted information before it’s transmitted to the PSP. APIs carry the most significant risk and compliance burden, as the merchant collects, receives, and transmits CHD.
- Depending on the API utilized, e-commerce merchants may also store and process CHD as part of payment processing. If so, this activity is subject to PCI DSS compliance.
Wholly Outsourced E-commerce Solutions
This method of processing reduces the PCI DSS compliance burden for e-commerce merchants, as they integrate all shopping functionalities into a website or platform managed by a PSP (Payment Service Provider), including product search, cart functionality, checkout, and account management. Since the PSP handles all cybersecurity aspects of the platform, they primarily bear the responsibility for PCI DSS compliance. Even if e-commerce merchants fully outsource the shopping functionality provided to customers, the PCI DSS still mandates them to establish policies and procedures for secure handling of cardholder data (CHD).
PSP Platform Validation—The PA-DSS
Though PSPs will assume a percentage of PCI compliance efforts (depending on the functionality utilized), e-commerce merchants must still validate platforms to ensure their use will adhere to the 12 Requirements. Regardless of what functionality is outsourced to a PSP, e-commerce merchants remain responsible for their PCI DSS compliance—including whether or not an implemented PSP platform, application, or service adheres to PCI regulations.
E-commerce merchants should evaluate PSPs’ and their platforms’ compliance before implementation to ensure compliance. Processing solutions and services are subject to the Payment Application Data Security Standards (PA-DSS). The PCI SSC maintains a list of approved applications that have received PA-DSS validation. E-commerce merchants should note:
- Processing platforms developed in-house only fall under a merchant’s existing efforts to comply with the PCI DSS Requirements, not the PA-DSS.
- Implementation of a PA-DSS-compliant payment processing application doesn’t automatically guarantee PCI DSS compliance.
- All applications that collect, store, process, or transmit CHD are subject to the PCI DSS regardless of PA-DSS validation.
- Suppose an e-commerce merchant customizes a PSP processing application. In that case, their PCI DSS assessment will be more thorough to ensure that the platform remains representative of the PSP’s original version that received PA-DSS validation.
In addition to PCI DSS compliance and PA-DSS verification, organizations must ensure that their payment processing platforms adhere to all other compliance frameworks that apply to their industry or business activity. For example, the EU’s GDPR regards credit card data as personally identifiable information (PII). Therefore, e-commerce merchants that interact with EU citizens must ensure that CHD security also follows GDPR specifications.
PA-DSS Requirements
The PA-DSS applies to all PSPs who sell payment processing services or applications to merchants. The PA-DSS’s 14 Requirements are:
- Requirement 1 – Do not retain credit cards’ full track data, verification codes or values (e.g., CAV2, CID, CVC2, CVV2), or PIN block data.
- Requirement 2 – Protect cardholder data stored.
- Requirement 3 – Provide secure authentication.
- Requirement 4 – Log payment application activity.
- Requirement 5 – Develop secure payment applications.
- Requirement 6 – Protect wireless transmissions.
- Requirement 7 – Test payment applications to address vulnerabilities and maintain payment application updates.
- Requirement 8 – Facilitate secure network implementation.
- Requirement 9 – Don’t store CHD on internet-connected servers.
- Requirement 10 – Facilitate secure remote access to payment applications.
- Requirement 11 – Encrypt sensitive traffic over public networks.
- Requirement 12 – Encrypt all non-console administrative access.
- Requirement 13 – Maintain a PA-DSS implementation guide for a PSP’s customers, resellers, and integrators.
- Requirement 14 – Assign PA-DSS responsibilities for personnel, and maintain training programs for personnel, customers, resellers, and integrators.
PCI DSS Reporting for E-Commerce Merchants
In general, eCommerce PCI compliance reporting resembles that of other merchants, involving quarterly vulnerability scans and documentation submission. However, the specific documentation requirements vary based on annual transaction volume and the method of payment processing employed.
The PCI SSC classifies merchants into four levels based on their annual payments processed across all payment channels. Most merchants, except those with the highest transaction volumes, are required to submit a Self-Assessment Questionnaire (SAQ). E-commerce merchants using various outsourcing methods for payment processing must ascertain the appropriate SAQ version that applies to their operations.
The PCI DSS Levels
Per Visa, an SSC founding member, the PCI’s four Levels are as follows:
- Level 1 – Merchants that annually process six million or more transactions across all payment channels; required reporting documentation includes a Report on Compliance (ROC) and an Attestation of Compliance (AOC)
- Level 2 – Merchants that annually process between one to six million transactions across all channels; required reporting documentation includes a SAQ and an AOC
- Level 3 – Merchants that annually process between twenty thousand to one million e-commerce transactions; required reporting documentation includes a SAQ and an AOC
- Level 4 – Merchants that annually process fewer than twenty thousand e-commerce transactions and all other merchants that process under one million transactions; required reporting documentation only includes a SAQ
Note that Level categorization for eCommerce PCI Compliance is distinct from all other payment processing methods at Levels 3 and 4.
QSAs and ASVs
The PCI SSC certifies third parties to conduct quarterly scans and submit documentation, similar to the approved list of payment processing applications validated under PA-DSS. These third parties are known as Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs). QSAs and ASVs, such as RSI Security, must undergo rigorous recertification yearly to maintain their SSC-approved status.
Merchants completing their reporting documentation must partner with a QSA for ROCs and AOCs. While a merchant can fill out their SAQ internally, QSA guidance can help streamline the process and minimize effort substantially. An ASV must conduct the requisite quarterly vulnerability scans. However, note that for PCI DSS compliance, the “quarters” are not defined as the standard “Q1-4” but, instead, as 90 days since the previous vulnerability scan.
Self-Assessment Questionnaires (SAQs) for E-Commerce Merchants
The SSC provides numerous SAQ versions covering PCI compliance for eCommerce sites, with each pertaining to different processing methods. Depending on what and how much processing functionality a merchant outsources to a PSP, e-commerce merchants must choose from the following SAQ versions:
- SAQ A – Applicable to wholly outsourced, URL redirect, or iFrame payment processing methods
- SAQ A-EP – Applicable to DPM or JavaScript Post payment processing methods
- SAQ D – Applicable to API or other payment processing methods.
Completing a SAQ mostly consists of providing yes or no answers, with any additional information contained in compensating control worksheets (CCW).
E-Commerce Merchant Best Practices for PCI DSS Compliance
The PCI SSC incorporates the following elements in its best practice guidelines concerning PCI compliance for e-commerce websites:
- Know where CHD is stored
- Dispose of unnecessary CHD
- Evaluate the risks each e-commerce technology poses to merchants
- Govern PSP access to merchant systems strictly
- Conduct quarterly ASV scans or ensure a PSP partner does
- Conduct penetration testing for all e-commerce environments
- Implement regular security training for staff
Expert eCommerce PCI Compliance
PCI compliance demands rigorous efforts annually from all merchants involved in collecting, storing, processing, or transmitting credit card data. For e-commerce merchants, navigating cybersecurity implementations and reporting is additionally complex due to the diversity of processing platforms and the associated documentation requirements.
This guide aims to streamline e-commerce merchants’ comprehension of their PCI compliance obligations. Nonetheless, maintaining PCI compliance demands continuous attention to cybersecurity and vigilance over cardholder data (CHD). Achieving a comprehensive grasp of implementation and reporting nuances requires expertise in the DSS framework. RSI is an SSC-approved QSA and ASV with over a decade of experience related to PCI DSS compliance.
Contact RSI Security today to learn how you can streamline and simplify your eCommerce PCI compliance even further!
Discover how RSI Security can help your organization. Request a complimentary consultation:
