PCI DSS compliance depends partly on how your hosting environment handles payments. The practical work includes defining scope, configuring firewalls and TLS, separating systems, protecting backups, and maintaining reliable logs.
This guide uses PCI DSS v4.0.1, published in June 2024, to connect payment scope with a repeatable hosting security routine. The applicable requirements depend on your payment integration and assessment scope. Confirm the appropriate Self-Assessment Questionnaire (SAQ) with the entity accepting your compliance submission, usually your acquirer or payment brand. Then assign owners, deadlines and evidence for the controls your environment needs.
How PCI DSS Applies to Hosting
Start with the payment flow and security dependencies
PCI DSS covers systems that store, process or transmit cardholder data, systems with unrestricted connectivity to them, and systems that can affect their security. The last category can include administrative accounts, deployment tools and payment redirection servers even when they never store a card number. Effective, validated segmentation can keep unrelated systems outside scope. Sharing a host or administrative path with test scripts and unrelated projects can undermine that separation.
Your payment flow helps determine your hosting obligations. A hosted payment page or gateway-hosted embedded fields can reduce scope when card data bypasses your servers, but eligibility for a particular assessment depends on the full integration and applicable criteria. For WooCommerce payment setups, see PCI DSS Checklist for WooCommerce Hosting. It walks through the common payment setups and what they mean for your obligations.
A hosted payment flow is not an automatic exemption. For embedded payment forms, the merchant page surrounding the provider’s iframe can still affect payment security. SAQ A v4.0.1 r1 includes a script-attack eligibility criterion for that embedding page. That particular criterion does not apply in the same way to pages that redirect customers entirely to a payment provider; other SAQ obligations remain. The provider’s exact implementation and all eligibility criteria matter, not simply the domain shown in the address bar.
Designing Your Hosting to Shrink PCI Scope
Separate public, application and administrative access
Consider a hypothetical shop with everything on one VPS—storefront, admin, staging, cron, analytics, and unrelated projects. Separating staging and unrelated workloads from production, and restricting admin access to a secure network, can reduce unnecessary exposure. Moving workloads alone does not fix a directory listing issue or prove that segmentation reduces PCI scope.
First determine whether a provider-hosted payment page or properly integrated embedded form can keep card data away from your servers. Tokenization is a separate technique that replaces card data with a reference; its scope impact depends on the implementation and remaining systems. Map the permitted connections between your public edge, application, database and management networks. Document why each path exists, and verify the isolation used to reduce scope instead of assuming that separate network labels prove it.
On the edge, a load balancer or reverse proxy can help centralize TLS and enforce consistent rules. It can also support controlled deployments, health checks and failover. For an explanation of these patterns, see: HAProxy Layer 4/7 load balancing, health checks and TLS. Centralizing entry points can make ingress policies and event collection more consistent; it does not establish compliance by itself.
Restrict access to administrative services through appropriate network and identity controls, such as a VPN or tightly restricted bastion host. mTLS can authenticate a client certificate before an administrative login, but does not make a public endpoint private. Apply least privilege to both people and network connections, and enforce the applicable MFA requirements. An IP allowlist, VPN or SSH key alone is not evidence that those authentication requirements have been met.
TLS Across the Edge and Origin
Certificates, protocols, and avoiding ancient ciphers
Define your TLS policy across the origin, proxy and CDN, including the connections between them. Remove weak protocols and cipher suites, verify certificates and renewal, and test checkout compatibility before changing production. Enable HSTS only after HTTPS is reliable across all hosts it will cover. Use OCSP stapling where the certificate authority and server support it. These settings must support the applicable strong-cryptography requirements; a certificate or a successful browser connection alone is not a compliance result.
Certificates also deserve a thoughtful approach. Domain validation (DV), organization validation (OV) and extended validation (EV) describe different identity-validation processes; a wildcard describes hostname coverage. OV or EV does not automatically provide stronger TLS encryption or establish PCI compliance. For a comparison of certificate types, see: Choosing DV, OV, EV or wildcard certificates. Choose identity validation and hostname coverage for your service, then verify the protocol configuration and certificate lifecycle separately.
For admin panels, client certificates can add an access-control layer. Correctly enforced mTLS can block clients without valid certificates before they reach the login page. Combine it with the user authentication and applicable MFA controls required for that access path. For a step‑by‑step guide, see: Protecting panels with mTLS on Nginx. Include certificate issuance, revocation and renewal in the access-management process.
Server and Application Hardening
Patching, SSH and file permissions
Keep an inventory of the operating system, web server, application, plugins and other dependencies. Under PCI DSS v4.0.1 requirement 6.3.3, patches for vulnerabilities ranked critical must be installed within one month of release; other applicable security patches follow an appropriate timeframe based on the entity’s risk assessment. Active exposure can justify acting sooner. Use controlled automation, checkout testing, maintenance windows and a rollback procedure to make the patch schedule achievable.
For SSH, use individual credentials and prefer managed keys over password-only access. Remove departing personnel’s access immediately, and rotate shared or potentially exposed secrets. Apply MFA according to the requirements covering the access path; ordinary SSH keys alone do not satisfy an MFA requirement. A non-default port can reduce background noise but does not replace restricted ingress, authentication or monitoring.
Review application file permissions and execution paths. Web roots should not be world‑writable; uploads directories should be separate from executable code and configured to prevent execution of uploaded scripts; and staging shouldn’t sit next to production on the same server. For WordPress-specific steps alongside the broader hosting controls, see: WordPress Hardening Checklist. For other platforms, apply the same separation between writable content and executable code, and verify that unauthorized changes produce an alert.
Containers and orchestrators are also part of the scope assessment when they handle card data or can affect its security. Include hosts, images, control planes, network policies and deployment credentials as appropriate. Keep secrets out of images, scan dependencies, limit privileges and allow only necessary connections. Containers often share a host kernel; do not assume they provide the same isolation boundary as separate virtual machines or that packaging an application removes PCI obligations.
Log Retention, Review and File Integrity
Protect the records and define who investigates
Consider an investigation into whether a suspicious URL was accessed: mismatched time zones, irregular log rotation, and missing entries can prevent a reliable answer. Centralized logging can help correlate events, but collection completeness and consistent timestamps still matter.
Collect the required events, protect audit records against unauthorized changes and synchronize system clocks with a reliable time source. Central collection can simplify correlation and access control. Where requirement 10.5.1 applies, retain at least 12 months of audit history, with the latest three months immediately available for analysis. Define and verify that availability rather than relying on an untested archive.
Under applicable 10.4 requirements, review security events and the logs of card-data systems, critical components and systems providing security functions at least daily, using automated review mechanisms. Review other in-scope system logs at the frequency defined by a targeted risk analysis. Investigate and address exceptions and anomalies. Selected alerts for login bursts, role changes, web shells or firewall changes support this process; they do not replace it. Exclude unnecessary card data and payment request bodies from application, proxy, WAF and debugging logs. Audit retention is not permission to retain sensitive authentication data.
File integrity monitoring should alert on unauthorized additions, deletions and modifications to critical files, including relevant configuration, system and payment integration files. Applicable requirement 11.5.2 calls for critical-file comparisons at least weekly. Maintain a trusted baseline and distinguish authorized deployments from unexpected changes; build-time checks alone do not cover runtime changes. This is separate from monitoring payment pages as received by a customer’s browser.
WAF Protection and Payment-Page Scripts
Automated web protection has a defined role
Where PCI DSS 6.4.2 applies to public-facing web applications, an automated technical solution must continually detect and prevent web-based attacks. This requirement became effective on 31 March 2025. A properly configured WAF is one way to meet it: place the solution before the application, keep it active and updated, generate audit logs, and either block attacks or generate alerts that are immediately investigated. Ordinary IP/port firewalling or rate limiting alone does not provide all those functions. Rate limits on login, cart and checkout endpoints can complement application protection, but do not replace patching or the applicable control.
When using a proxy or CDN WAF, prevent direct origin access from bypassing its protection. Keep a response runbook and investigate false positives; use narrowly scoped, recorded exceptions rather than broadly exempting an integration partner. Check that protective rules remain active after deployments.
Payment-page scripts need separate attention. Applicable 6.4.3 requires authorization, integrity assurance and an inventory with a business or technical reason for each script. Applicable 11.6.1 covers unauthorized changes to security-impacting HTTP headers and script content in the payment page received by the browser, with checks at least weekly or at a frequency supported by the specified targeted risk analysis. For the SAQ A r1 embedded-form eligibility criterion, merchants may use techniques such as these or obtain confirmation that the compliant payment provider’s correctly implemented solution protects the merchant page from script attacks. Distinguish the provider’s iframe content from the merchant page embedding it; reducing the script count alone does not establish eligibility.
Vulnerability Scans and Penetration Testing
Maintain a tidy setup and verify scan remediation
Applicable requirement 11.3.2 requires external vulnerability scans at least every three months by a PCI SSC Approved Scanning Vendor (ASV). Resolve findings, meet the ASV Program Guide’s passing-scan criteria and use rescans as needed to verify remediation. SAQ A e-commerce webpages remain subject to ASV scanning even when they redirect to a payment provider or embed its iframe. Define the scope with the ASV, including relevant externally accessible addresses and services; public DNS resolution alone does not determine whether a staging system or other endpoint belongs in scope. Consistent TLS, removal of forgotten services and maintained software help address findings. Refer to PCI SSC payment security resources for the official materials.
Significant changes also trigger external scans under applicable 11.3.2.1. Resolve vulnerabilities scoring 4.0 or higher under CVSS and rescan as needed. A qualified, organizationally independent tester may perform these after-change scans; being an ASV is not mandatory for that separate requirement.
Where internal scanning applies, 11.3.1 requires scans at least every three months, remediation of high-risk and critical vulnerabilities, and rescans confirming those corrections. Keep the tool current and use qualified, organizationally independent testers. Periodic internal scans use authentication with sufficient privileges; document systems unable to accept credentials. Lower-ranked vulnerabilities follow the targeted risk analysis. Also scan after significant changes and perform the required remediation and rescans; the authenticated-scanning requirement does not specifically apply to those after-change scans.
Penetration testing is a distinct activity. Applicable 11.4 requires internal and external testing at least annually and after significant infrastructure or application changes, using qualified, organizationally independent testers. Correct exploitable findings according to risk and repeat testing to verify the fixes. If segmentation reduces scope, test its effectiveness at least annually and after changes to those controls; service providers have additional, more frequent segmentation-testing requirements. Include checkout, login, administrative and API paths in the agreed methodology where relevant.
Document remediation owners, target dates and interim safeguards. A delayed patch may require an immediate exposure-reduction measure such as restricting the affected service, but the delay still needs to be resolved. A recorded exception does not waive PCI deadlines, and a temporary safeguard is not automatically an accepted compensating control. Any formal compensating-control approach must meet the standard’s criteria and assessment process.
Backup Data, Encryption and Recovery Tests
Minimize the data before protecting the copies
Accidental database deletion is one reason to maintain a practiced restore procedure. First verify what the backups contain. Keep account data only where justified by business, legal or regulatory needs, for a defined retention period, and securely remove it when no longer needed. Merchants must not retain sensitive authentication data after authorization, even when encrypted. This includes card verification codes such as CVV/CVC, full track data and PIN/PIN blocks. Logs, caches, snapshots and backups are not exceptions. Encryption does not make unnecessary or prohibited retention acceptable.
Protect necessary backups at rest and in transit with strong encryption and restricted access. Keep keys separate—don’t leave your encryption keys sitting next to the data they protect. Use controlled key-management facilities with appropriate access, rotation and recovery procedures. And keep a copy offsite. Object-storage lifecycle and any immutable retention settings must match the data-retention and deletion policy; choose them after checking the backup contents and recovery needs. For a practical workflow, see this rclone guide: rclone backups to S3/B2 with encryption and lifecycle policies.
Then there’s disaster recovery. Keep a clear runbook: who does what, where the credentials live, how to restore the database, how to warm caches, how to rotate DNS if needed, and how to verify the site is truly OK. For a plan focused on use under stress, see: Disaster recovery planning with RTO, RPO and restore tests. Practice restores in a controlled environment, verify data consistency and the checkout path, and measure recovery time and recoverable data age. This can expose missing credentials, unclear steps and unrealistic recovery assumptions.
Secrets and Configuration Management
Control secret access and deployment changes
Keep payment gateway keys, database passwords and API tokens out of source repositories, images and diagnostic output. Use a secrets manager or another controlled delivery mechanism, restrict access to the necessary services and people, and rotate compromised or shared credentials when access changes. Environment variables and .env files are delivery or storage choices, not automatic protection: prevent exposure through web roots, process inspection, logs and copied configuration. Maintain an inventory of secret owners, consumers and recovery procedures.
Version non-secret configuration where practical: web server configs, firewall rules, WAF policies, and infrastructure definitions. Review and test changes so that versioned configuration remains consistent with the running environment. For consistent server provisioning, see this practical first‑boot routine: From blank VPS to ready‑to‑serve with cloud‑init + Ansible. Being able to rebuild quickly supports recovery. If compromise is suspected, isolate the server and preserve relevant evidence before replacing it; address the cause before returning the replacement to service.
People, Access and Least Privilege
Least privilege, MFA, and small circles
A team reducing blanket sudo access could create role groups, document administrative actions and introduce approval flows for sensitive operations. Give each person only the access needed for their role and apply the MFA requirements covering administrative, remote and cardholder-data-environment access, including their specific applicability notes. Review accounts and privileges regularly; remove obsolete access and record the review. A small admin list is useful only when the remaining permissions and authentication are appropriate.
Protect control panels, dashboards and monitoring interfaces with suitable network restrictions and identity controls. Client certificates can add a layer, while a VPN or restricted management network can limit exposure; neither removes the need to meet applicable authentication requirements. Revoke departing personnel’s access immediately and rotate shared secrets they knew. Include service accounts and delegated provider access in the responsibility and access inventory.
Changes, Runbooks and Evidence
Record the control and its verification
Use controlled change windows with rollback plans and runbooks for routine tasks. A short change record should identify what changed, who approved it, when it happened and where the relevant evidence is stored. Link scan findings to the fix and rescan, and record the reason and review date for WAF exceptions. Keep operational evidence available to authorized reviewers, with access appropriate to the sensitive system details it contains.
OWASP ASVS can provide an additional framework for application-security verification. Use it to structure application checks alongside the PCI work; it does not replace PCI DSS requirements, the relevant SAQ or the evidence required by your compliance program.
Common Questions About PCI Hosting
Hosted payment page vs. on‑site capture
A provider-hosted payment flow can reduce direct handling of card data, but the integration and all eligibility criteria determine the remaining obligations. If your page instead posts card data to your backend, include the web and application path, and any affected storage or supporting systems, in the assessment. Check logs, caches and backup jobs for accidental capture. Retain only necessary, permitted data under the defined policy; sensitive authentication data must not remain after authorization, even encrypted.
“Do scans mean I’m failing at security?”
A scan identifies vulnerabilities within its defined scope and method. Controlled ingress, strong TLS, maintained software and removal of unused services help address findings but do not guarantee a pass. Fix findings, verify the corrections and update the configuration baseline. A passing scan is one piece of evidence; it does not establish overall PCI DSS compliance.
“What if I’m on a VPS or cloud? Does that change PCI?”
VPS and cloud services still require a clear responsibility split. Determine which infrastructure, operating-system, application, key-management, logging and network controls the provider operates, which you operate, and which are shared. Ask for the provider’s relevant Attestation of Compliance and verify its date, service coverage and responsibility information. Do not infer that every service is covered or that the document proves your application is compliant.
Build a Repeatable Hosting Plan
Turn the scope into assigned work
For a hypothetical store, start by mapping the payment flow and selecting an integration that avoids unnecessary card-data handling. Confirm its assessment path and document the provider/customer responsibility split. Next, verify network boundaries, administrative authentication and TLS across the edge and origin. Assign owners to server hardening, patching and restrictions on upload execution, with deadlines that satisfy the applicable requirements.
Connect each remaining control to an operating record: WAF status and incident response, log retention and review, scan schedules and remediation, permitted backup contents and restore results. Plan required testing around significant changes as well as regular intervals. Keep runbooks and rollback procedures aligned with the current deployment, and prioritize active risks and mandatory deadlines.
The resulting evidence should let the team answer concrete questions: which systems are in scope, who operates each control, when it was checked, what failed and how the correction was verified. These answers support the assessment and make gaps easier to assign and track.
Maintain the Controls as the Store Changes
Revisit the plan after payment and hosting changes
PCI hosting work continues after a scan or assessment. When payment plugins, scripts, infrastructure or personnel change, revisit the affected data flows and controls, complete the required verification and update the evidence. A repeatable routine helps maintain those obligations without treating a single security product or a completed checklist as proof of compliance.
