PCI-Compliant Hosting: Requirements and Checklist

PCI-compliant hosting is hosting infrastructure whose assessed services and security controls can support a merchant or service provider working towards PCI DSS compliance. It may cover the data centre, hardware, hypervisor, network and selected managed services. It does not make the customer’s website, application or payment process compliant automatically.

That distinction changes how a provider should be selected. A long security-feature list is less useful than three precise answers: What did the provider have assessed? Which of those services will we actually use? Who owns every control that remains?

PrivaLex approaches PCI hosting as a provider-assurance and architecture decision. The objective is not to find a server carrying a PCI label. It is to build a payment environment in which the provider’s validated controls and the customer’s controls meet without an unassigned gap.

PCI-compliant hosting in one minute

The current standard is PCI DSS v4.0.1, available through the official PCI Security Standards Council document library. It establishes technical and operational requirements for protecting payment account data.

A hosting service becomes relevant when it stores, processes or transmits account data, provides controls used to meet PCI DSS, or can affect the security of the cardholder data environment.

The provider may take responsibility for physical security, platform isolation or a managed firewall. The customer may still be responsible for:

• Payment-page code and third-party scripts.
• Application vulnerabilities and secure software releases.
• Cloud security groups and tenant configuration.
• User accounts, privileged access and multi-factor authentication.
• Log selection, alert handling and retention.
• Vulnerability remediation and penetration testing.
• Incident decisions, notifications and forensic coordination.
• PCI DSS validation through the route required by its acquirer or payment brand.

The phrase PCI-ready has no value without scope and evidence. It may describe useful technical features, but it does not tell us whether an independent assessment covered the service being sold.

First identify your payment model

The hosting question cannot be answered before the payment journey is mapped. Two merchants using the same cloud provider may have completely different exposure because their checkout implementations differ.

Redirect to a provider-hosted page: The customer leaves the merchant site to enter payment details. Merchant scope may be smaller, but the website initiating the redirect and the oversight of the payment provider still matter.

Embedded provider form or iframe: Payment fields are supplied by a third party inside the merchant experience. The surrounding page can still influence payment security through scripts, compromised content or unauthorised changes.

Direct API or application processing: Card data passes through merchant-controlled application components. Application security, hosting configuration, access, logging and technical testing therefore become central to the environment.

Stored account data: The business retains permitted cardholder data for a defined purpose. Storage, retention, encryption, key access, backups and verified deletion all require close analysis.

Before buying specialised hosting, ask whether the architecture can remove card data instead. A processor-hosted page, tokenisation or redesign of an integration may reduce scope more effectively than adding controls to a large environment.

Outsourcing does not remove the merchant’s PCI DSS responsibilities. PCI SSC explains that an outsourcing merchant still has to ensure the provider is compliant for the services offered, maintain written responsibility agreements, monitor provider status and understand shared responsibilities.

The Council’s outsourced payment-processing guidance also advises merchants to confirm their validation obligations with the relevant acquirer or payment brand.

Ignore the badge and inspect the evidence pack

The decisive question is not whether the provider’s website says “PCI compliant”. It is whether the provider can supply documents that apply to the contracted service.

The Attestation of Compliance

Request the provider’s current service-provider Attestation of Compliance, or AOC. Review the assessed entity, validation date, service description, locations, exclusions and result.

An AOC for one corporate entity does not necessarily cover every subsidiary. An assessed cloud platform does not necessarily include managed operating systems, backups, content delivery, support administration or a separate region sold under the same brand.

Record the AOC’s assessment anniversary. A document that was valid during procurement may no longer provide current assurance by the time the customer’s own assessment begins.

The service description

Match the AOC against the order form and technical design. Product naming is often the point where assurance breaks down. The contract may refer to a premium managed bundle while the AOC describes only the underlying infrastructure.

• Create a short reconciliation showing:
• Contracted product and service tier.
• Hosting region and physical locations.
• Managed components included in the order.
• Subcontractors used to deliver those components.
• Corresponding language in the AOC.
• Unresolved differences requiring written confirmation.

The responsibility matrix

The provider should state which PCI DSS requirements it performs, which are shared and which remain with the customer. The matrix must be service-specific and usable by control owners.

PrivaLex tests these matrices by asking for the evidence behind a sample of provider and customer responsibilities. This is similar to documenting security controls so they hold up in audit: a control statement is only useful when it points to a real system, owner and record.

Build the responsibility map before comparing providers

A practical responsibility map should go beyond “provider” and “customer”. It should explain what each party does and what the customer can retain as evidence.

• Physical security. The provider may operate facility access, surveillance and equipment protection. The customer still needs to confirm that the contracted facility appears within the assessed scope and retain the relevant AOC.
• Network protection. The provider may secure the platform perimeter or supply managed firewall and isolation features. The customer must configure tenant rules, document payment flows and retain approved rule changes and reviews.
• System hardening. The provider may harden the hypervisor or a managed operating system. The customer remains responsible for unmanaged systems, applications and unnecessary services, supported by a configuration baseline and review results.
• Identity and administrative access. The platform may supply IAM capabilities and provider workforce controls. The customer must enforce individual accounts, MFA, least privilege and periodic reviews while retaining access lists and approvals.
• Encryption and keys. The provider may offer encryption and managed key services. The customer decides what data is covered, who can use the keys and how rotation, backups and replicas are handled.
• Logging and monitoring. The provider may generate or store platform logs. The customer chooses relevant sources, retention and alert handling, then retains evidence of investigations and response decisions.
• Vulnerability management. The provider may patch the platform and support scanning. The customer must remediate application and customer-managed findings and document any time-limited exception.
• Incident response. The provider investigates its environment and notifies the customer under the contract. The customer activates its own plan, preserves evidence and coordinates with assessors, acquirers and other payment parties.

No responsibility should remain simply marked “shared”. Shared must be decomposed into the provider action, customer action and handoff evidence.

Compare hosting models by responsibility, not prestige

Dedicated infrastructure is not automatically more compliant than cloud hosting. Greater control can also create greater operational responsibility.

Shared hosting may work for a low-complexity environment when the provider can demonstrate effective tenant isolation and supply usable evidence. The decisive question is whether the provider can prove separation and satisfy the PCI DSS expectations applicable to its service model.

A managed VPS can provide isolation without making the customer operate every system layer. The contract must still identify exactly where management stops and who patches the application, dependencies and unsupported components.

Dedicated or bare-metal hosting provides strong isolation and architectural control. It also gives the customer more to harden, monitor, patch and recover. Choose it only when the organisation can operate those responsibilities consistently.

Public cloud can support scalable security services and automation. Its main risk is not the cloud model itself, but unclear managed-service boundaries and customer configuration that drifts after deployment.

A managed private cloud can suit complex environments needing tailored support. Bespoke does not mean assessed, so each service, location and administrative function still needs to be reconciled with the AOC.

The correct option depends on the payment model, internal engineering capacity, required evidence and total cost of operating customer-side controls.

Use consistent provider questions during procurement

Provider comparisons often fail because one quote includes managed security while another prices only infrastructure. Asking every provider the same questions exposes those differences.

• Can you show where this exact product, region and service tier appear in the AOC?
• Do you provide a requirement-level responsibility matrix for this service?
• How is customer separation implemented and tested?
• When can support personnel access the environment, and how is that access approved and logged?
• Which system layers and products do you patch, and to what service level?
• Which logs can we export, and how long are they retained?
• Can ASV scans, penetration tests and segmentation tests be performed without contractual obstacles?
• What incident notice, evidence and forensic assistance will you provide?
• Which subcontractors and locations support the service, and how will changes be communicated?
• How will account data, snapshots, backups and keys be returned or destroyed at exit?

Treat vague language as a finding. “We handle the infrastructure”, “fully managed” and “commercially reasonable assistance” do not establish a boundary. Ask the provider to name the component, action, evidence and timing.

Evidence quality should also affect the evaluation. “Yes” supported by the AOC and contract is stronger than “yes” stated during a sales call.

Put the important assurances into the contract

Provider documents describe current status. The contract determines what happens when that status or service changes.

Relevant provisions may include:

• Acknowledgement of the provider’s PCI DSS responsibilities.
• Delivery of a current AOC and responsibility matrix.
• Annual notification or evidence of renewed compliance status.
• Notice of material scope, region, subcontractor or service changes.
• Security-incident notification timing and minimum information.
• Access to logs, reports and other evidence needed for validation.
• Cooperation with the customer’s assessor, acquirer or forensic investigator.
• Remediation expectations when provider controls fail.
• Secure return, deletion and confirmation at contract termination.

The contract should not promise that the provider will “make the customer PCI compliant”. It should define the controls and evidence the provider is committing to deliver.

Treat go-live as an assurance handoff

Procurement is complete only when the evidence and responsibilities have reached the teams that will operate them.

Before the contract is signed

Complete the payment-flow map, reconcile the AOC with the proposed service and identify customer-owned controls. Escalate any ambiguity that could materially change scope, cost or validation.

Before production traffic begins

Harden the customer-managed layers, configure MFA and least privilege, test logging, confirm scan targets and validate segmentation assumptions. Update the system inventory and data-flow diagram to match the deployed environment rather than the design proposal.

Where sensitive cloud data and unmanaged assets are difficult to locate, PrivaLex’s cloud data security platform can provide additional visibility. It does not replace PCI DSS assessment, but it can help teams find exposure that a static diagram misses.

Once the service is live

Place provider assurance on the operating calendar. Track the AOC anniversary, access reviews, scan results, vulnerabilities, script changes, incidents and contractual notifications.

Automation can collect evidence and flag configuration drift, but it needs an agreed control owner and escalation path. Regulatory compliance automation briefly explains why connecting tools before defining the control model simply digitises uncertainty.

Understand what drives the real cost

The monthly server price is only one part of PCI-compliant hosting. Compare total operating cost across the same responsibility boundary.

The main cost drivers are:

• Managed versus unmanaged layers. Unmanaged systems require internal hardening, patching, monitoring and evidence.
• Isolation model. Dedicated networks, hosts or private environments may increase infrastructure cost.
• Logging and retention. Central monitoring, export and longer retention can be priced separately.
• Vulnerability services. ASV scans, internal scanning, penetration testing and remediation support may not be included.
• Availability and recovery. Replicas, encrypted backups, recovery exercises and secondary regions add controls and cost.
• Evidence and assessor support. Document preparation and technical participation may be a separate service tier.
• Migration and exit. Secure data transfer, parallel operation and verified deletion can require project work.

Ask each provider to price the same target design and list exclusions. A cheaper infrastructure quote can become the most expensive option when the customer has to supply several missing controls.

10 Warning signs in a PCI hosting proposal

Pause the procurement process if:

• The provider will not share an AOC or explain an alternative assessment route.
• The AOC cannot be matched to the exact service or region.
• PCI-ready and PCI compliant are used interchangeably.
• The responsibility matrix contains large “shared” areas without tasks.
• Managed-service boundaries are not reflected in the contract.
• The provider cannot explain administrative access or log availability.
• Security testing is restricted without a workable coordination process.
• Incident assistance is described only as commercially reasonable.
• There is no process for notifying customers about compliance-status changes.
• Exit terms say nothing about backups, keys and deletion evidence.

These signs do not always disqualify a provider, but each creates uncertainty that must be resolved before reliance.

What a PrivaLex PCI hosting review delivers

A PrivaLex PCI hosting review is designed around a specific provider decision, migration or validation problem. It does not reproduce the organisation’s full PCI DSS programme in a generic maturity report.

Payment-path boundary map: The team can see which merchant pages, applications, integrations and hosting services can affect account data.

AOC-to-contract reconciliation: Services, regions or managed components that the provider’s current assurance does not clearly cover are identified before reliance.

Executable responsibility matrix: Each customer-owned activity receives a named operator, evidence source and timing instead of remaining in a broad shared category.

Quote-normalisation sheet: Providers can be compared against the same technical and assurance boundary instead of headline server prices.

Remediation and validation pack: Priority gaps are organised around the agreed SAQ, assessor or customer-review route so the team knows what must be resolved before validation.

PrivaLex can also join provider calls to test unclear claims against the architecture and documents. Where a formal assessment is required, the acquirer, payment brand, Qualified Security Assessor or other authorised PCI professional retains responsibility for the validation route and independent conclusion.

This review is particularly useful for ecommerce businesses changing checkout design, SaaS providers entering payment flows, platforms replacing a cloud provider and organisations whose existing host can no longer demonstrate that the deployed service sits inside its assessed scope.

Conclusion

The hosting decision should end with three documents that agree: the payment-flow map, the provider’s current assurance scope and the customer responsibility matrix. If a service appears in the architecture but not in the AOC, or a requirement appears in the matrix without an owner, the environment is not ready to rely on.

PCI-compliant hosting supports validation when provider and customer controls cover the complete payment path, remain testable after service changes and produce evidence at the required frequency. That is a stronger purchasing standard than selecting the provider with the longest feature list or the most prominent compliance badge.

If you want to test whether a current or proposed hosting model can support your PCI DSS obligations, request your free risk assessment or book a provider-review session with our team.

Frequently Asked Questions (FAQs)