PCI compliant hosting is hosting configured so that the parts of the payment card standard your infrastructure is responsible for are actually met — encryption in transit, patching, access control, logging and segmentation. The host cannot make you compliant on its own, because most of PCI DSS is about how you run your business, not where your site lives.
The good news is that the smartest move available to a small merchant is also the cheapest: arrange things so card numbers never touch your server at all. Here is what the standard requires, what changed in 2025, and how to shrink your obligations rather than satisfy them the hard way.
What is PCI DSS, and does it apply to me?
PCI DSS is the Payment Card Industry Data Security Standard, and it applies to any organization that stores, processes or transmits cardholder data. If you take card payments, it applies to you.
One important distinction: PCI DSS is not a law. It is a contractual standard maintained by the PCI Security Standards Council and enforced through your agreements with card brands and your payment processor. The consequences of failing it are commercial rather than criminal — fines passed down by your acquirer, higher transaction costs, and in serious cases losing the ability to accept cards at all.
That makes it easy to underestimate. It is also the reason nobody from the government will tell you that you are non-compliant; you usually find out when something has already gone wrong.
What changed in PCI DSS v4.x?
Version 3.2.1 was retired on 31 March 2024, leaving v4.0 and v4.0.1 as the active versions. Version 4.0 introduced 64 new requirements. Of those, 51 were future-dated and became effective on 31 March 2025.
The practical meaning is that the grace period is over. Requirements that were “best practice until” a date are now simply requirements, and an assessment today is measured against the full v4.x set.
The broad direction of v4.x is toward continuous security rather than annual box-ticking: more emphasis on authentication, on monitoring, and on being able to demonstrate that controls work rather than that they exist.
Which parts of PCI does PCI compliant hosting actually affect?
Your host is responsible for a slice of the standard, not all of it. The slice matters, though, because it is the part you cannot fix with a policy document.
- Encryption in transit. Strong TLS on anything that carries cardholder data, with weak protocols and ciphers disabled rather than merely deprecated.
- Patching and vulnerability management. Operating system and software updates applied on a defined schedule, with a way to show they were.
- Access control. Unique accounts, least privilege, multifactor authentication on administrative access, and no shared logins.
- Logging and monitoring. Audit trails that exist, are retained, and can be produced.
- Segmentation. Keeping any cardholder data environment separated from everything else, so a compromise elsewhere does not reach it.
Everything else — your written policies, staff training, physical security at your premises, your vendor management — stays with you no matter how good the hosting is.
The easier path: never touch the card number
The most effective way to reduce PCI scope is to arrange things so cardholder data never reaches your infrastructure. Every system that touches a card number falls into scope. Remove your server from that path and you remove most of the burden with it.
Two standard approaches do this:
- A hosted payment page. The customer is redirected to the payment provider to enter their card details, then returned to you. Your server sees a result, never a card number.
- Tokenisation with an embedded field. The card details go directly from the customer’s browser to the payment provider, which returns a token — a reference you can store and charge against safely. The checkout still looks like part of your site.
Either way you are still responsible for the integrity of the page that collects the details, which is why the hosting controls above still matter. But you are no longer storing, and mostly no longer transmitting, the data that makes PCI expensive.
The corollary is worth stating plainly: do not store card numbers yourself. Not in your database, not in an order export, not in an email confirmation, not in a support ticket. Storing card data is the single decision that turns a modest compliance obligation into a large one.
What to ask about PCI compliant hosting before you sign
- Is the environment dedicated or shared? Shared infrastructure complicates segmentation arguments considerably.
- How are TLS configuration and cipher suites managed, and who keeps them current?
- What is the patching schedule, and can I get evidence of it?
- Is multifactor authentication enforced on all administrative access?
- What logs are kept, for how long, and can I retrieve them?
- Will you document which PCI responsibilities are yours and which are mine? A clear responsibility matrix saves a great deal of argument during an assessment.
That last question is the one that separates hosts who understand compliance from hosts who have simply written “PCI compliant” on a feature list.
How LiberationTek handles PCI compliant hosting for payment environments
Our e-commerce development and payment processing work is built around keeping card data off your infrastructure wherever possible, using tokenised payment flows rather than storing card numbers.
On the hosting side, our managed environments run on U.S.-owned hardware that we operate ourselves, with OS patching, monitoring, encrypted backups and multifactor authentication handled as standard rather than sold as add-ons. For merchants who also handle health data — a billing page attached to a clinic, for instance — the same environment supports our healthcare requirements, including a signed Business Associate Agreement.
If you are not sure which parts of the standard currently sit with you, book a consultation and we will map it out, including the parts where the honest answer is that you need a QSA rather than a host.
What happens if you are breached and non-compliant?
The costs are commercial and they arrive quickly. Because PCI DSS is enforced contractually rather than by statute, the consequences flow through your acquirer rather than a regulator.
In a card-data breach a merchant typically faces a forensic investigation it must pay for, fines passed down from the card brands through the acquirer, the cost of reissuing affected cards, and higher transaction rates afterwards. In serious cases the merchant account is terminated, which for an online business is an existential outcome rather than a financial one.
The distinction that matters: being compliant at the time of a breach does not eliminate these costs, but being demonstrably non-compliant removes most of your defenses. This is why the evidence trail — patch records, log retention, access reviews — matters as much as the controls themselves.
What if you handle both card data and health data?
You are subject to both standards, and they overlap less than you would hope. A clinic with an online billing page, a dental practice taking deposits, a therapist with a booking system — all of these sit under HIPAA for patient information and PCI DSS for card details.
The good news is that the technical controls largely coincide. Encryption in transit, access control with unique accounts, multifactor authentication, patching, logging and segmentation appear in both. Implement them once and you have satisfied a large part of each.
The divergence is in the paperwork and the scope. HIPAA wants a risk analysis, a Business Associate Agreement with every vendor touching PHI, and workforce training. PCI wants a defined cardholder data environment, an annual assessment appropriate to your merchant level, and evidence that controls operate continuously. Neither accepts the other as a substitute.
The practical route is the same in both cases: shrink what is in scope. Keep card numbers off your systems with tokenisation, and keep PHI out of email by moving those exchanges into a portal. See our guide to HIPAA compliant hosting for the health-data half.
What PCI compliant hosting cannot do for you
The phrase does a lot of work in hosting marketing, and it is worth being precise about its limits, because a merchant who believes the host has handled compliance is a merchant in for an unpleasant surprise.
No host can make you compliant. PCI DSS applies to the merchant. A host can supply infrastructure that meets its share of the requirements and can provide documentation showing which controls it covers, but the obligation, the questionnaire and the attestation remain yours. PCI compliant hosting is a component of compliance, never a substitute for it.
There is no PCI certificate for a hosting plan. Service providers can undergo assessment and appear on the card brands’ lists, which is meaningful. A shared hosting plan advertised as “PCI certified” with nothing behind it is marketing. Ask what specifically was assessed, by whom, and when.
Your application is still yours. An out-of-date plugin, a vulnerable theme or a compromised admin account will expose a checkout regardless of how well the server is configured. Skimming attacks overwhelmingly target the application layer and injected scripts rather than the infrastructure, which is why v4.x pays particular attention to what runs on the payment page.
Third-party scripts are in scope. Analytics, chat widgets, ad pixels and tag managers loading on a checkout page are exactly what the newer requirements address. PCI compliant hosting does nothing about a marketing script somebody added last month.
Your staff and processes are in scope too. Card numbers read over the phone and written on a pad, emailed order forms, or a shared admin login are all failures no server configuration prevents. The PCI Security Standards Council document library publishes the self-assessment questionnaires free, and reading the one that applies to you is the fastest way to see what is genuinely being asked.
What good PCI compliant hosting does do. It removes an entire category of problem from your list, gives you documentation you can attach to your own assessment, and means the infrastructure answers are already written when you fill in the questionnaire. That is worth paying for. It is simply not the same thing as being compliant.
Frequently asked questions
Is PCI DSS a law?
No. It is a contractual standard from the PCI Security Standards Council, enforced through your agreements with card brands and your payment processor. Penalties are commercial rather than criminal.
What version of PCI DSS is current?
PCI DSS v4.0 and v4.0.1, referred to together as v4.x. Version 3.2.1 was retired on 31 March 2024, and the 51 future-dated requirements introduced in v4.0 became effective on 31 March 2025.
Can a hosting provider make me PCI compliant?
No. A host can meet the infrastructure portion — encryption, patching, access control, logging, segmentation — but policies, training, physical security and vendor management remain yours.
How do I reduce my PCI scope?
Keep cardholder data off your systems entirely by using a hosted payment page or tokenisation, and never store card numbers in your database, exports, emails or support tickets.
Do I need PCI compliance if I use a payment gateway?
Yes, but far less of it. Using a gateway properly reduces which requirements apply; it does not remove the obligation, and you remain responsible for the security of the page that collects the details.
This article is general information, not legal or assessment advice. Your PCI obligations depend on how you handle cardholder data; consult your acquirer or a Qualified Security Assessor.
Related reading
- SSL Certificates — The baseline every public-facing site is expected to have.
- How to Protect Your Business Online — The controls that apply whatever the regime.