As a PCI DSS Qualified Security Assessor, I’ve had this conversation far too many times now. Many hosting providers make claims of PCI DSS compliance, however when trying to verify that compliance we are met with obfuscation and frustration. I have seen so many certificates, ASV scan reports, merchant attestations and other documents which service providers hold up to claim PCI DSS compliance that it just isn’t funny anymore.
Ultimately, it is the Merchant that has responsibility for PCI DSS compliance. It is the Merchant who owns the contract with the acquiring bank. It is the Merchant who will be fined in the event that cardholder data is breached. It is the Merchant’s responsibility to ensure that all their service providers who could impact the security of cardholder data are fit for purpose. It is the Merchant who, to all intents and purposes, is on the hook. This is covered by PCI DSS Requirements 12.8, 12.8.1, 12.8.2, 12.8.3, 12.8.4 and 12.8.5.
PCI DSS requirement 12.8, and associated sub-controls requires that the Merchant entity performs appropriate due diligence of service providers before engagement, and at least annually thereafter.
As a Merchant, how do you deal with this?
The first piece is to understand how your shopping cart software integrates with your payment gateway and what SAQ (Self-Assessment Questionnaire) you are eligible to complete. For E-Commerce, this will be either SAQ-A, SAQ-A/EP or SAQ-D.
- SAQ-A is applicable when all cardholder data functions are outsourced to a PCI DSS compliant third party such that the Merchant has no visibility to cardholder data. This is through a redirect to a hosted payment page or through an iFrame.
- SAQ-A/EP is applicable where there are more creative payment mechanisms involved such as client-side javascript pulled directly from the payment gateway. These mechanisms are also known as Direct Post or Silent Order Post amongst others. My advice is to avoid this as the PCI DSS compliance requirements mandated by SAQ-A/EP are technically complex and expensive to implement.
- SAQ-D is applicable where the Merchant’s website is directly taking cardholder data from the customer. SAQ-D applies PCI DSS in it’s entirety which is also to be avoided as the PCI DSS compliance requirements are technically complex and expensive to implement, even moreso than SAQ-A/EP.
The second piece is to fully understand the scope of the hosting provider’s service provision to you. How could your hosting provider impact the security of your cardholder data? Remember, if your service provider screws up and your customer’s payment card details are exposed, you’re the one who’s on the hook. You as the merchant own the contract with the acquiring bank.
Hosting services generally come in four flavours:
- Co-location. You have purchased some space in a rack from the hosting provider. Into that space, you install your server, deploy your own operating system, application stack and shopping cart software. You have complete responsibility for everything other than the physical security of the system which has been deployed.
- Hardware. You have purchased some space and a server from the hosting provider. Onto that server, you deploy your own operating system, application stack and shopping cart software. You have complete responsibility for everything other than the physical security of the system which has been deployed.
- Platform-as-a-Service. You have purchased some space and a server from the hosting provider. The hosting provider has also deployed an operating system onto that server and the hosting provider has a login to that server. Your hosting provider is now operating within your cardholder data environment and falls into your scope.
- Software-as-a-Service. You have purchased some space and a server from the hosting provider. The hosting provider has also deployed an operating system, application stack and shopping cart onto that server and the hosting provider has a login to that server.
Generally, with (1) and (2) your hosting provider will fall outside the scope of PCI DSS as they have no logical access to your server. This is not always the case as there may be Out-Of-Band management controllers or other mechanisms outside the software elements which are under your control where the hosting provider still has some level of access to your cardholder data environment.
With (3) and (4) the hosting provider falls into your scope. They have access into your cardholder data environment, so you now have to determine which controls are applicable to your hosting provider.
Ideally you want your hosting provider to be out of scope, however there is an argument that you want to outsource the technical expertise rather than hire somebody directly. This great idea, subject to your outsourcing partner being properly compliant with the PCI DSS.
So how do you validate the compliance of a hosting partner?
There are two critical documents. The PCI DSS Attestation of Compliance, and the contracts, agreements & terms of service you have with the hosting partner.
The PCI DSS Attestation of Compliance defines the service provider’s PCI DSS compliance scope, both as the environment which forms the services, and the PCI DSS controls for which the service provider bears responsibility. The attestation is required for PCI DSS requirements 12.8.3 and 12.8.4.
The contracts, agreements and terms of service defines the scope of the service provision which must align with scoping statements in the attestation. If the contract contains services which are not covered by the attestation, these services are NOT PCI DSS compliant.
This is further complicated when a separate web development company is involved. You now have two third parties who can impact the security of your cardholder data. Who is responsible for what? In this case, it is better to create a “Matrix of Responsibilities” document which defines which entity bears responsibility for each control, or which responsibilities are shared between entities and how those responsibilities are shared. This gets complicated and you should seek professional guidance.
In summary, the merchant has primary responsibility for PCI DSS compliance. Any service providers which are engaged in any capacity providing people, process or technology with access to your environment are in your PCI DSS scope. For you to be compliant as a merchant, you need a valid PCI DSS service provider Attestation of Compliance document, and a contract which both covers the scope of their service provision to you, and aligns with the scoping statements with the attestation. If you don’t have these things, then you’re unlikely to be compliant.
