PCI‑DSS Compliant E‑Commerce Hosting Guide: Servers, SSL, Logs and Backups

Why PCI‑DSS matters for your e‑commerce hosting

If your online store touches cardholder data in any way, PCI‑DSS is not optional. Whether you run a small WooCommerce shop or a multi‑store Magento deployment, the way you host, encrypt, log and back up your environment directly affects your compliance status. Card brands and banks do not really care which shopping cart you use; they care about whether card data can leak from a misconfigured server, weak TLS or missing audit logs.

At dchost.com we regularly sit in on security and infrastructure planning meetings with merchants who are expanding from a simple shared hosting setup to a more controlled VPS or dedicated environment. The same questions keep coming up: What exactly has to be on a separate server? Which TLS versions are allowed? How long should logs and backups be kept, and how do we prove they were not tampered with?

This guide walks through PCI‑DSS hosting requirements with a practical focus on four areas you can control on day one: server architecture, SSL/TLS, logging and monitoring, and backups and disaster recovery. The goal is not to turn you into a QSA but to give you a concrete, technically realistic checklist you can implement on dchost.com infrastructure.

1. PCI‑DSS basics: scope, SAQs and what hosting can (and cannot) solve

PCI‑DSS is the Payment Card Industry Data Security Standard, a set of technical and process requirements that applies to any system that stores, processes or transmits cardholder data. For hosting, the two most important ideas are scope and segmentation.

Scope: which systems are in the cardholder data environment

Your PCI scope includes:

• Web servers that receive card data or host payment forms
• APIs and backend services that relay payment information
• Databases or caches that store customer or payment‑related data
• Logging, backup and monitoring systems that contain any of the above

If your store uses fully hosted payment pages or payment links, you may qualify for a lighter SAQ (Self‑Assessment Questionnaire) such as SAQ A. If the payment form is served from your own domain and the card data passes through your application before being tokenised, you are usually in SAQ A‑EP territory with heavier technical requirements on your servers.

We explored this distinction in more detail in our article PCI DSS for e‑commerce on the hosting side, but the short version is simple: the more your own infrastructure touches card data, the more controls you must implement.

What hosting can solve vs what stays in your processes

Your hosting layer can address many of the technical controls in PCI‑DSS, for example:

• Secure server builds, patching and network firewalls
• Strong TLS configuration and certificate management
• Centralised logging, log retention and access control
• Encrypted, tested backup and restore procedures

Other PCI requirements live in your organisation, such as formal policies, staff training, incident response and vendor management. A realistic PCI plan combines both: hardening your dchost.com servers and also documenting who can access what, how you handle disputes and how you respond to potential breaches.

2. Server and network architecture for PCI‑DSS compliant hosting

Once you know your SAQ type and scope, the next decision is hosting architecture. PCI‑DSS does not force you into a specific product, but some choices make compliance much easier.

Shared hosting vs VPS vs dedicated vs colocation

For very small stores using redirect‑based or hosted payment pages, shared hosting can still be acceptable if you keep your store firmly in SAQ A and ensure no card data ever touches your code or server. As soon as you serve payment forms from your own domain or integrate more complex flows, you typically move to VPS, dedicated or colocated servers so you can control firewalls, logging and hardening.

• VPS: Good balance of isolation, flexibility and cost. You get root access, can tune the OS, firewall and TLS, and can segment applications using multiple VPSs.
• Dedicated servers: Full hardware isolation, useful for high‑traffic or very strict compliance environments. You can separate web, database, logging and backup servers on dedicated hardware.
• Colocation: You own the hardware, we provide the data center, power, cooling and network. This suits organisations with strict internal standards or existing on‑prem standards they want to replicate.

If you are comparing options, our article Dedicated server vs VPS: which one fits your business walks through the trade‑offs from a performance and management perspective.

Network segmentation and firewalls

PCI‑DSS expects you to minimise the systems directly exposed to the internet and strictly limit access to the cardholder data environment. In hosting terms this usually means:

• Placing a reverse proxy or load balancer in front of your application servers
• Restricting inbound traffic with a stateful firewall, only opening ports that are needed (for example 80/443 to the public, SSH only from admin IP ranges or VPN)
• Separating web, application and database servers onto different network segments or VLANs when possible
• Using a Web Application Firewall (WAF) to block common attack patterns before they hit your app

On a single powerful VPS you can still apply logical segmentation by running separate firewalled services, containers or VMs and forcing all database access through strict IP‑based and user‑based controls.

Server build and hardening

PCI‑DSS includes a long list of system hardening expectations. On your dchost.com VPS or dedicated server you should at least:

• Use a modern, supported Linux distribution and keep it patched
• Disable unused services and remove sample apps and default accounts
• Enforce strong SSH security: key‑based auth, non‑root logins, restricted groups, optional 2FA
• Apply the principle of least privilege for system users and service accounts
• Use file permissions appropriate for web apps, similar to the 644/755 guidelines we cover in our Linux file permissions guide

Do not underestimate default settings. A single forgotten test vhost with directory listing enabled can leak logs, configuration files or even environment variables that contain secrets.

Isolating payment functionality

For larger stores, it is often worth hosting payment‑related components more tightly isolated than the rest of the site. For example:

• Public storefront on one VPS or server
• Checkout and payment microservice on a separate server or at least separate container/network segment
• Database and caching servers in a private network, with no direct internet access

This segmentation makes it easier to define PCI scope, apply stricter logging and access control, and prove to auditors that a compromise of, say, your blog subdomain does not automatically grant access to payment systems.

3. SSL/TLS and certificate requirements for PCI‑DSS

From a PCI point of view, insecure transport is a direct path to card data theft. The standard is explicit: cardholder data must never cross the network in clear text, and weak protocols and ciphers must be disabled.

Protocols and cipher suites

On your web servers and load balancers you should:

• Disable SSLv2, SSLv3, TLS 1.0 and TLS 1.1. Support only TLS 1.2 and TLS 1.3.
• Use strong cipher suites that provide forward secrecy (ECDHE key exchange) and modern AEAD ciphers like AES‑GCM or CHACHA20‑POLY1305.
• Turn off weak options such as NULL, EXPORT and RC4 ciphers.
• Prefer secure curves and key sizes: 2048‑bit RSA minimum, ECDSA with modern curves where supported.

Our articles on keeping SSL/TLS settings up to date and enabling TLS 1.3, OCSP stapling and HSTS show concrete Nginx and Apache configurations you can adapt for your store.

Certificate types: DV, OV, EV and wildcards

PCI‑DSS does not force you to use a specific certificate type, but for e‑commerce there are practical considerations:

• DV (Domain Validation): Technically secure and fine for the protocol, but offers no verified organisation details.
• OV (Organisation Validation): Adds verified business identity, which can improve trust for corporate stores.
• EV (Extended Validation): Historically more visible in browsers; today less prominent, but some enterprises still prefer it for legal or policy reasons.
• Wildcard: Convenient for many subdomains under one parent domain, but must be protected carefully because compromise impacts all covered hosts.

We compare these options in depth in our guide to choosing between free and commercial SSL for e‑commerce. For many merchants a mix works well: DV or wildcard certificates for non‑critical subdomains, and OV or EV for the main checkout domain.

Practical TLS hardening tips

Some practical measures we recommend on dchost.com servers:

• Redirect all HTTP traffic to HTTPS using 301 redirects and update internal links
• Enable HSTS (HTTP Strict Transport Security) after verifying that HTTPS works everywhere
• Use secure cookie flags: Secure, HttpOnly and appropriate SameSite settings for session cookies
• Configure OCSP stapling for faster and more reliable certificate validation
• Automate certificate renewal, whether using ACME for DV certs or an API/integration for commercial certificates

PCI‑DSS also expects you to maintain an inventory of certificates and update them before expiry. Automating renewals and monitoring dates removes a large class of avoidable outages and compliance findings.

4. Logging, monitoring and retention for PCI‑DSS

Logging is where many e‑commerce sites drift out of compliance without realising it. Either they log too little and cannot reconstruct events, or they log too much and accidentally store sensitive data in plain text.

What you should log

PCI‑DSS expects you to log at least:

• All authentication events: successful and failed logins for admin panels, SSH, database consoles and application backends
• Changes to user privileges and roles
• Configuration changes on firewalls, web servers, databases and key applications
• Access to cardholder data or systems that process it
• Security events, such as WAF blocks, intrusion detection alerts and malware scans

On a typical dchost.com VPS or dedicated server this means configuring logs from the OS, web server, database, application framework and security tools to flow into a central place where they can be retained and analysed.

What you must never log

At the same time, PCI‑DSS strictly forbids logging certain data elements in clear text, including:

• Full PANs (Primary Account Numbers) unless they are encrypted and access is strictly limited
• CVV/CVC codes
• PINs or PIN blocks
• Full magnetic stripe or chip data

Your application logs, access logs and debug output must be reviewed to ensure they do not accidentally contain these fields. Enable structured logging so you can drop or mask sensitive values before they hit disk.

Centralised logging and tamper resistance

PCI‑DSS requires that logs are protected from tampering and accessible for review. On the hosting side that translates into:

• Shipping logs off each server to a central log server or logging cluster (for example via syslog or log shippers)
• Restricting who can read and manage logs; administrators for the app should not automatically be able to delete logs that incriminate them
• Using append‑only or versioned storage where possible, so deletion or modification attempts are obvious
• Implementing alerting for critical events such as multiple failed logins, firewall rule changes or unexpected privilege escalations

We have a detailed walkthrough of centralised logging stacks in our article Centralising logs for multiple servers with ELK and Loki, and a VPS‑focused look at log pipelines in our VPS log management guide.

Log retention periods and compliance

PCI‑DSS typically expects you to retain certain logs for at least one year, with three months immediately available for analysis. At the same time, privacy regulations like GDPR and KVKK push you to avoid storing unnecessary personal data indefinitely.

Balancing these needs requires clear policies and technical enforcement. Our article Log retention on hosting and email infrastructure for KVKK/GDPR compliance explains how to define retention per log type, implement automatic deletion and still satisfy security and legal expectations.

In practice, you will usually store security and access logs longer than low‑level debug or performance logs, and you will regularly test that log rotation and archival are working as designed.

5. Backup, encryption and disaster recovery under PCI‑DSS

Backups are both a lifesaver and a potential liability. If you back up everything, including unencrypted databases and logs, and then lose those backups, you have effectively leaked your entire cardholder data environment. PCI‑DSS therefore treats backups as part of the CDE and applies the same controls.

Backup scope and frequency

For an e‑commerce hosting setup, you typically need to back up:

• Application code and configuration, including environment files and secrets (preferably in an encrypted form)
• Databases that hold orders, customer data and product catalogues
• Uploaded media and assets that are not easily reproducible
• Key configuration repositories such as infrastructure‑as‑code, Ansible playbooks or CI pipelines

A realistic starting point is daily full or incremental database backups, with more frequent binlog or WAL archiving if you need tighter RPOs (Recovery Point Objectives). Filesystem backups may be daily or hourly depending on how often content changes.

For a deeper dive into shaping RPO and RTO to your business, see our article How to design a backup strategy for blogs, e‑commerce and SaaS sites.

3‑2‑1 and offsite backups

The classic 3‑2‑1 rule fits PCI‑DSS nicely:

• Keep at least 3 copies of your data (production plus two backups)
• Store them on at least 2 different media or platforms (for example local snapshot + remote object storage)
• Ensure at least 1 copy is offsite and not immediately accessible from production

On dchost.com this may mean a combination of on‑server snapshots for fast restores, dedicated backup storage in the same data center for quick recovery, and encrypted offsite backups to a separate region or provider in case of major incidents.

Encryption and access control for backups

Backups must be encrypted in transit and at rest. Practically this means:

• Using TLS for all backup transports, whether you are sending data over SSH, HTTPS or S3‑compatible APIs
• Encrypting backup archives with strong algorithms; if you use tools like restic or Borg, client‑side encryption is built in
• Separating encryption keys from the backup storage location, with strict access control and rotation policies
• Limiting who can restore from backups; not every developer should be able to fetch a full database with customer data

Finally, test restores are not optional. A backup that has never been restored is only a theory. Schedule regular, documented restore drills to verify that you can meet your RTO and that the restored environment boots cleanly and passes application health checks.

6. A practical PCI‑aware rollout plan on dchost.com

Let us put the pieces together into a concrete checklist you can adapt to your own e‑commerce project.

Step 1: Decide your payment flow and SAQ type

• Choose between fully hosted payment pages (scope reduction, SAQ A) and on‑site payment forms that post directly to the gateway (SAQ A‑EP).
• If you run WooCommerce, our article PCI‑DSS checklist for WooCommerce hosting walks through real‑world examples.
• Document the exact path card data takes. Any system that can see or log it is in scope.

Step 2: Choose and segment your hosting

• Select a VPS, dedicated server or colocated solution appropriate for your traffic and compliance level.
• Plan at least logical segmentation between web frontends, application backends and databases; for higher assurance, use separate servers or VLANs.
• Deploy a firewall with a default‑deny stance, opening only required ports, and consider adding a WAF in front of your store.

Step 3: Harden servers and deploy TLS correctly

• Install a supported Linux distribution, remove unused packages and disable default/demo services.
• Lock down SSH with key‑only auth, non‑root logins and restricted admin IP ranges or VPN.
• Configure Nginx or Apache to serve only TLS 1.2/1.3 with strong ciphers and HSTS after testing.
• Choose appropriate SSL certificates for your domains, using the guidance from our SSL certificate selection guide for e‑commerce.

Step 4: Implement structured logging and monitoring

• Enable detailed but safe logs for the OS, web server, database and application, making sure no card data is written in clear text.
• Forward logs to a central log server or logging stack with restricted access.
• Define retention periods per log type, using the principles explained in our log retention guide.
• Set up alerts for failed logins, permission changes, firewall rule updates and application‑level errors on checkout.

Step 5: Design and test a PCI‑aware backup and DR strategy

• Identify all systems in PCI scope and ensure they are covered by regular, encrypted backups.
• Apply the 3‑2‑1 rule with at least one offsite copy that cannot be directly reached from production.
• Use separate credentials and keys for backup access, rotated on a schedule.
• Run restore drills to a staging environment, verify data integrity and document the runbook. The RPO/RTO planning ideas in our backup strategy article are particularly useful here.

Step 6: Document and keep improving

• Write down your hosting architecture, data flows, logging and backup policies in a short but clear internal document.
• Review PCI‑DSS requirements annually or when you significantly change payment flows or hosting architecture.
• Keep an eye on updates to TLS, browser behaviour and security best practices; our ongoing SSL/TLS and security posts on the dchost.com blog are designed to help you stay ahead of these changes.

7. Bringing it all together

PCI‑DSS can look intimidating from the outside, but once you break it down into concrete hosting tasks it becomes manageable. On the server side you need a clean, segmented architecture; hardened operating systems and services; modern TLS with the right certificate strategy; trustworthy logs; and encrypted, tested backups. On the organisational side you need documentation, access controls and a culture that treats cardholder data with the same care as cash in a physical store.

At dchost.com we see every day that merchants who invest a bit of effort early save themselves a lot of stress later. A carefully designed VPS, dedicated or colocation setup that respects PCI scope makes audits easier, incidents rarer and scaling more predictable. If you are planning a new e‑commerce project or want to bring an existing store closer to PCI‑DSS compliance, our team can help you choose the right hosting architecture and translate this guide into a concrete deployment plan on our infrastructure.

Start by mapping your payment flows, then review your servers, SSL/TLS, logs and backup strategy against the steps above. From there, we can fine‑tune capacity, high availability and performance together, so your store stays fast, secure and compliant as it grows.