Blog
When it comes to PCI requirements, it’s important to first understand that there are different levels or tiers of merchants, each with PCI DSS requirements unique to their individual tier. As expected, the number and type of transactions processed, on an annual basis, generally form the governing factor which will ultimately determine a merchant’s tier. But, wait, … what is a merchant in the first place?
Introduction: Merchant Defined
With respect to PCI DSS, the term merchant refers to any entity that accepts payment cards from any of the five members of the PCI SSC.
Payment Card Industry Security Standards Council, colloquially known as PCI SSC, is a governing organization and open forum responsible for the development, management, education and awareness of PCI Security Standards, including Data Security Standard (PCI DSS) and Payment Application Data Security Standard (PA DSS.) Members of the PCI SCC consist of the five major payment card brands: Visa, MasterCard, American Express, Discover and JCB.
In other words, if your business accepts credit cards as a method of payment, you are defined by the PCI DSS as a merchant.
PCI DSS: Merchant Tiering System Defined
In order to adequately manage a wide variety of businesses, and the appropriate level of testing required, the PCI SSC created four different categories, ranging from Tier 1 to Tier 4. Each tier is based on the quantity of transactions processed annually by any given merchant. Additionally, the tier also dictates the level of testing that is required of each merchant.
Did you know? While the number of transactions processed annually dictates a merchant’s tier, any PCI DSS merchant could be reclassified to a Tier 1, at the credit card company’s discretion, if they have suffered a data breach.
PCI DSS Merchant Tiers & Requirements
Tier 1:
Any merchant processing over six million transactions annually, across all channels, or any merchant that has suffered a data breach. Credit card companies may upgrade any merchant to a Tier 1 at their own discretion.
PCI DSS Merchant Requirements:
Annual Report on Compliance
Minimum Quarterly network scan by an Approved Scanning Vendor
Annual Penetration Testing – Including Internal Network
Attestation of Compliance Form
Tier 2:
Any merchant processing between one million and six million total transactions annually.
PCI DSS Merchant Requirements:
Annual Self-Assessment Questionnaire (PCI SAQ) if the organization has a certified Internal Security Assessor on staff, or, Onsite Assessment conducted by a PCI SSC approved Qualified Security Assessor (QSA)
Minimum Quarterly network scan by an Approved Scanning Vendor
Depending on the PCI SAQ type, there may be requirements Including Penetration Testing
Attestation of Compliance Form
Tier 3:
Any merchant processing between twenty thousand and one million e-commerce transactions annually.
PCI DSS Merchant Requirements:
Annual Self-Assessment Questionnaire (PCI SAQ)
Minimum Quarterly network scan by an Approved Scanning Vendor
Depending on the PCI SAQ type, there may be requirements Including Penetration Testing
Attestation of Compliance Form
Tier 4:
Any merchant processing less than 20,000 e-commerce transactions annually, or any merchant processing a maximum of one million regular transactions annually.
In summary, the tiers are quite simple, the more transactions your organization processes, the higher the tier. There are two exceptions. The first, if an organization has suffered a breach, they will be moved right to Tier 1, at the credit card company’s discretion. As well, we need to be aware of the total transaction limitations for e-commerce and regular transactions in Tiers 3 and 4. Depending on the total number of each, a PCI DSS merchant may bypass Tier 3 entirely, moving from a Tier 4 to a Tier 2.
PCI DSS Merchant Requirements:
Annual Self-Assessment Questionnaire (PCI SAQ)
Minimum Quarterly network scan by an Approved Scanning Vendor
Depending on the PCI SAQ type, there may be requirements Including Penetration Testing
Attestation of Compliance Form
Penetration Testing: More than a PCI DSS Requirement
At Packetlabs, we believe it is crucial to highlight that PCI Compliance and Penetration testing should be approached as two individual pillars of a sound security posture. One should not get caught in the mindset that penetration testing is merely completed for the sake PCI DSS compliance. As a matter of fact, if you utilize penetration testing to secure your network and systems beyond the requirements laid forth by PCI DSS, you will undoubtedly achieve compliance and reduce your organizations risk of a data breach in the process.
All tiers, with the exception of tier 1, are required to complete an annual PCI SAQ. As mentioned in a previous Packetlabs blog, the type of SAQ a merchant is required to complete is completely dependent on how their credit card payments are processed.
That said, depending on an organization’s individual SAQ category, the possibility exists that neither external vulnerability scanning or penetration testing are mandatory requirements for PCI compliance.
See Also:
On the other hand, if your organization falls under a PCI SAQ category that requires penetration testing, you will also be required to perform additional penetration testing when any significant changes are made to the Cardholder Data Environment (CDE). Oddly, the phrasing of ‘significant changes’ lends itself to possible misinterpretation which could lead to an insecure Cardholder Data Environment, viably leading to a breach. As mentioned, a data breach could kick a merchant at any merchant tier to a Tier 1, necessitating the most demanding requirements for PCI DSS compliance, not to mention the cost of recovery, brand damage, loss of customer trust, and downtime.
In order to avoid such an event, at Packetlabs, we recommend a minimum of annual penetration testing, as well as additional penetration testing after any changes have been made to the environment. If you would like to learn more about anything you read here, or what Packetlabs can do for your organization, please contact us for details.