PCI-Compliant Hosting: Your Checkout Decides This, Not Your Host

The phrase “PCI-compliant hosting” sells a product that only half exists. A host can genuinely hold a PCI attestation for its own infrastructure — but that attestation covers their data centre, not your store.

And the thing that actually determines how much PCI work you face isn’t which host you pick. It’s how your checkout is built.

First, a correction that saves you money

A lot of current advice tells small merchants that PCI DSS v4.0’s future-dated requirements 6.4.3 and 11.6.1 — payment-page script inventory, and weekly tamper detection on payment pages — became mandatory for them in March 2025, and that shared hosting can’t deliver them.

The opposite happened. The PCI Security Standards Council removed 6.4.3 and 11.6.1 from SAQ A, effective 31 March 2025 — the same date people cite as the deadline.

They were replaced with a new eligibility criterion: you confirm that your site is not susceptible to attacks from scripts that could affect your e-commerce systems.

Two things follow, and they pull in opposite directions:

If you’re on SAQ A, you don’t owe the formal 6.4.3 and 11.6.1 controls. You don’t need a script inventory with integrity checks, and you don’t need a weekly change-detection mechanism on your payment page. Don’t buy tooling for requirements that no longer apply to you.

But you can’t ignore client-side script risk either, because the replacement criterion is an attestation about exactly that. Arguably it’s harder to evidence than a checklist was — a checklist you can tick, a susceptibility judgement you have to actually make.

And they still apply if you’re not on SAQ A. Requirements 6.4.3 and 11.6.1 remain in force for merchants validating under SAQ D and for anyone presenting an Attestation of Compliance from an onsite assessment.

Which brings us to the decision that matters.

Your checkout architecture sets your scope

To qualify for SAQ A, every element of the payment page delivered to the customer’s browser must originate only and directly from a PCI DSS compliant third-party service provider or payment processor. Not “mostly.” If your own script participates in collecting card details, you’ve left SAQ A.

This is the single highest-leverage decision in the whole exercise. Moving from SAQ D to SAQ A removes the overwhelming majority of the work — and it’s an implementation choice made in an afternoon, not a hosting purchase. If you handle card data on your own server and you don’t have a compelling reason to, stop. Use the processor’s hosted fields or a redirect and let them carry the scope.

Note also that your acquiring bank decides which validation applies to you, not your host and not an article. Ask them before you build a plan around a guess.

The cost line people forget

Even on SAQ A, Requirement 11.3.2 obliges you to pass an external vulnerability scan performed by a PCI SSC-listed Approved Scanning Vendor at least once every three months.

For an e-commerce merchant on SAQ A, that scanning applies to the system hosting the page that redirects to — or embeds the payment form from — your compliant provider. Which is your web server. Which is a hosting question.

Penetration testing is a different matter. It’s formally required for SAQ A-EP, SAQ D and full Report on Compliance validation, and not for SAQ A. That difference alone is a decent argument for keeping your checkout on the SAQ A side of the line.

Budget the ASV scan as a recurring line, four times a year, plus the time to remediate whatever it flags. That remediation is where hosting choice starts to matter, and it’s the next section.

What a host can and can’t do for you

“PCI-certified infrastructure”

The provider holds an Attestation of Compliance as a service provider. This is real and it is not what most buyers think they’re getting. It means the provider’s own environment — the data centre, the hypervisor, their internal controls — has been assessed. It says nothing about your application, your plugins, your TLS configuration or your checkout.

Useful, and necessary if you’re on SAQ D and need to evidence your provider’s status. Not sufficient for anything.

“PCI-supporting managed hosting”

The provider will actually help you pass a scan: keeping the stack patched, TLS current, disabling the protocols and ciphers ASV scans fail you on, and responding when a scan flags something in their layer.

This is the thing worth paying for, and it’s a support-quality question rather than a certificate question.

The shared hosting problem nobody mentions

On shared hosting, your ASV scan targets an IP address you share with other tenants. A vulnerable service or an outdated TLS configuration belonging to somebody else’s site on that address can appear in your scan results — and you have no ability to fix it and limited ability to get it fixed.

You’ll also generally have no control over the platform’s software versions, which are precisely what a scan interrogates.

That’s the substantive technical argument for a VPS or a managed store platform over shared hosting for merchants — not that shared hosting is insecure, but that it puts your compliance evidence in someone else’s hands.

The honest recommendation

For most small merchants: use a hosted or embedded checkout from a compliant processor, stay on SAQ A, buy hosting good enough to pass a quarterly ASV scan, and budget the scan. Your host barely features in this, and that’s the correct outcome.

If you must handle card data, you’re on SAQ D, you owe 6.4.3 and 11.6.1 among much else, and you want a provider that will engage with an assessment rather than one that emails you a certificate.

The providers

Liquid Web — the fully-managed end, and the right shape if you’re on SAQ D and need a provider who will actually participate in an assessment rather than point at their own AOC. You’re buying an operations team, and priced accordingly. This is the one to consider when “who fixes the scan finding at 2am” needs a contractual answer.

Nexcess — managed hosting in the same family, oriented at stores specifically, with managed WooCommerce and Magento stacks. That store orientation matters here, because a platform kept patched by someone whose job it is removes a category of ASV findings.

Cloudways — managed hosting on your choice of underlying cloud, from $11 for 2GB with no term. It gives you a defined server rather than a shared IP, which addresses the shared-scan problem above, while still handling the patching. A reasonable middle for a growing store.

ScalaHosting — runs its own SPanel with managed security on its VPS plans, and includes the panel rather than licensing cPanel per account. For a merchant running a store plus client sites, that licensing difference is real money.

InMotion Hosting — long-standing host with strong support and unusually generous 90-day money-back terms. Worth pricing yourself; we could not read its current rates from its plan pages.

SiteGround — the most expensive of the shared-hosting options over three years at about $12.99/month effective, because a $2.99 promo runs only 12 months before renewing at $17.99. For a store taking money, the support quality is a defensible reason to pay it — but note the shared-IP caveat above applies to its shared plans.

If the store is the whole business, our ecommerce hosting comparison is the more relevant guide, and small business hosting covers the three-year cost arithmetic across the cheaper tiers.

How we checked this

We are not a Qualified Security Assessor and this is not compliance advice. Which SAQ applies to you is determined by your acquiring bank and your payment channels, and nothing here substitutes for asking them.

The SAQ A change is the load-bearing claim and we verified it against multiple independent sources, read on 18 August 2026: that the PCI Security Standards Council removed Requirements 6.4.3 and 11.6.1 from SAQ A effective 31 March 2025 and replaced them with an eligibility criterion requiring the merchant to confirm the site is not susceptible to script-based attacks affecting its e-commerce systems; that 6.4.3 concerns authorising, integrity-checking and inventorying payment page scripts while 11.6.1 concerns a change- and tamper-detection mechanism assessed at least weekly; and that both remain applicable to SAQ D merchants and to those presenting an Attestation of Compliance from an onsite assessment.

This corrects the brief we were given for this article, which stated that 6.4.3 and 11.6.1 became mandatory for hosting buyers in 2025 and that shared hosts cannot deliver them. For SAQ A merchants — the audience shared hosting serves — those requirements were withdrawn on the very date cited. Publishing it the other way round would have pointed small merchants at tooling they don’t need.

The scanning position — that Requirement 11.3.2 obliges an external scan by a PCI SSC-listed ASV at least once every three months, that this applies to SAQ A e-commerce merchants for the system hosting the redirecting or embedding page, and that penetration testing is required for SAQ A-EP, SAQ D and Report on Compliance validation but not for SAQ A — is from the same body of published guidance.

Read from secondary sources, not the standard itself. We have relied on payment-industry and assessor commentary rather than the PCI DSS v4.0.1 document and the SAQ instructions. Verify anything you’re going to rely on against the Council’s own published SAQ, which is free to download.

The shared-IP argument is reasoning from architecture, not a tested result. That shared hosting means a shared address, and that an ASV scan of that address can surface findings you don’t control, follows from how shared hosting works — but we have not commissioned an ASV scan against a shared host to demonstrate it, and how a given ASV scopes and reports findings varies.

We deliberately did not quote an ASV scan price. The brief asked for that line item and it’s a real one, but published figures vary by scanner, IP count and support level, and we could not verify a current range we’d stand behind. Get a quote rather than trusting a number from an article — including this one.

What we did not do: hold an account with any of these providers, request or read any provider’s Attestation of Compliance, verify any provider’s PCI status, run an ASV scan, or assess a merchant environment. Provider descriptions reflect how each positions itself plus pricing read across this series in August 2026.

The host links above are affiliate links. The central recommendation here — move your checkout to the processor and your host stops mattering much — argues against the premium managed hosting this page links to.

FAQ

Is there such a thing as PCI-compliant hosting?

Partly. A host can hold an Attestation of Compliance covering its own infrastructure, but that doesn’t make your store compliant. Your checkout architecture determines most of your obligations.

Do requirements 6.4.3 and 11.6.1 apply to me?

Not if you validate under SAQ A — they were removed from it effective 31 March 2025 and replaced with an eligibility criterion about script susceptibility. They do still apply under SAQ D and for onsite assessments with an AOC.

How do I reduce my PCI scope the most?

Never let card data reach your server. A redirect to your processor, or a payment page or form served directly by them, is what qualifies you for SAQ A — the shortest requirement set. It’s an implementation decision, not a purchase.

Do I still need quarterly scans on SAQ A?

Yes. Requirement 11.3.2 requires passing external scans by a PCI SSC-listed Approved Scanning Vendor at least every three months, and for e-commerce merchants that covers the system hosting the redirecting or embedding page.

Do I need a penetration test?

Not for SAQ A. Penetration testing is required for SAQ A-EP, SAQ D and full Report on Compliance validation, which is a further reason to keep your checkout on the SAQ A side.

Is shared hosting a problem for PCI?

It complicates your evidence. Your ASV scan targets an IP you share, so another tenant’s configuration can surface in your results with no way for you to fix it — and you don’t control the platform’s software versions either.

Who decides which questionnaire I use?

Your acquiring bank, based on how you accept payments. Ask them before building a compliance plan, because getting this wrong wastes either money or your validation.