Choosing a PCI DSS Compliant Web Host for a Small Business

"PCI compliant hosting" is a phrase hosts use in marketing, and it means less than it sounds. A host can be assessed against PCI DSS for the service it provides; your website cannot inherit that. This guide covers the decision that matters more than the choice of host, what a host's compliance does and does not cover, and what to ask before you sign. It names no host and quotes no price, because both change faster than the standard does.

Decide how the payment page is delivered first

How the card form reaches your customer's browser decides how much of PCI DSS your website carries, and so how much you need from your host. The SAQ Instructions and Guidelines (v4.0.1 r1) set it out:

How the site takes payment	SAQ, if eligible	PCI DSS requirements in it
The payment page is entirely hosted and managed by a compliant payment provider, and you have no access to it	SAQ A	14
Your site redirects the customer to a compliant provider's page	SAQ A	27
Your site embeds a compliant provider's payment form in an iframe	SAQ A	27
Your site creates the form and the browser posts card data straight to the provider ("Direct Post")	SAQ A-EP	139
Your site loads a script that builds the payment page or controls how card data is sent	SAQ A-EP	139
Anything else, including card data passing through your own server	SAQ D	All

With a redirect or an iframe, your site never receives card data, but it controls where the customer is sent or what frames load, so it is still a target. That is why SAQ A for v4.x includes external vulnerability scans of those pages for both (11.3.2 and 11.3.2.1; the Council's FAQ 1604). An iframe merchant must also confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems; the Council's FAQ 1588 says that criterion does not apply to a redirect. With Direct Post or a script on your page, your site is part of the payment transaction, and the host is carrying part of that.

Find my SAQ works through the full eligibility criteria. How iframes simplify PCI DSS compliance covers the embedded option.

Your host is a service provider

A host that runs your payment pages, or anything that could affect their security, is a third-party service provider. That brings in 12.8 on your side: list the host and what it provides, have a written agreement in which it acknowledges its responsibility, check its compliance status at least once every 12 months, and record which requirements it manages and which you do (12.8.1 to 12.8.5).

The Council's FAQ 1312 is clear that 12.8 does not require the host to be validated as compliant. But any requirement the host meets on your behalf counts in your own assessment, so if the host cannot show it is met, it is not met for you.

What kind of hosting, and who does what

The type of hosting mostly decides how the work is split:

• Shared hosting. Many customers on the same servers. The host is a multi-tenant service provider, and Appendix A1 of the standard applies to it: separation between customers, audit logs each customer can review for its own environment, and support for a customer's forensic investigation. You control very little of the platform, which suits a site that only redirects or embeds a provider's page.
• Virtual private server (VPS) or dedicated server. You usually control the operating system and everything on it, so hardening, patching, logging and anti-malware on that server are yours unless a contract says otherwise.
• Managed hosting. The host takes on some of the server work you would do on a VPS. Which parts is exactly what the responsibility record under 12.8.5 has to say.
• A hosted e-commerce platform (the platform runs the whole store, checkout included). Closest to the first row of the table above, if the platform's own compliant service handles the payment page.

What to ask a host

1. An Attestation of Compliance that covers the service you are buying. FAQ 1576 says a provider is expected to provide its AOC on request, and it should apply to the services it provides to you. An AOC for the host's data centres does not cover a managed plan or an application it runs for you unless those were in scope.
2. A written statement of who is responsible for what. Under 12.9.2, a service provider must tell customers on request which requirements are its responsibility, which are the customer's, and which are shared. A responsibility matrix is the usual form.
3. The written acknowledgement 12.8.2 and 12.9.1 require, in the contract.
4. For shared hosting: how customers are separated, how you get your own logs, and whether you can commission your own penetration testing; 11.4.7 requires multi-tenant providers to support customers' external penetration tests.
5. How the site will be scanned. Your quarterly ASV scan has to reach your site, so ask how the host handles scanning traffic and whether its protections will need adjusting for the scan.
6. How administrators get in. Non-console administrative access must be encrypted (2.2.7), and where the server is part of the cardholder data environment, non-console access into it needs multi-factor authentication (8.4.2).
7. How the host tells you about a security incident affecting your site, so your own incident response plan (12.10.1) can rely on it.

What a host cannot do for you

A host's compliance covers the host. It does not cover the plugins, themes and third-party scripts on your site, the admin accounts you create, or the choices you make about the payment page. Keeping those in order stays with you, and for most small merchants the cheapest way to keep that list short is the top of the table above: let a compliant payment provider serve the whole payment page.

Should my service provider be PCI compliant? covers the 12.8 obligations in more depth.