PCI Compliant Hosting: Scoping Your Cardholder Environment

You take card payments, and someone in finance, a customer or your acquiring bank has asked whether your hosting is PCI compliant. It is a fair question with a misleading shape. No hosting provider can make your business compliant. What a provider can do is take responsibility for part of the environment, and how big that part is depends almost entirely on how you scope your cardholder data environment.

So start with scope. This article covers what sits inside it, three ways to shrink it before you choose a host, where the host's responsibility usually stops, and the questions that tell you whether a provider can carry its share. It builds on the shared responsibility model, which applies to payment data the same way it applies to everything else you run in the cloud.

What "PCI compliant hosting" actually means

The Payment Card Industry Data Security Standard (PCI DSS) is maintained by the PCI Security Standards Council (PCI SSC). The current version is 4.0.1. Version 4.0 was retired at the end of 2024, and the requirements it had marked as future-dated became mandatory on 31 March 2025. The council publishes the standard, the Self-Assessment Questionnaires (SAQs) and its scoping guidance in the PCI SSC document library.

When a hosting provider says it offers PCI compliant hosting, it usually means one of three things:

It holds its own Attestation of Compliance (AOC) as a service provider, covering the specific services it was assessed on.
It will help you meet requirements on the infrastructure it runs, without an AOC of its own.
It is using the phrase loosely, and neither of the above is true.

Only the first reduces the work in your own assessment, and only for the services the AOC lists. An AOC names the services that were assessed and the ones that were not. If the service you buy sits in the second list, it is in your scope.

What sits inside your cardholder data environment

Your cardholder data environment (CDE) is every system component that stores, processes or transmits cardholder data or sensitive authentication data. That part is intuitive. The part that catches teams out is what PCI DSS pulls in alongside it.

Systems in the CDE. Web servers that render the payment form, application servers that handle card numbers, the databases that store them, and anything else that touches account data directly.

Connected-to systems. Anything that can reach the CDE without restriction. A monitoring server that polls the payment database, the jump host your engineers use to get in, or a build server that deploys code into it.

Security-impacting systems. Components that could affect the security of the CDE without ever seeing a card number. Directory and authentication servers, log collectors, patch servers and the hypervisor underneath your virtual machines all count.

A flat network makes this worse. If every virtual machine in your environment can talk to every other one, there is a strong case that all of them are in scope.

Three-ring diagram of PCI DSS scope, with the cardholder data environment at the centre, connected-to systems such as a jump host and CI runner around it, and security-impacting systems such as directory and logging in the outer ring. — PCI scope extends beyond card data to connected systems and those that can affect the CDE’s security.

If you are deciding where a payment workload should live, our managed private cloud page sets out what the platform includes and what stays with you.

Three ways to shrink scope before you choose a host

Scope is the biggest lever you have on cost and effort, and these three decisions move it further than any choice of host.

Take the payment page off your servers. If customers enter card details on a page hosted by your payment provider, through a redirect or an embedded payment form, card numbers never reach your servers. That usually qualifies you for a much shorter SAQ. It does not remove every obligation, because the page that loads or redirects to the payment form can still be tampered with. Check the eligibility criteria on the current SAQ version rather than relying on what applied two years ago.

Tokenise anything you store. If you need to charge a card again, store a token from your payment provider instead of the card number. Systems that hold only tokens, with no way to turn them back into card numbers, can fall outside the CDE.

Segment what is left. PCI DSS does not require network segmentation, but without it the whole network is in scope. On a private cloud, segmentation means a separate network for the CDE, network isolation between projects, and firewall rules that deny by default and allow only named flows. Our guide to firewall rules and security groups covers how to build those rules.

Segmentation has to be proven, not assumed. PCI DSS requires penetration testing of segmentation controls at least once a year, and every six months for service providers.

Side-by-side comparison of a flat network where every virtual machine is in PCI scope and a segmented network where security groups limit scope to three servers in the cardholder data environment. — Segmentation can reduce scope, but monitoring connected to the CDE remains in scope.

Where the host's responsibility ends

PCI DSS expects you to know exactly which requirements each third-party service provider covers. Requirement 12.8 asks you to keep a list of providers, hold written agreements with them, check their compliance status at least once a year, and record which requirements each one manages. Requirement 12.9 asks service providers to acknowledge in writing the requirements they are responsible for.

In practice that becomes a responsibility matrix. Where the provider runs the hardware and platform and you run the virtual machines, it usually splits like this.

Typically the provider's

Physical security of the data centre
Hardware, including secure disposal of storage media
The hypervisor and platform layer
Network infrastructure up to the edge of your environment

Typically yours

How card data flows through your application
Guest operating systems and what runs on them, unless patching is contracted to the provider
User accounts, multi-factor authentication and access to your virtual machines
Logging and log review for your systems
Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV)
Your policies, training and incident response

Shared, and where findings tend to appear

Firewall rules, where the provider supplies the capability and you define the rules
Patching, where the contract has to say who patches what
Backups, which are in scope whenever they contain card data

Layered diagram of a typical PCI DSS responsibility split, with physical, hardware and platform layers owned by the hosting provider, application and card data owned by the customer, and firewall rules, patching and backups shared. — A written responsibility matrix defines what your provider covers, what you own and which duties are shared.

We used the same structure for healthcare data in our article on HIPAA compliant hosting. In both frameworks, the shared row is where the problems show up.

What to ask a hosting provider

Do you have a current PCI DSS AOC, and which services does it cover? Ask to see both lists. A provider with an AOC for colocation may not have one for its managed cloud.

Will you give us a responsibility matrix? It should map to the 12 PCI DSS requirements rather than mark everything "shared".

Will you acknowledge your responsibilities in writing? You need this for Requirement 12.9.

Who on your side can access our virtual machines, and how is that logged? Provider staff with administrative access are part of your access control story.

Where are backups and snapshots stored? If they contain card data, that storage is in scope.

Is the hardware dedicated or shared? Multi-tenant infrastructure can support a compliant environment. Dedicated infrastructure makes it easier to answer an assessor who asks who else was on the hardware.

Where InMotion Cloud fits, and where it doesn't

InMotion Cloud is managed private cloud built on OpenStack. Our engineers can help you design the segmentation described above, configure security groups and isolated networks, and patch and harden the operating systems in your environment, as part of the managed services included on every plan.

Summary

PCI compliant hosting is a shared arrangement, and scope decides the size of your share. Take card entry off your servers where you can, tokenise what you store and segment what remains. Then hold any provider to a written responsibility matrix, backed by an AOC that names the services you are buying.

Not sure what sits inside your cardholder data environment? InMotion Cloud engineers will review your architecture and show you which parts of the platform are in scope.

Talk to a cloud architect →

Frequently asked questions

Is there such a thing as PCI certified hosting? No one certifies a host as making you compliant. A provider can hold an AOC for the services it was assessed on, which covers its part. Your own compliance is validated separately.

Does using a PCI compliant host make my website compliant? No. The host's AOC covers the services it lists. Your application, card data flows, access controls and policies are assessed on their own.

What is a cardholder data environment? The systems that store, process or transmit cardholder data or sensitive authentication data, plus the systems connected to them without restriction.

Do I need network segmentation for PCI DSS? It is not mandatory, but without it every system on the same network can fall into scope. If you rely on segmentation, it has to be tested at least once a year.

Are backups in PCI scope? Yes, if they contain cardholder data. Where they are stored, who can reach them and how they are protected all count.

Which PCI DSS version applies now? Version 4.0.1. Version 4.0 was retired at the end of 2024, and its future-dated requirements became mandatory on 31 March 2025.