PCI DSS Compliant Hosting: What It Actually Requires

Any business that accepts, processes, stores, or transmits payment card data needs PCI DSS compliant hosting to meet the Payment Card Industry Data Security Standard. Specifically, this standard applies without exception to every business handling cards. In short, this is not optional. Card brands including Visa, Mastercard, and American Express require it as a condition of accepting card payments. Consequently, non-compliance results in increased transaction fees, potential fines, and in the event of a breach, direct liability for fraudulent charges.

PCI DSS infrastructure requirements are, at their core, an infrastructure question. According to the PCI Security Standards Council, the standard applies to every entity involved in payment card processing. This includes merchants, processors, acquirers, issuers, and service providers alike. Its controls, however, all depend on what your hosting environment allows you to implement. Specifically, these include network isolation, firewall configuration, system hardening, encryption, and audit logging. Shared hosting cannot meet these requirements. Dedicated servers are architecturally aligned with them.

This guide explains what PCI-DSS actually requires at the infrastructure level, and how dedicated server infrastructure supports each requirement category.

---

What PCI-DSS Actually Requires From Your Infrastructure

PCI-DSS version 4.0, the current standard, organises its requirements into twelve domains. Several of these domains have direct infrastructure implications. They determine whether shared hosting, VPS, or dedicated servers are the appropriate hosting model.

Requirements Affecting Network and System Configuration

The most infrastructure-relevant requirements are:

Requirement 1 – Install and maintain network security controls. PCI-DSS requires that network security controls protect the Cardholder Data Environment (CDE) from untrusted networks. Firewall rules must be documented, reviewed regularly, and enforced with technical controls. However, on shared hosting, you have no firewall control. On a dedicated server, you implement and own the full firewall configuration.

Requirement 2 – Apply secure configurations to all system components. Default configurations must be changed and unnecessary services disabled. All system components must be hardened before deployment in the CDE. On shared hosting, the provider controls the OS configuration entirely. On a dedicated server, you control every installed service and every configuration parameter.

Requirements Affecting Data Protection and Access

Requirement 3 – Protect stored account data. Cardholder data stored in databases or files must be encrypted. In practice, on dedicated infrastructure, you implement full-disk encryption and database-level encryption with complete control over key management.

Requirement 4 – Protect cardholder data with strong cryptography during transmission. All transmission of cardholder data over open networks must use strong cryptography: TLS 1.2 or higher. On a dedicated server, you configure TLS entirely, enforcing specific protocol versions and cipher suites.

Requirements Affecting Logging and Patch Management

Requirement 6: Develop and maintain secure systems and software. Security vulnerabilities must be patched within defined timeframes. On shared hosting, patching depends on the provider’s schedule. By contrast, on a dedicated server, you apply patches on your own schedule within PCI-DSS requirements.

Requirement 7: Restrict access to system components by business need. Role-based access control must ensure only authorised personnel can access CDE components. Accordingly, on a dedicated server, you implement OS-level user management, database permission models, and SSH access controls without platform constraints.

Requirement 10: Log and monitor all access to system components and cardholder data. Comprehensive logging of every access event must be maintained for audit purposes. On a dedicated server, therefore, you configure logging at the OS, application, and database level, with full control over retention and access policies.

---

Why Shared Hosting Cannot Meet PCI DSS Infrastructure Requirements

Shared hosting is structurally incompatible with PCI-DSS compliance for cardholder data environments. Specifically, the reasons are architectural, not configurational.

Network isolation is impossible. In particular, PCI-DSS requires that the CDE is isolated from other systems. On shared hosting, your application shares a network segment with hundreds of other customers, with no firewall between your site and the others on the same server. This violates the network segmentation requirements at the foundation of PCI-DSS.

System configuration is the provider’s responsibility. PCI-DSS requires that you can document and verify the security configuration of every system component in scope. Consequently, on shared hosting, you cannot verify the OS configuration, the installed services, or the patch level.

Logging is limited or inaccessible. PCI-DSS requires detailed logs of all access events. Similarly, on shared hosting, access to OS-level logs, complete web server logs, and database access logs is typically restricted, and a PCI-DSS auditor cannot verify compliance without access to these logs.

Multi-tenant exposure exists. PCI-DSS requires that the CDE is isolated from other environments. Shared hosting is definitionally multi-tenant, physical hardware is shared between all customers, creating a cross-tenant attack surface that PCI-DSS is specifically designed to eliminate.

---

How Dedicated Servers Support Each PCI-DSS Requirement Category

Network Security Controls (Requirement 1)

PCI-DSS requires that network security controls protect the CDE from untrusted networks and that all rules are documented and reviewed at least every six months.

On a dedicated server, you implement the firewall configuration entirely. For example, using UFW or iptables on Linux, you create specific allow rules for each service: SSH on a non-standard port with source IP restrictions, HTTPS on port 443, database access restricted to the application server’s internal IP only, with a default-deny policy blocking everything else.

Dedicated infrastructure also allows network segmentation between server tiers. By deploying your web server, application server, and database server on separate dedicated machines connected through a private network, you create the physical network segmentation that PCI-DSS assessors consider the strongest form of CDE isolation.

In a single-server deployment, you achieve logical segmentation through firewall rules that restrict database access to localhost only, preventing the database from being reachable from any external network regardless of application-level vulnerabilities.

System Hardening (Requirement 2)

PCI-DSS requires the removal of all default accounts, unnecessary services, and unused system components from CDE systems.

On a dedicated server, consequently, you control the complete software installation. After provisioning, you remove all packages not required for your application, disable all services not needed for the application stack, change or disable default database accounts, configure the web server with only the modules required, and remove any graphical environment or management tools not needed in production.

As a result, each of these steps reduces the attack surface, and the list of system components within PCI-DSS scope shortens, which in turn directly reduces audit complexity.

Encryption Implementation (Requirements 3 and 4)

PCI-DSS requires encryption of stored cardholder data and encryption of all data in transit over public networks. On a dedicated server, you implement encryption at every relevant layer:

Full-disk encryption – Using LUKS on Linux, the entire storage volume is encrypted at rest. If the physical drives are ever removed from the datacenter, the data is unreadable without the encryption key.

Database encryption – MySQL and PostgreSQL both support transparent data encryption (TDE) for encrypting database files at rest, combined with encrypted database connections to protect cardholder data both on disk and in transit.

TLS configuration – You configure TLS entirely on a dedicated server. For PCI-DSS 4.0 compliance, TLS 1.2 is the minimum; TLS 1.3 is preferred. You can disable TLS 1.0 and 1.1, which PCI-DSS explicitly prohibits for new implementations, and enforce specific cipher suites that meet PCI-DSS cryptographic requirements.

Certificate management – You control SSL certificate installation, renewal, and OCSP stapling configuration without dependency on a provider’s platform.

Access Control (Requirements 7 and 8)

PCI-DSS requires that access to system components is restricted to individuals whose job requires it, and that all access is authenticated and logged. On a dedicated server, therefore, you implement the complete access control stack:

OS-level user management: Each individual who requires server access receives their own OS user account with the minimum permissions required for their role. Indeed, shared accounts are prohibited by PCI-DSS.

SSH key authentication: Notably, password-based SSH is disabled, and each administrator’s SSH public key is installed individually, creating a direct audit trail mapping every SSH session to a specific individual.

Database access controls: Likewise, database users are created with the minimum permissions required for each application component, application database users cannot read the system tables, and administrative database access is restricted to specific hosts.

Role-based access control: Similarly, sudo privileges are granted only to users who require elevated access for specific functions, and those privileges are documented and reviewed regularly.

Multi-factor authentication: PCI-DSS 4.0 requires MFA for all access to the CDE. Consequently, on a dedicated server, you implement MFA for SSH using TOTP combined with SSH key authentication.

Logging and Monitoring (Requirement 10)

PCI-DSS requires that all access to network resources and cardholder data is logged, that logs are protected against modification, and that logs are reviewed regularly for anomalies. Given this requirement, on a dedicated server, you configure logging at every relevant layer:

OS authentication logs: /var/log/auth.log records every authentication event, SSH login attempts, sudo commands, user switching, with timestamp, source IP, and username.

Web server access logs: In addition, Nginx and Apache log every HTTP request with source IP, request path, response code, bytes transferred, and user agent, providing the audit trail for all access to your application.

Database audit logs – MySQL’s general query log and audit plugin provide a record of all database queries, including failed authentication attempts and queries against sensitive tables. PostgreSQL’s pgaudit extension provides equivalent functionality.

Application-level logging: In the same way, authentication events, permission changes, data exports, and administrative actions must all be logged, with each entry containing sufficient detail for forensic analysis.

Log integrity: PCI-DSS requires that logs cannot be modified by the individuals who generated them. As such, on a dedicated server, you implement log forwarding to a separate, write-only log server, ensuring a compromised application server cannot tamper with its own audit trail.

Vulnerability Management (Requirements 5 and 6)

PCI-DSS requires that all system components are protected against malware, that security vulnerabilities are identified and addressed, and that critical patches are applied within one month of release.

On a dedicated server, you control the patching schedule entirely. When a critical vulnerability is announced, particularly those affecting web servers, databases, or the Linux kernel, you can apply the patch immediately without waiting for a provider’s maintenance window.

You can also implement automated security updates for OS-level packages using unattended-upgrades on Debian/Ubuntu, ensuring security patches are applied promptly while major version upgrades are reviewed before deployment.

Vulnerability scanning is a PCI-DSS requirement: quarterly internal scans and, for some compliance levels, quarterly external scans by an Approved Scanning Vendor (ASV). In this case, on a dedicated server, you can schedule and run internal vulnerability scans using tools like Lynis or OpenVAS without restriction.

---

What Genuine PCI DSS Compliant Hosting Actually Looks Like

Not every hosting environment marketed as “PCI compliant” delivers the same thing. Genuine PCI DSS compliant hosting means every one of the following is under your direct control, not managed on your behalf by a shared platform you cannot verify.

Table comparing shared hosting and dedicated servers across six PCI DSS compliance pillars: network isolation, system hardening, encryption key management, access control granularity, audit logs, and patch timing control, with dedicated servers meeting all six and shared hosting meeting none.

---

DDoS Protection and Availability: Indirectly Supporting PCI-DSS

PCI-DSS Requirement 6.4 addresses the need to protect web-facing applications against known attacks. While DDoS protection is not explicitly mandated by name, availability of payment processing systems is a compliance expectation, and dedicated server providers at enterprise datacenters typically include network-level DDoS mitigation as part of their infrastructure.

This means volumetric DDoS attacks, UDP floods, SYN floods, ICMP floods, are scrubbed at the datacenter network layer before reaching your server, protecting payment processing availability during attack events that would otherwise render a shared hosting environment completely unavailable.

Application-layer protection, rate limiting in Nginx, WAF rules via ModSecurity with the OWASP Core Rule Set, addresses the HTTP-based attacks that pass through network-level filtering and that PCI-DSS Requirement 6.4 specifically addresses for web-facing applications.

---

PCI-DSS Compliance Levels: Which Applies to You?

PCI-DSS compliance is tiered by transaction volume. Regardless of level, the infrastructure requirements are identical, only the verification method changes.

Table showing four PCI-DSS compliance levels by annual transaction volume, from Level 1 at 6 million or more requiring an annual on-site QSA assessment, to Level 4 under 20,000 requiring an annual self-assessment questionnaire.

---

The Scope Reduction Advantage of Dedicated Infrastructure

One of the most practical benefits of dedicated infrastructure for PCI-DSS is scope reduction. Specifically, PCI-DSS scope includes all system components that store, process, or transmit cardholder data, or that are connected to such systems.

A well-architected dedicated server infrastructure, with physically separate web, application, and database tiers, strict firewall rules limiting cross-tier communication to only what is necessary, and no other systems on the same hardware, creates the clearest possible scope boundary. As a result, assessors can verify the scope boundary objectively.

Shared hosting environments, by contrast, create ambiguous scope boundaries because systems outside your control are physically co-located with systems inside your scope. This ambiguity increases audit complexity and can result in scope expansion that no amount of additional controls can resolve.

---

---

Frequently Asked Questions

Do I need a dedicated server to achieve PCI-DSS compliance?

---

What PCI-DSS requirements are most difficult to meet without dedicated infrastructure?

---

What encryption does PCI-DSS require for cardholder data?

---

How does PCI-DSS define the Cardholder Data Environment (CDE)?

---

Does PCI-DSS require a Web Application Firewall (WAF)?

---

How does PCI-DSS compliance interact with GDPR for European businesses?

---

How do I verify a hosting provider genuinely offers PCI DSS compliant hosting?