PCI DSS Hosting: Servers, TLS, Logs and Backups

Why PCI‑DSS matters for your e‑commerce hosting

Your payment flow determines which hosting systems and controls need assessment. PCI DSS scope includes systems handling card data, systems with unrestricted connectivity to them, and components that can affect the security of that data. Outsourcing payment processing can reduce scope, but does not remove the merchant’s responsibility to secure its part of the flow and manage service providers.

When moving an online store from shared hosting to a VPS or dedicated environment, key planning questions include: Which components need isolation? Which TLS versions are allowed? How long should logs and backups be kept, and how can their integrity be demonstrated?

This guide walks through PCI‑DSS hosting requirements with a practical focus on four areas to plan: 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 practical checklist to map against your hosting plan and operational responsibilities. This guide uses PCI DSS v4.0.1, the January 2025 SAQ A r1 and current PCI SSC guidance, including requirements that became mandatory on 31 March 2025. Determine applicable controls and reporting with the organization accepting your compliance submission; this checklist does not certify a hosting product.

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

PCI DSS is the Payment Card Industry Data Security Standard. Account data includes cardholder data (CHD) and sensitive authentication data (SAD). The full primary account number (PAN) defines CHD; cardholder name, expiry date and service code present with PAN, or otherwise present in the CDE, require the applicable CHD protections. SAD includes card verification codes, PIN/PIN blocks and full track or equivalent chip data. Ordinary customer or order information alone is not automatically CHD, although systems holding it can still be in scope through connectivity or security impact.

Scope: which systems need PCI‑DSS assessment

Your PCI scope includes:

• Web servers, APIs, databases and caches that store, process or transmit CHD/SAD, and components with unrestricted connectivity to them.
• Logs, backups and recovery locations containing account data; assess other backup systems according to their connections and security impact.
• Systems that can affect the CDE or account-data security, including identity, DNS, web redirection, administration, CI/CD, security monitoring and segmentation controls.
• People, processes and administrative workstations associated with these functions. Document actual access paths rather than treating only the payment database as the assessment boundary.

SAQ A can apply to an eligible card-not-present channel whose account-data functions are fully outsourced to compliant providers. Merchant systems/premises must not electronically store, process or transmit account data; retained account data, if any, must be paper records not received electronically. Confirm provider compliance for the services used. For e-commerce, every payment page/form element must originate only and directly from the compliant provider: a redirect or provider-hosted iframe may qualify.

SAQ A-EP is for eligible e-commerce channels where the merchant website affects payment security but does not receive account data, such as a merchant-origin form posting directly from the browser to a compliant processor. All processing except the payment page is outsourced; payment-page elements must originate from the merchant or compliant provider. The merchant must still not electronically store, process or transmit account data, must confirm provider compliance for the services used, and must meet the paper-record condition. If a third-party provider hosts the merchant website, it must comply with all applicable PCI DSS requirements, including Appendix A where it is a multi-tenant hosting provider.

PAN passing through your application before tokenization does not meet A-EP’s no-account-data condition. Neither your domain name nor the mere presence of JavaScript settles SAQ choice. Validate every eligibility criterion with your acquirer/payment brand; SAQ D or a ROC may be appropriate instead. SAQ A/A-EP are merchant questionnaires, not service-provider assessment forms.

Our PCI DSS for e‑commerce on the hosting side covers operational responsibilities. For current SAQ selection, also account for the January 2025 SAQ A revision: questions 6.4.3, 11.6.1 and 12.3.1 were removed from that questionnaire, without removing those underlying DSS requirements. FAQ 1588 clarifies that the script-attack eligibility criterion concerns merchant pages embedding a provider’s payment form. Meet it through suitable protection techniques or the compliant provider’s confirmation that its correctly implemented solution protects the merchant payment page from script attacks. This particular criterion does not apply to redirects or payment links; other eligibility and security requirements remain.

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

Staff responsibilities, access reviews, incident response and provider management remain part of the compliance program. Obtain service-specific evidence such as the provider’s AOC and a responsibility matrix; a provider’s status does not automatically cover your configuration. Requirement 12.8.5 calls for identifying controls handled by the provider, by the merchant and jointly. Agree how you receive evidence and investigate failures.

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

Choose hosting from your payment flow, assessment scope, required controls, capacity and management responsibilities. PCI DSS does not mandate a particular hosting product. More server access can give you configuration options, but also creates maintenance responsibilities.

Shared hosting vs VPS vs dedicated vs colocation

Shared hosting may be usable for an eligible SAQ A payment flow, provided all eligibility criteria, applicable controls, isolation and provider responsibilities are met. Merely keeping PAN off the server is insufficient. Consider VPS, dedicated or colocated servers when your architecture requires firewall, logging or hardening controls that your shared hosting plan does not provide.

• VPS: Good balance of isolation, flexibility and cost. With a plan that provides root access, you can tune the OS, firewall and TLS, and use multiple VPSs to separate application roles.
• Dedicated servers: A physical machine allocated to one customer avoids sharing that machine’s CPU and RAM with other customers. Network, storage and administration dependencies still need assessment. You can separate web, database, logging and backup servers on dedicated hardware.
• Colocation: You own the hardware and contract for data center space, power, cooling and network connectivity. 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

Restrict access to in-scope systems and expose only necessary services. Segmentation is a recommended way to reduce scope, not a universal PCI DSS requirement. If you use it to claim systems are out of scope, demonstrate that those systems cannot affect the CDE even if compromised. A practical topology may include:

• 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, separate firewalled services, containers or supported VMs can help restrict communication, alongside strict IP‑based and user‑based database access controls. Treat this as a shared-host design whose isolation must be evaluated, not as proof that payment systems are independently protected.

Server build and hardening

The following are practical hardening steps for a VPS or dedicated server. They support relevant requirements; the checklist is not a literal list of PCI-mandated Linux settings:

• Use a supported operating system, inventory components and install applicable patches. Under 6.3.3, critical vulnerability patches are due within one month of release; set other patch deadlines through your environment’s risk assessment.
• Disable unnecessary services and remove sample applications and unnecessary default accounts.
• Use non-root administrative access, limited groups and SSH keys as part of a suitable authentication design. Implement required MFA; a key alone is not automatically MFA and “optional 2FA” is not sufficient for access covered by 8.4.
• Apply least privilege to people and service accounts; use individual identities for routine access and remove departing personnel’s access immediately.
• Choose file permissions from the actual owner/group and runtime model; our Linux file permissions guide explains 644/755 examples, which are not universal permission recipes.

Remove forgotten test virtual hosts, exposed directory listings and publicly accessible logs/configuration files. Requirement 8.4.1 covers non-console administrative access into the CDE; 8.4.2 covers all non-console CDE access, subject to its specific notes for automated application/system accounts, single-card transaction POS users and accounts authenticated only with phishing-resistant factors. Requirement 8.4.3 requires MFA for remote access originating outside the entity’s network that could access or impact the CDE. One MFA check does not automatically cover a later, separate access boundary; assess the actual path and applicable notes.

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 separation can help organise logging and access controls. To demonstrate isolation, document and validate the actual network paths, permissions and shared dependencies; separate servers or containers alone do not prove that a blog compromise cannot reach payment systems. Where 11.4.5 applies, test segmentation at least every 12 months and after changes, covering all segmentation methods, using qualified testers with organizational independence. Container names and VLAN diagrams are not substitute evidence.

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

Requirement 4.2.1 protects PAN transmitted over open, public networks with strong cryptography and secure protocols. It requires trusted keys/certificates, valid and non-revoked certificates, secure configurations and no fallback to insecure versions or algorithms. Do not broaden that wording into an assertion that this single requirement covers every type of data over every internal network. Verified encryption of internal service and backup traffic is also a sound security choice.

Protocols and cipher suites

Use PCI DSS’s strong-cryptography requirements alongside current TLS implementation guidance such as RFC 9325. For a modern web-server/load-balancer policy:

• 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 keeping SSL/TLS settings up to date and enabling TLS 1.3, OCSP stapling and HSTS discuss web TLS configuration. Check current software and CA behaviour before adopting examples: Let’s Encrypt ended its OCSP service on 6 August 2025 and now publishes revocation information through CRLs. OCSP stapling is therefore not a universal setup step for every certificate.

Certificate types: DV, OV, EV and wildcards

Certificate validation class does not by itself determine TLS encryption strength. Select coverage, identity validation, renewal support and key handling from your needs and verified contractual requirements:

• DV verifies control of the domain and can protect checkout connections with a suitable certificate and TLS configuration. A certificate alone does not establish PCI compliance.
• OV/EV add organization identity validation; they do not automatically provide stronger encryption for identical protocol/key settings. Confirm an actual policy or contract before treating them as required.
• Wildcard describes domain coverage, rather than the same validation axis as DV/OV/EV. Sharing its private key across systems can extend the impact of compromise; limit distribution and access.

Our guide to choosing between free and commercial SSL for e‑commerce discusses operational tradeoffs. Do not classify DV as suitable only for non-critical subdomains or claim OV/EV is universally required for checkout. Match trust, hostname coverage and automated renewal to the deployment.

Practical TLS hardening tips

Practical HTTPS measures for a store include:

• Serve customer pages over HTTPS, update internal links and configure appropriate HTTP-to-HTTPS redirects. Redirects do not protect sensitive data already sent in an initial plain-HTTP request.
• Deploy HSTS after testing HTTPS and the intended subdomain scope; assess preload separately.
• Set Secure/HttpOnly and suitable SameSite attributes for session cookies, testing checkout redirects and embedded payment flows.
• Use the revocation mechanisms supported by the issuing CA and clients. Configure OCSP stapling only where the certificate/CA support it; Let’s Encrypt’s OCSP service has ended.
• Automate certificate issuance/renewal and verify the renewed certificate is actually loaded by every endpoint. Monitor failures and expiry.

Requirement 4.2.1.1 calls for an inventory of trusted keys and certificates used to protect PAN over open, public networks. Track endpoint ownership, expiry and renewal deployment. HTTP headers have distinct roles: CSP limits allowed content/script sources, frame-ancestors or X-Frame-Options restrict embedding, nosniff limits MIME guessing and Referrer-Policy controls referrer disclosure. They support browser security but are not interchangeable or a general phishing barrier.

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

Map required audit events to 10.2.1, rather than enabling verbose logging indiscriminately. Relevant sources include:

• Individual access to cardholder data, administrator actions, invalid logical access attempts and access to audit logs.
• Creation/changes of identification or authentication credentials, privilege changes and account lifecycle events.
• Initializing new audit logs; starting, stopping or pausing existing audit logs; and creation/deletion of system-level objects.
• Security tools and critical application, firewall and database events needed to reconstruct activity.
• For each required auditable event, capture user identity, event type, date/time, success/failure, origin and affected data/system/resource/service under 10.2.2; synchronize clocks.

Collect the required events from the operating system, web server, database, application and security controls. Verify their fields and timestamps with test events. Separate operational checkout diagnostics from required audit trails, and avoid recording secrets, request bodies or payment details merely to make debugging convenient.

What you must never log

The rules for PAN and sensitive authentication data are different:

• SAD: merchants must not store CVV/CVC, PIN/PIN blocks or full track/equivalent chip data after authorization, even encrypted (3.3.1). This includes logs, traces, crash dumps and backups.
• PAN: retain only when necessary and render it unreadable wherever stored under 3.5.1. Permitted approaches include appropriate truncation, index tokens or strong cryptography with key management. Hashing must use a keyed cryptographic hash of the entire PAN with associated key management under 3.5.1.1; follow the method’s additional requirements. Encryption is not the sole permitted method.
• Prefer not to collect PAN in application or web logs at all. Display masking and stored-data protection are different controls; hiding digits in a viewer does not make a raw log safe.

Use structured logs with an explicit allowlist of fields; structure alone does not remove sensitive values. Check payment success/failure paths, exception traces, access URLs, debug output and archived backups. Drop unnecessary fields before persistence, and confirm that no post-authorization SAD remains in any copy.

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:

• Limit read access to people with a job-related need and protect existing log files against modification (10.3.1/10.3.2).
• Promptly back up audit logs to a secure, central, internal log server or other media difficult to modify (10.3.3). The standard does not mandate ELK, Loki or WORM specifically.
• Use file-integrity/change detection so changes to existing audit logs generate alerts (10.3.4); verify that routine additions and unauthorized alteration are distinguished.
• Review the security, CHD/SAD, critical-system and security-function logs covered by 10.4.1 at least daily, using automated mechanisms under 10.4.1.1. Set the periodic review of other in-scope logs through the applicable risk analysis, and assign investigation responsibility.

Our Centralising logs for multiple servers with ELK and Loki covers multi-host stack design, while our VPS log management guide covers collector migration, labels, retention and alert considerations. Verify collection, access, retention and response separately; a dashboard does not prove complete delivery or control effectiveness.

Log retention periods and compliance

Where 10.5.1 applies, audit-log history must be retained for at least 12 months, with at least the most recent three months immediately available for analysis. This is a requirement, not a typical recommendation. Define the actual retrieval process and measure it; a particular storage tier is not mandatory. Minimize unnecessary personal data while meeting applicable security, legal and contractual duties.

Define retention by log purpose and obligation, then enforce and test the policy. Log retention on hosting and email infrastructure for KVKK/GDPR compliance provides a general classification framework; its examples are not substitutes for PCI DSS 10.5.1 or a determination of your legal requirements.

Keep operational debug/performance logs on a justified schedule distinct from required audit history. Test rotation, archival, access and deletion after retention expires. Longer retention does not justify collecting prohibited authentication data.

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

Assess backups according to their account data, connectivity and ability to affect CDE security. PAN-bearing backups and relevant configuration, key-management and recovery systems need applicable controls; an ordinary product-image archive is not automatically cardholder data. Moving a copy offsite does not remove its protection requirements, and encryption alone generally does not remove PCI scope.

Backup scope and frequency

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

• Application code and configuration, with secrets handled through a separately controlled recovery process.
• Order, customer and product databases, retaining only needed data and applying the relevant protections.
• Uploaded media and assets that cannot easily be reproduced.
• Infrastructure-as-code, deployment configuration and related recovery dependencies; identify which can affect CDE security.

Set backup frequency from business-defined RPO (acceptable data loss) and RTO (target recovery time), then prove the result with restore tests. Daily full/incremental backups or more frequent database log archiving are examples, not PCI-prescribed intervals. Coordinate database consistency, transaction logs and application dependencies.

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

3-2-1 is a recovery design recommendation, not a literal PCI DSS copy-count requirement:

• 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

A design might combine local snapshots for convenience, separate backup storage and a protected offsite copy. A snapshot on the same failed disk is not an independent copy. Check credentials, deletion protection, physical failure domains and recovery dependencies; no particular DCHost plan or offsite service is assumed here.

Encryption and access control for backups

Protect PAN wherever it is stored under 3.5.1, including backups; do not retain SAD after authorization even if encrypted. Strong encryption is one allowed PAN protection method and a useful archive safeguard, with key protection and lifecycle processes under 3.6/3.7. For transport, 4.2.1 specifically covers PAN over open, public networks. Operationally:

• Use verified TLS for HTTPS/S3-compatible transports. SSH/SFTP uses SSH’s own encrypted transport, not TLS over SSH; verify host identity and credentials.
• Choose an encrypted repository/archive mode and verify the configuration. Restic encrypts repository data; Borg also supports an unencrypted mode, so naming the tool does not prove encryption.
• Separate permission to use recovery keys from ordinary storage access, preserve authorized recovery material and define key lifecycle/rotation procedures. Encryption without usable protected keys can make recovery impossible.
• Restrict backup reads and restores by role; use separate limited credentials and collect applicable audit trails. Avoid unrestricted production databases in developer environments.

Test restores in an isolated environment with equivalent protection for any in-scope data; verify database/application consistency, integrity and measured recovery time. Requirement 12.10.1 includes business recovery/continuity and data backup processes in the incident response plan, while 12.10.2 requires review and testing of the complete plan at least every 12 months. PCI DSS does not prescribe one universal RPO, RTO or backup interval.

6. A practical PCI DSS hosting rollout and evidence plan

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

• Map the browser, form origins, payment API, server, logs, backups and administration paths. Validate all SAQ eligibility conditions; a redirect or provider iframe can qualify for A, while merchant-origin direct post may qualify for A-EP.
• If your application receives PAN, later tokenization does not satisfy A-EP’s no-account-data condition. Confirm the appropriate SAQ or ROC reporting route with the organization accepting your submission.
• For WooCommerce integration choices, see PCI‑DSS checklist for WooCommerce hosting. Platform name, own domain or a JavaScript label alone does not establish SAQ eligibility.

Step 2: Choose and segment your hosting

• Choose shared hosting, VPS, dedicated or colocation according to needed controls, traffic and responsibility allocation; obtain evidence for the actual services used.
• Where using segmentation, restrict web/application/database access and demonstrate effective isolation. Shared hosts, containers and VLANs require assessment of common dependencies.
• Default-deny unnecessary network access. Where 6.4.2 applies, deploy an active, current automated solution in front of public web applications to detect/prevent attacks and generate logs, with blocking or immediate investigation of alerts; a WAF can serve this purpose.

Step 3: Harden servers and deploy TLS correctly

• Install supported systems, remove unnecessary services and implement the patch policy. Plan applicable 11.3 internal and ASV external scans at least every three months, remediation/rescans and scans after significant changes. The additional post-change external scans in 11.3.2.1 require qualified, organizationally independent testers and need not be performed by an ASV.
• Restrict administration, use individual least-privilege identities and implement MFA for the access paths required by 8.4; SSH keys alone do not settle that requirement.
• Deploy strong TLS using current guidance and verify hostname/trust, revocation, renewal and HTTP security headers. Choose SSL certificates using our SSL certificate selection guide for e‑commerce, without treating a certificate class as a compliance guarantee.
• Where applicable, 11.5.2 requires critical-file change detection with at least weekly comparisons. Under 6.4.3 manage payment script authorization, integrity and a justified inventory; 11.6.1 requires detection of unauthorized changes to payment-page script content and security-impacting headers as received by the browser, at least weekly or at the frequency set by the relevant targeted risk analysis. Apply SAQ A r1’s separate eligibility approach where appropriate.

Step 4: Implement structured logging and monitoring

• Generate test events and confirm required fields, synchronized time and the absence of prohibited SAD. Minimize PAN rather than merely avoiding cleartext.
• Verify secure prompt backup of audit logs, limited access and detection of changes to existing records.
• Enforce the applicable 12-month/most-recent-three-month rule and per-log policies, using our log retention guide for general classification.
• Test daily/periodic review, actual alert routing, investigation ownership and detection of missing log delivery.

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

• Map backup data and security dependencies to PCI scope; apply required PAN protections and keep post-authorization SAD out of every copy.
• Choose a recovery design such as 3-2-1 with independent failure domains, protected offsite copies and limited production access.
• Protect recovery credentials and keys separately, define their lifecycle and ensure authorized recovery is possible.
• Run restores in an isolated, appropriately protected environment and document integrity, application health and measured recovery time. our backup strategy article explains business-driven RPO/RTO planning.

Step 6: Document and keep improving

• Document architecture, data flows, responsibilities, controls and verification evidence.
• Confirm scope at least annually and after significant changes as required by 12.5.2; review provider status and the applicable incident response/testing schedule.
• Track protocol, software, browser and payment-provider changes. Revalidate controls when the environment changes instead of treating an annual questionnaire as the only maintenance task.

7. Bringing it all together

The hosting plan should connect each control to a scope decision, an owner and evidence. Use appropriate architecture and access controls, current TLS, trustworthy audit trails and protected, tested recovery. Segmentation and 3-2-1 are useful design choices whose role must be distinguished from specific PCI DSS requirements.

When comparing DCHost or other providers, ask for the actual plan’s permissions, service boundaries, control responsibilities and applicable compliance evidence. A product label, dedicated server or provider AOC alone does not prove the merchant environment meets every requirement. Confirm which controls you operate and which evidence the provider supplies.

Start with the payment-flow and scope map, then prioritize gaps across servers, TLS, logs and backups. Record acceptance results, owners and the next review date. This creates a repeatable basis for maintaining the environment as traffic, integrations and infrastructure change.

Primary Technical References

• PCI DSS v4.0.1 / SAQ A r1 / SAQ Instructions and Guidelines
• PCI SSC FAQ 1588
• SAQ A — January 2025
• RFC 9325 — TLS
• Let’s Encrypt — OCSP end of life