The PCI DSS standard remains the same, regardless of your organisation. However, there are some differences in how to approach compliance.
PCI DSS compliance affects different types of organisations, the most common being Merchants and Service Providers. The PCI DSS standard remains the same, regardless of your organisation. However, there are some differences in how to approach compliance. This article explores some of those differences.
Merchants are the most common type of organisation affected by PCI compliance. Merchants are organisations that process card transactions via any number of channels. They can range from high-street stores and energy providers to online shops and charities.
Service Providers are defined as any organisation that stores, processes or transmits cardholder data on behalf of another entity. This also includes companies that could impact the security of that cardholder data. This covers various types of organisations, including hosting providers, call centres, network support, payment processing, media storage centres, data destruction and many others.
Some organisations can fall into both categories, handling card payments for themselves and also on behalf of other companies.
The first thing to establish as an organisation is what Level you are under PCI DSS guidelines. The Level of Merchant or Service Provider you are is normally set based on the number of transactions made per year, though it can be increased if you are considered to be a high risk entity (as a result of past breaches).
This is described in Figure 1, though it must be stressed that this table is just a summary, and organisations should seek expert guidance.
It should also be noted that this is based on the number of transactions only, and not the value of those transactions, since a breach of a single card is worth the same to a criminal regardless of how much was paid in the original transaction.
The Merchant or Service Provider Level does not denote how compliant you must be, or which parts of the standard apply. The PCI DSS applies whether you are processing 1 card or 1 billion cards. What changes is how you obtain and prove that compliance. For Level 1, this will require a full audit by an independent PCI QSA assessor; lower Levels may submit a Self Assessment Questionnaire (SAQ).
For Merchants, there are four Levels, with Level 1 being the highest and Level 4 the lowest. The guidance on how to determine each Level is set by the card brands. However, ultimately it is the Merchant Acquirer (also known as the Acquiring Bank) who sets this Level. If you are in any doubt, please contact your acquirer. The Level for Merchants is also based on the transactions that are processed by that particular acquirer and are not aggregated. Merchants with multiple payment channels and different acquirers may find that they are processing enough in total to warrant being a Level 1 Merchant, but in fact only have to validate to each Acquirer as a Level 2.
For Service Providers, there are only two Levels, Level 1 and Level 2. Unlike Merchants, Service Providers must look at the aggregate number of transactions per year to determine which Level they are.
One of the key differences between Merchants and Service Providers is how compliance is validated. Merchants validate their compliance by submitting evidence to their Acquirer, whereas Service Providers must submit evidence to the individual Card Brands (which are Visa, MasterCard, American Express, JCB and Discover).
Both Level 1 Merchants and Service Providers can only validate compliance with an independent assessment by a PCI QSA. Level 2 (and below) Merchants and Service Providers may be able to complete an SAQ to validate compliance. For Merchants, there are multiple SAQs, each of which represents a subset of PCI requirements and can be completed if certain criteria are met. For Service Providers who wish to self-assess (and Merchants who do not meet the criteria for any other SAQs) SAQ D must be completed. SAQ D constitutes the full set of PCI requirements.
A common misconception is that there is such thing as partial compliance. As far as PCI DSSassessments go, you are either compliant or noncompliant. This has a number of ramifications.
Firstly, as a Merchant, you cannot obtain compliance for certain parts of your environment. You must validate the organisation as a whole (single) entity. We have seen many Merchants with multi-faceted organisations use different SAQs to determine which parts of the organisation are in line with PCI DSS requirements. Whilst this approach is a useful aid, any single non-compliance will mean that the entire organisation is non-compliant. Furthermore, a single assessment for validation must cover all of these environments together.
Secondly, there cannot be ‘PCI compliant’ solutions in place that negate the need for compliance. This is because the standard applies to the environment in which cardholder data is handled. To put this into context, a non-compliant Service Provider that managed a call centre for their customer might state that they had a ‘compliant voice solution’. This statement is misleading as, whilst the solution may support their compliance efforts, it does not remove the rest of the environment (such as workstations, call operators, data centres and so on) from the scope of compliance. The Service Provider is still non-compliant and still affects their customer’s compliance program.
One point to note is that, whilst Merchants assess the organisation as a whole, Service Providers validate compliance for one, some or all of the services they offer. A Service Provider may be able to offer a PCI-compliant dedicated hosting solution, for example, whereas other services (e.g. their shared hosting platforms) may not be compliant.
There is no such thing as an official ‘Certificate of Compliance’, though there is certainly demand for such from organisations looking to promote themselves as compliant. This has led to some assessor companies offering rather flashy-looking pieces of paper – great for marketing material but not much else.
The real proof of compliance is a signed and submitted Attestation of Compliance (AoC). Completed by an officer of the company responsible for compliance (typically the CFO or similar), this attestation certifies that all of the relevant PCI requirements have been met. If the assessment that took place was an audit, this will also be countersigned by the lead QSAresponsible for the assessment.
Service Providers may provide a completed AoC to their customers, however the card brands also maintain a list of compliant Service Providers on the appropriate web pages. This lists the Service Provider, compliance date (and whether self-assessed or independently audited) and other important information. It is also concrete evidence that the Service Provider is compliant, though the customer should take care that compliance was attained for the service being provided.
For entities that validate as both a Merchant and a Service Provider, the appropriate AoC should be provided. Validating as a Merchant only demonstrates that you are handling your own card details in a compliant manner, and does not validate that the service that you offer to customers will also be compliant.
Establishing the scope of the Cardholder Data Environment (CDE) and hence the scope of an assessment is an extremely challenging issue. The standard is relatively clear with quite prescriptive controls, but a minority of those requirements need interpretation. A significant portion of the work that we do to help clients become compliant focuses on establishing, identifying changes to, and reducing the scope of compliance. Techniques have been discussed at previous MWR Briefings and in the PCI for Merchants paper. This section will cover how the scope of assessments can be affected by the use of compliant and non-compliant Service Providers.
Service Providers that are not compliant have two options open to them. They can either undergo a PCI DSS assessment to validate compliance, or have their services reviewed as part of each customer’s PCI DSS assessment.
A Merchant that is using a noncompliant Service Provider will therefore find that the scope of their PCI DSS environment has been increased, and may actually harm the Merchant’s currentPCI compliant status.
From a Merchant’s perspective, it is obviously preferable to use a PCI-compliant Service Provider. Bringing in a Service Provider’s environment to the scope of the Merchant’s compliance program can be costly. Despite Right to Audit clauses commonly found in outsourcing contracts, obtaining full access to a Service Provider’s systems and data may be difficult, particularly for shared environments where separating an individual customer’s data may be difficult or impossible.
There is great value in obtaining PCI DSS compliance as a Service Provider. Compliance offers a business benefit for those Service Providers that are able to offer it to their customers. As Merchants seek to outsource more of their cardholder data functions and reduce their compliance burden, Service Providers that can provide compliant services are uniquely positioned. Furthermore, with validated compliance, the cost in resourcing and accommodating multiple audits by multiple customers is significantly reduced.
We hope that this article has answered some of the basic questions about how Merchants and Service Providers go about attaining (and maintaining) PCI compliance. Compliance benefits both Service Providers, as a key business differentiator, and Merchants, who make use of these services in supporting their own compliance efforts.
Figure 1: Summary of Merchant and Service Provider Levels
|1||6 million+ transactions
|2||1-6 million transactions||
|3||20,000-1 million e-commerce transactions||
|4||<20,000 e-commerce transactions
<1 million otherwise
|Service Provider Level||Criteria||Validation|
|1||300,000+ transactions annually||
|2||<300,000 transactions annually||