A business’s cybersecurity infrastructure must meet its regulatory compliance requirements. One compliance framework that applies to businesses in nearly every industry is the Payment Card Industry (PCI) Data Security Standard (DSS), developed and enforced by the PCI Security Standards Council (SSC). PCI Level 2 compliance is mandatory for businesses that process, store, or transmit credit card data and handle between one and six million transactions per year.
How to Meet PCI DSS Level 2 Requirements
PCI DSS compliance can be challenging for companies at every level. There are myriad controls to implement, plus a variety of assessment and reporting protocols to sort through.
For PCI level 2 certification, you’ll want to familiarize yourself with:
- The different levels of PCI DSS compliance and reporting on compliance
- The different documentation required at each respective PCI level
- The PCI DSS requirements that all companies have to implement
- Other compliance considerations, such as additional PCI frameworks
Understanding the Levels of PCI Compliance
Nearly all companies that process payments via credit or debit card must comply with the PCI DSS. Compliance also applies to most companies that transmit, store, or otherwise come into contact with card and cardholder data, irrespective of their payment structure. However, not all of these companies need to comply and report on their compliance in exactly the same ways.
Companies with the lowest volume of transactions generally have lower bars to clear: namely, they just need to fill out a Self-Assessment Questionnaire (SAQ). But companies with more transactions need to have their SAQ and compliance verified by a Qualified Security Assessor (QSA)—such as RSI Security—that files an Attestation of Compliance (AOC), a Report on Compliance (ROC), or both.
Achieving Level 2 PCI compliance has to do with the specific assessing and reporting protocols used to verify your implementation. All companies at all Levels must implement all controls or, where appropriate, compensate controls that meet or surpass PCI compliance requirements.
Request a Free Consultation
Leveled Requirements for Applicable Companies
The PCI compliance reporting levels depend on the volume and type of transactions a company processes throughout a calendar year. Per Visa’s PCI DSS compliance guide, they are:
- PCI DSS Level 1 – Merchants who process over six million transactions per year across all of their channels must file a QSA-verified ROC and an SAQ and AOC every year.
- PCI DSS Level 2 – Merchants who process between one and six million transactions per year across all of their commercial channels must file an SAQ and AOC every year.
- PCI DSS Level 3 – Merchants who process between 20 thousand and one million e-commerce transactions (exclusively) per year must file an SAQ and AOC every year.
- PCI DSS Level 4 – Merchants who process fewer than 20 thousand e-commerce transactions or up to 1 million transactions total must file just the SAQ every year.
While PCI DSS Level 2 is identical to Level 3 in terms of reporting, it encompasses a wider range of companies. It also signifies the most transactions a company can process before being required to submit a QSA-verified ROC.
Documenting PCI Compliance at All Levels
At all but the lowest PCI Level, companies who need to comply must contract the services of a QSA, or PCI-verified managed security services provider, to assess their efforts. The AOC that Level 2 and 3 companies must file alongside their SAQ verifies that the self-assessed answers are factual. A QSA may elect to assess the company’s security practices, but this is not always a requirement.
An ROC, required only for the highest compliance level, is a much more thorough analysis of the target company’s security features. It involves an on-site visit and assessment by the QSA, who will test controls themselves rather than relying on self-reported findings. If you’re on the verge of Level 1’s transaction volume, you’ll want to prepare for an ROC’s more rigorous evaluation.
At the opposite end of the spectrum, the SAQ is a survey with simple yes or no questions about all PCI DSS controls.
Different Questionnaires for Different Businesses
The SAQ applies to companies at all PCI levels. However, different companies fill out different variants of the form, depending on the business’s activity. Per the PCI’s guidance on SAQs, these are:
- SAQ A – Applies to merchants that outsource card data functions to service providers and use cardless payment technologies (e-commerce, etc.), not face-to-face channels.
- SAQ A-EP – Applies exclusively to e-commerce merchants that outsource card data functions to service providers and that use a website that has no impact on said data.
- SAQ B – Applies to merchants that exclusively use imprint machines or standalone dial-out terminals that cannot or do not store cardholder data physically or digitally.
- SAQ B-IP – Applies exclusively to merchants that use payment transaction security (PTS) compliant terminals that have IP connections but do not store cardholder data.
- SAQ C-VT – Applies to merchants that manually enter their transactions into a virtual terminal interface that cannot or does not provide electronic cardholder data storage.
- SAQ C – Applies to merchants that use payment application systems that are connected to the internet but that do not or cannot provide electronic cardholder data storage.
- SAQ P2P-HW – Applies to merchants that use hardware payment terminals managed exclusively via a PCI Point to Point Encryption (P2PE) complaint or approved solution.
- SAQ D – Applies to any party that does not fit the descriptions above but must comply:
-
- The SAQ D-M applies exclusively to merchants outside the above categories.
- The SAQ D-SP applies exclusively to service providers outside those categories.
Nothing about these distinctions is strictly tied to a company’s PCI Level. However, merchants processing a higher volume of transactions are unlikely to fall into one of the few categories that exclusively apply to face-to-face transactions.
Implementing the DSS Framework at All Levels
Recapping from above, PCI DSS level 2 requirements include selecting the appropriate SAQ from above, filling it out, then contracting a QSA to verify your answers and ensure compliance. Critical considerations when choosing which QSA to work with include determining whether you need assistance with the actual implementation itself or just with verifying security and integrity.
Before a company begins to assess and document its implementation, it needs to ensure that it’s able to integrate all applicable PCI DSS controls. The subsection immediately below will detail the core of the PCI DSS framework, including its six Goals and twelve Requirements.
As an SSC-approved third party, RSI Security, can help with all elements of implementation and compliance. Our dedicated PCI DSS compliance advisory suite encompasses integration, reporting, and ongoing maintenance.
Breakdown of PCI DSS Goals and Requirements
The current DSS, as of May 2018, is PCI DSS v3.2.1. Its core breaks down as follows:
- Goal 1: “Build and Maintain a Secure Network and Systems”
- Requirement 1: Install and keep firewall or filtering configurations up to date.
- Requirement 2: Remove vendor-supplied security settings and replace them.
- Goal 2: “Protect Cardholder Data”
- Requirement 3: Protect card and cardholder data that is stored in your servers.
- Requirement 4: Encrypt card and cardholder data prior to public network traffic.
- Goal 3: “Maintain a Vulnerability Management Program”
- Requirement 5: Safeguard against malware with antivirus monitoring software.
- Requirement 6: Develop and maintain secure programs, applications, etc.
- Goal 4: “Implement Strong Access Control Measures”
- Requirement 7: Restrict card and cardholder data access by business need.
- Requirement 8: Authenticate the identity of all individuals who access data.
- Requirement 9: Restrict access to devices and proximities with sensitive data.
- Goal 5: “Regularly monitor and test networks”
- Requirement 10: Monitor all access to sensitive networks for any irregularities.
- Requirement 11: Perform assessments of security practices at regular intervals.
- Goal 6: ”Maintain an Information Security Policy”
- Requirement 12: Develop and distribute a policy addressing the entire staff.
These controls have remained stable over many editions of the DSS, dating back nearly two decades. Experts speculate that there will not be many changes in the upcoming DSS v4.0.
Complying with All Applicable PCI Controls
Another critical consideration for meeting PCI level 2 requirements is that the PCI DSS may not be the only PCI framework to which your company must adhere. The SSC has developed many other guides that apply to a wide range of business activities. In many cases, companies need to comply with multiple different PCI frameworks simultaneously, not to mention other, non-PCI regulations.
Alongside the PCI DSS, two other sets of PCI-specific rules are most widely applicable across various industries. Per the PCI SSC’s guidance on security guides, these include the Payment Application DSS (PA-DSS) and the PIN Transaction Security (PTS) security guides.
The PA-DSS applies to software developers and payment application vendors, along with the software they distribute to third parties. PTS breaks down into separate guides for Hardware Security Modules (HSM) and Point of Interaction (POI) guides. Let’s take a close look at each.
Payment Application (PA) DSS Requirements
The current PA-DSS v3.2, current as of May 2016, breaks down into 14 distinct Requirements:
- PA-DSS Requirement 1 – Ensure that the “full track data” for cards, including verification codes and personal identification numbers (PINs), is not stored or retained in any way.
- PA-DSS Requirement 2 – Protect cardholder data that is stored internally or externally.
- PA-DSS Requirement 3 – Utilize secure identification features to authenticate access.
- PA-DSS Requirement 4 – Log all activity on, with, or related to payment applications.
- PA-DSS Requirement 5 – Develop and maintain secure payment apps and software.
- PA-DSS Requirement 6 – Protect wireless transmissions of or pertaining to card data.
- PA-DSS Requirement 7 – Perform regular tests and scans on payment applications to identify, address, minimize, and mitigate vulnerabilities that can impact cardholder data.
- PA-DSS Requirement 8 – Facilitate and maintain a secure network implementation.
- PA-DSS Requirement 9 – Ensure that no cardholder data is ever stored on a server, network, or other systems that are connected to the internet or could be accessed online.
- PA-DSS Requirement 10 – Facilitate remote, secure access to payment applications.
- PA-DSS Requirement 11 – Encrypt cardholder data for transmission over networks.
- PA-DSS Requirement 12 – Secure all instances of non-console administrative access.
- PA-DSS Requirement 13 – Maintain an Implementation Guide for clients, resellers, etc.
- PA-DSS Requirement 14 – Assign responsibilities pertinent to PA-DSS implementation across all personnel and maintain training programs for staff, customers, integrators, etc.
The PA-DSS is derived from the PCI DSS. Therefore, its Requirements and adherence efforts overlap with the DSS’s, but companies must carefully document their implementation separately for compliance across both guides.
PIN Transaction Security (PTS) Requirements
The current PTS-HSM v3.0 (June 2016) comprises four modules, which break down as follows:
- PTS-HSM Module 1: “Core Requirements” – Comprising numerous Physical and Logical Security Requirements, along with Policies and Procedures for compliance.
- PTS-HSM Module 2: “Key-Loading” – Comprising measures for this kind of device.
- PTS-HSM Module 3: “Remote Administration” – Comprising Logical Requirements and controls for message authentication, key generation, and digital signature devices.
- PTS-HSM Module 4: “Device Management Security Requirements” – Comprising Device Security Requirements for both during and after all device manufacturing.
The current PTS-POI v6.0 (June 2020) also comprises four modules, mirroring those above:
- PTS-POI Module 1: “Physical and Logical Requirements” – Similar to PTS-HSM’s.
- PTS-POI Module 2: “POS Terminal Integration” – Integration and PIN Requirements.
- PTS-POI Module 3: “Communications and Interface” – Requirements for all the protocols and interfaces of POI devices that relate to communication functionalities.
- PTS-POI Module 4: “Life Cycle Security Requirements” – Requirements for device management that span from early manufacturing stages through initial implementation.
As with the PA-DSS, these controls build off of and overlap with DSS controls. When applicable, companies need to document their implementation separately from PA-DSS and DSS controls.
Professional Compliance Advisory Services
Compliance with the DSS at PCI Level 2 involves implementing all DSS controls, filling out the SAQ, and a QSA’s AOC form for verification. This differs from compliance at the lowest level, where just a SAQ is required, and the highest level, where an ROC is also required. At all levels, working with a QSA facilitates both implementation and reporting. To see how simple the entire compliance process can be, contact RSI Security today.
