What PCI-compliant Hosting Covers and Where You're Exposed

PCI-compliant hosting is web hosting infrastructure that operates within a scope assessed against the Payment Card Industry Data Security Standard (PCI DSS). That means the provider has implemented and validated specific security controls across the infrastructure and services included in its assessment, such as network security, access management, encryption, monitoring, and physical security.

However, not every website running on that infrastructure automatically becomes PCI-compliant. PCI DSS follows a shared-responsibility model, so the provider's assessment covers only part of the environment while the organization remains accountable for the controls and systems it manages.

That’s why evaluating PCI-compliant hosting involves understanding the boundary between those two responsibilities. Two providers can both support PCI requirements while giving your team very different levels of operational control, security tooling, and ongoing responsibility.

This guide explains what exactly PCI-compliant hosting covers, where exposure can remain, when you may not need specialized PCI hosting at all and more.

What does PCI-compliant hosting actually cover and what are you still responsible for?

PCI-compliant hosting covers the infrastructure and services that fall within the hosting provider’s assessed PCI DSS scope. Exactly what that includes varies by provider and service, so a PCI-compliant designation should never be interpreted as blanket coverage for everything running on the platform. 

PCI SSC requires service providers to identify which PCI DSS requirements they fulfill for customers and which remain the customer’s responsibility.

A typical responsibility split may look like this:

These are examples, not a universal PCI responsibility map. An individual PCI DSS requirement can contain provider-controlled, customer-controlled, and shared components. A managed platform may patch its operating systems, for example, while leaving CMS extensions and custom application code to the customer.

This is also why outsourcing infrastructure does not outsource PCI accountability. Requirement 12.8 requires organizations to perform due diligence on applicable third-party service providers, maintain appropriate agreements, understand the responsibility split, and monitor provider compliance status at least annually.

Do you need PCI-compliant hosting if you use Stripe, PayPal, or another payment provider?

Not necessarily—using Stripe, PayPal or another PCI-compliant payment provider can significantly reduce your PCI DSS scope, but it does not remove your PCI responsibilities or automatically eliminate hosting-related requirements. Whether you need specialized PCI hosting depends largely on how your website handles the payment flow.

The key concept is self-assessment questionnaire A (SAQ A), which is the reduced-scope PCI DSS validation questionnaire intended for eligible merchants that outsource payment processing to PCI DSS-compliant third parties and do not electronically store, process, or transmit cardholder data on their own systems. Eligibility still depends on meeting all SAQ A criteria and on the validation requirements set by your acquirer or payment brand.

Your payment architecture determines how much remains in scope:

• Redirected checkout: If your site sends customers to a provider-hosted payment page, you may qualify for SAQ A.
• Provider-hosted iframe: You may also qualify for SAQ A when every element that collects or processes payment data originates directly from PCI DSS-compliant service providers. For e-commerce sites using embedded payment forms, SAQ A also requires the merchant to confirm that its site is not susceptible to script attacks that could affect the payment system.
• Merchant-generated payment page: If your website generates elements that collect payment data and sends that data directly to the processor, the implementation may instead qualify for SAQ A-EP, which has broader requirements.
• Card data reaches your own systems: Your PCI scope expands substantially.

Even SAQ A does not mean your website is outside PCI DSS. Applicable e-commerce merchants must still have quarterly external vulnerability scans performed by a PCI SSC Approved Scanning Vendor (ASV), including sites that redirect to a payment provider or embed its iframe.

So, outsourcing payments can reduce the need for infrastructure designed to handle cardholder data directly, but your hosting still needs to support the PCI controls that remain in your scope.

Which hosting architecture is best for PCI compliance: shared, VPS, dedicated, or containers?

PCI DSS does not require a specific hosting architecture—shared, VPS, dedicated, and container-based environments can all support PCI-compliant workloads if the applicable security, isolation, access, and operational controls are implemented correctly and included in the provider’s assessed scope.

The main difference is how isolation is achieved and who is responsible for securing each layer:

• Shared hosting places multiple customers on shared infrastructure and often gives customers relatively little control over the underlying environment. It is not automatically noncompliant, but the provider must be able to demonstrate appropriate separation between customer environments.
• VPS hosting gives each customer a logically isolated virtual machine with its own operating system. The physical host and hypervisor remain shared, while responsibility for the guest OS depends on whether the VPS is managed or self-managed.
• Dedicated hosting assigns the physical server to one customer. That removes cross-customer tenancy at the server level and can simplify some isolation and scoping decisions, but the server, application, and payment architecture still have to meet all applicable PCI DSS requirements.
• Container-based hosting isolates workloads using operating-system-level mechanisms such as namespaces and resource controls rather than a separate guest OS for each workload. Its PCI suitability depends on how that isolation, the underlying host and the surrounding platform are secured and assessed.

What changes between these models is how customer isolation is achieved and how much of the underlying stack the provider versus the customer has to secure. That is especially important for shared and other multi-tenant environments. PCI DSS does not prohibit multi-tenant hosting. Instead, Appendix A1 adds requirements for applicable service providers that host multiple customers on shared infrastructure. Those providers must enforce separation between customer environments so one tenant cannot access another tenant’s systems, data, or allocated resources.

What does PCI DSS 4.0.1 mean for website hosting now?

PCI DSS 4.0.1 is the current version of the standard, and all applicable future-dated requirements introduced with PCI DSS 4.x have been mandatory since March 31, 2025. PCI DSS 4.0.1 itself did not add new requirements—it is a limited revision of PCI DSS 4.0 that clarifies existing requirements and guidance.

For hosting and web teams, the most relevant areas are:

• Multi-factor authentication: Requirement 8.4.2 requires MFA for all access into the cardholder data environment (CDE). It does not automatically apply to every in-scope system outside the CDE, unless access to that system can be used to connect into the CDE.
• Authenticated vulnerability scanning: Requirement 11.3.1.2 requires authenticated internal vulnerability scans for systems that can accept scanning credentials, giving teams a deeper view than unauthenticated scanning alone.
• Payment-page script security: Requirements 6.4.3 and 11.6.1 address e-skimming risks by requiring controls around the authorization, integrity, and monitoring of scripts and changes that can affect payment pages.
• SAQ A update: The current SAQ A removed 6.4.3 and 11.6.1 from that questionnaire, but added an eligibility criterion requiring applicable merchants to confirm that their site is not susceptible to script attacks that could affect their e-commerce systems. The underlying PCI DSS requirements themselves were not removed.

For hosting buyers, the takeaway is that PCI DSS 4.x puts more emphasis on proving how access, vulnerabilities, and web-layer risks are controlled, not simply showing that the underlying server is secure.

How can you verify that a hosting provider is PCI-compliant?

The best way to verify a PCI-compliant hosting provider is to review its PCI DSS Attestation of Compliance (AOC) and confirm that the specific hosting service you plan to use is included in the assessed scope. An AOC summarizes the results of a PCI DSS assessment, but simply possessing one does not mean every service the provider offers is covered.

When evaluating a host:

• Ask for the Service Provider AOC: A hosting company should provide evidence appropriate to its role as a service provider, not rely on a merchant AOC or a marketing badge. PCI SSC expects assessed third-party service providers to provide their AOC to customers on request.
• Confirm what services were assessed: The AOC should identify the services covered by the assessment. Make sure the hosting product, platform or infrastructure you intend to use falls within that scope.
• Check the assessment date and compliance status: Organizations must monitor applicable service providers' PCI DSS compliance status at least annually. Whether particular evidence remains acceptable for your validation should ultimately be confirmed with your assessor, acquirer or other compliance-accepting entity.
• Request the responsibility breakdown: Establish which PCI DSS requirements the provider performs, which remain yours and which are shared. PCI DSS requires applicable service providers to provide this information to customers on request. A responsibility matrix is one useful way to document it.
• Verify the controls that matter to your architecture: Ask specifically about tenant isolation, access controls, MFA, patching, encryption, logging, vulnerability management, and who is responsible for your application-level security and required scans.

Be wary of a provider that offers only a “PCI certificate” or PCI-compliant badge. PCI SSC does not recognize vendor-created compliance certificates as PCI DSS validation evidence. Official PCI SSC reporting documents, including AOCs, ROCs, and SAQs, are the recognized forms.

Is a passing PCI scan the same as PCI-compliant hosting?

No, a passing PCI vulnerability scan tests a defined set of externally visible security conditions, while PCI-compliant hosting concerns the broader controls and infrastructure included within the provider's assessed scope. Neither, by itself, proves that your entire website or organization is PCI-compliant.

An ASV scan does not assess the rest of your PCI responsibilities, such as:

• Whether your PCI scope is correct.
• How hosting tenants or workloads are isolated.
• Whether users have appropriate access.
• Whether your WordPress or Drupal application and custom code are secure.
• Whether payment-page scripts are properly controlled.
• Whether logging, monitoring and incident-response processes meet applicable requirements.
• Whether third-party providers are appropriately managed.
• Whether all required PCI policies and documentation are in place.

That makes scanning and PCI-compliant hosting two different pieces of the compliance picture.

Three operating models for PCI-compliant hosting

The right PCI hosting model depends on how much infrastructure and operational responsibility you want your own team to retain. These are not formal PCI SSC categories, but they are a useful way to compare how hosting providers divide responsibility in practice.

There are three common operating models:

• Self-managed cloud infrastructure: You provision services directly from a cloud provider such as AWS, Microsoft Azure, or Google Cloud and design the environment yourself. The cloud provider may have its own PCI DSS validation for applicable services, but your team remains responsible for configuring the architecture correctly, including areas such as network segmentation, operating-system security, patching, logging, and access controls where those layers are customer-managed.
• Managed PCI hosting: The provider manages more of the underlying infrastructure and can supply PCI DSS evidence for the services within its assessed scope. Depending on the provider and plan, it may also manage areas such as operating systems, patching, firewalls, monitoring, or vulnerability management. The exact responsibility split still has to be verified rather than assumed.
• Managed WebOps platform such as Pantheon: The provider combines managed infrastructure with the tooling used to build, deploy, and operate websites, such as controlled deployment workflows, environment management, access controls, monitoring, and automated maintenance capabilities. This can shift additional day-to-day operational work away from individual web teams.

This comparison matters because two providers can both offer infrastructure covered by a PCI assessment while leaving customers with very different amounts of operational work.

How does Pantheon support PCI compliance for WordPress and Drupal?

Pantheon is a PCI DSS 4.0.1 Level 2 Service Provider that supports PCI-sensitive WordPress, Drupal and Next.js sites through a shared-responsibility model where Pantheon secures the underlying platform, while customers remain responsible for validating their applications and meeting the PCI DSS requirements that remain within their scope.

Additionally, Pantheon provides several controls that can support that shared-responsibility strategy:

• Container-based isolation: Each site runs in isolated containers, limiting interaction between workloads and reducing the infrastructure customers have to manage themselves.
• Managed encryption: Pantheon supports TLS 1.2 and 1.3 and manages TLS certificates for sites.
• Identity and access controls: SAML/SSO, MFA and role-based permissions help organizations control who can access the platform and deploy changes.
• Controlled deployments: Code is version-controlled with Git and cannot be changed directly in Test or Live environments, creating a more governed production workflow.
• Platform-level protection: Pantheon provides infrastructure monitoring, DDoS protection, and other centrally managed security controls rather than requiring each web team to build the underlying platform security itself.

Customers still need to secure their application and payment implementation, determine their PCI scope and complete the appropriate validation. That includes arranging required quarterly ASV scans for their own site URLs, which Pantheon does not perform as part of its platform attestation.

The advantage is a clearer division of labor—Pantheon manages more of the infrastructure underneath the site, leaving your team to focus on the application-level PCI responsibilities that cannot be outsourced.

Reduce your PCI exposure with the right hosting foundation

PCI-compliant hosting does not remove your PCI obligations. It reduces the amount of infrastructure your team has to secure itself and gives you a clearer, auditable boundary between provider-managed and customer-managed controls.

That makes the hosting decision less about finding a provider that claims to “handle PCI” and more about choosing one that can prove what it secures, document where its responsibility ends and give your team the controls needed to protect everything that remains in scope.

For organizations running WordPress, Drupa,l and Next.js at scale, Pantheon combines a PCI DSS 4.0.1 Level 2 Service Provider posture with managed infrastructure, workload isolation, access controls and governed deployment workflows.

Start with Pantheon today and build on infrastructure that helps reduce PCI exposure without blurring your responsibilities!