¿Te worried about how switching hosting providers will affect PCI compliance, cardholder data scope, and QSA evidence? This guide provides a practical, actionable runbook and templates to migrate payment PCI scope when changing hosting providers while minimizing risk and preserving compliance with PCI DSS v4.0.
This guide focuses exclusively on migrating the PCI scope during a hosting change: inventory, network segmentation diagrams, firewall/security group examples, purge procedures for PANs in backups and caches, QSA evidence checklist, legal clauses to require from new providers, and concrete AWS/Azure/GCP commands and config examples.
Key takeaways: what to know in 1 minute
- Inventory the CDE first. Identify every system, process, and flow that handles PAN or sensitive authentication data before planning the migration.
- Aim to reduce PCI scope using hosted fields or tokenization. If possible, move PAN capture out of customer-hosted infrastructure to a PCI SAQ-reducing model to avoid transferring PANs.
- Require provider attestations and evidence up front. Request SOC 2/ISO 27001, PCI attestation, and written responsibilities in the contract before migration.
- Follow a tested runbook with rollback windows and purge steps. Include log retention transitions, backups purging, and verification steps for QSA evidence.
- Validate segmentation post-migration with isolation tests and pentest scope examples. Document test results for the QSA.
Inventory and scope mapping: find what touches cardholder data
- Create a CDE inventory spreadsheet listing servers, containers, services, endpoints, databases, caches, third-party APIs, and backup destinations that process, store, or transmit PAN or SAD.
- For each item add columns: "Data type (PAN/Token/None)", "Last PAN access (timestamp)", "Logs containing PAN (yes/no)", "Encryption at rest (Y/N) and cipher", "Owner/Team", "Current host/provider".
- Use automated discovery tools where possible (host-based scanning, EDR, network flow analysis) and validate with manual checks.
Important verification steps:
- Confirm no cleartext PANs in HTML, JavaScript, or server-side templates.
- Inspect caches (Redis, Memcached), message queues (Kafka, SQS), and job queues for stray PANs.
- Scan backups and archives for encoded PANs or full-track data.
Reference tools:
- For scanning use card data discovery tools or regular expressions carefully tuned to PAN formats.
- For network flows use VPC flow logs, Azure NSG flow logs, or GCP VPC flow logs.
Liability and legal requirements: what to contract with the new hosting provider
- Require written responsibilities for data handling, breach notification timelines (<=72 hours), and PCI-relevant attestations in the contract.
- Insist on provider evidence: recent SOC 2 Type II, ISO 27001 certificate, and if provider processes payment data, a PCI DSS Attestation of Compliance (AOC) or a written responsibility statement. Example link to standards: PCI SSC document library.
- Include clauses requiring encryption key custody controls, HSM usage (if applicable), and restrictions on backups exports.
- Require the ability to terminate and securely erase all copies of PAN and related logs within defined SLA (e.g., 7 days) and demand written proof of erasure.
Sample contract clause (language example, adapt by counsel):
- "Provider shall not access or use cardholder data except as expressly authorized, shall maintain current SOC 2/ISO 27001 attestation, provide PCI AOC where applicable, and certify secure destruction of backups containing cardholder data within X days of migration termination."
Technical migration runbook: ordered steps, windows, rollback
- Pre-migration gating (window -30 to -14 days)
- Complete CDE inventory and map data flows. Do not proceed until inventory verified.
- Confirm tokenization/hosted fields options with payment gateway to avoid transferring PANs.
- Obtain provider attestations and contract clauses.
-
Prepare test environment in new hosting provider replicating segmentation.
-
Pre-cutover tasks (window -14 to -3 days)
- Deploy segmentation controls in target (subnets, firewall/security groups, NSGs).
- Configure logging destinations (SIEM endpoints) and ensure logs land outside the CDE if required.
- Provision encryption keys or HSM access; verify key management with provider.
-
Run discovery scans against test environment and validate no PANs leaked.
-
Cutover day (window day 0)
- Put live systems into maintenance mode; suspend background jobs that write to caches or queues.
- Switch DNS and routing in controlled steps; keep old environment read-only.
- Migrate ephemeral data that is safe (non-cardholder). For PANs, avoid copying raw PANs—prefer migration via tokenization at payment provider.
-
Run validation scripts to ensure no PAN in new environment and segmentation holds.
-
Post-cutover verification (day 1–14)
- Perform external and internal scan for PANs in file systems, backups, caches, and logs.
- Run isolation tests: attempt to reach CDE systems from non-CDE subnets and validate blocked.
-
Start pentest scoped to CDE; capture results for QSA.
-
Purge and decommission (day 7–30)
- Securely delete PANs from old backups and storage following documented procedures.
- Capture proof of deletion (hash lists, secure erase logs) and store for QSA.
- Update SAQ/ROC evidence and inform acquiring bank if required.
Rollback triggers and plan:
- Define triggers such as discovery of PANs in transit, segmentation failure, or critical service outage.
- Rollback steps must be rehearsed: revert DNS, restore read/write to old environment, and preserve forensic captures.
Network segmentation and diagrams: before and after
- Before: typical hosting change without segmentation often places web, app, and database servers in flat networks where PAN touches multiple systems.
- After: recommended segmentation places public-facing web tier in one VPC/subnet, application tier in a private subnet with limited egress, and CDE database in an isolated subnet with strict inbound rules only from application tier.
Example security group / firewall rules (concrete):
- Web servers: allow inbound 443 from 0.0.0.0/0; allow outbound to application tier on TCP 443 only.
- Application servers: allow inbound from web subnet on TCP 443; allow outbound to database subnet on TCP 5432 (Postgres) or 3306 (MySQL) only.
- Database servers (CDE): allow inbound from application security group on DB port only; deny all outbound except to SIEM collector IP on TCP 514/443.
AWS security group example commands (illustrative):
- Create security group for app tier:
- aws ec2 create-security-group --group-name app-sg --description "App tier"
- aws ec2 authorize-security-group-ingress --group-id sg-app --protocol tcp --port 443 --source-group sg-web
Azure NSG example (az cli):
- az network nsg create --name cde-nsg --resource-group RG
- az network nsg rule create --nsg-name cde-nsg --name AllowAppToDb --priority 100 --access Allow --protocol Tcp --direction Inbound --source-address-prefixes 10.0.2.0/24 --destination-port-ranges 5432
GCP firewall example (gcloud):
- gcloud compute firewall-rules create allow-app-to-db --direction=INGRESS --allow=tcp:5432 --source-ranges=10.128.2.0/24 --target-tags=db-server
Network diagram (textual):
Internet → Web subnet (WAF) → App subnet (tokenizer / backend) → CDE DB subnet (isolated, HSM) → SIEM / Logging outside CDE
Table: migration options and PCI scope impact
| Migration option |
Scope impact |
Advantages |
| Rehost raw PAN to new provider |
Maintains or increases PCI scope |
Simpler migration, fewer gateway changes |
| Tokenize before migration |
Significant scope reduction |
Lower compliance effort, safer long term |
| Use hosted payment fields / redirect |
Removes web servers from PAN handling |
Best scope reduction, less QSA involvement |
Example practical: how it works really
📊 Case data:
- Variable A: 120 application servers handling payment form
- Variable B: 5 databases storing tokens, 1 DB with legacy PANs
🧮 Calculation/process: Move payment capture to hosted fields (zero PAN transit on app servers) and migrate legacy PANs to tokens. Purge PANs from legacy DB and backups with secure erasure. Re-segment DB subnet and restrict egress.
✅ Result: Scope reduction from 120 servers to 6 systems (5 token DB + token provider), estimated 85% reduction in in-scope assets and lower SAQ complexity.
Migration timeline and key checkpoints
Migration timeline: gated runbook
Pre-checks
Inventory, attestations, tokenization plan
Test & configure
Segmentation, logging, key mgmt
Cutover
DNS switch, verification scans
Validation
Isolation tests, pentest, purge old backups
Purge and data erasure: secure removal of PAN from backups and caches
- Identify all backup stores (onsite, offsite, object storage, snapshots) and list retention windows.
- For backups containing PANs, perform an extract-and-transform to remove PANs or replace with tokens, then re-encrypt and reseal backups.
- For snapshots and AMIs, create sanitized images without PANs and deprecate old images. Use cloud provider APIs to permanently delete snapshots and verify with object storage list operations.
Commands and examples:
- AWS S3: list objects, delete, and verify
- aws s3api list-objects-v2 --bucket example-bucket --prefix backups/
- aws s3 rm s3://example-bucket/backups/old-backup.tar.gz
- AWS EC2 snapshot delete: aws ec2 delete-snapshot --snapshot-id snap-0123456789abcdef0
Verification artifacts for QSA:
- Export of inventory before and after purge.
- S3 object deletion logs, snapshot delete confirmations, storage provider erase certificates.
- Hash lists and manifest showing removed files and deletion timestamps.
Segmentation validation and testing: evidence for QSA
Tests to run post-migration:
- Internal and external vulnerability scans targeted to CDE assets.
- Port and service discovery attempts from non-CDE subnets to CDE subnets (should fail).
- Penetration test focused on CDE scope boundary; include scope statement and testing results.
- Network flow proof: VPC Flow Logs or NSG flow logs showing denied attempts.
Collect for QSA:
- Diagrams before and after with CIDR ranges and security groups.
- Firewall rule listings and security group IDs with timestamps.
- Pentest report and remediation evidence.
Reference for PCI segmentation testing: PCI SSC segmentation guidance.
Cloud-specific examples: commands and configs (AWS, Azure, GCP)
AWS
- VPC subnets: create separate VPCs or subnets for CDE and non-CDE, enable flow logs.
- KMS/HSM: use AWS KMS and request CloudHSM if key separation required.
- Example: aws kms create-key --description "CDE key" --policy file://key-policy.json
Azure
- Use Azure Key Vault with tenant isolation and Managed HSM for key custody.
- NSGs with explicit deny rules for non-approved traffic.
- Example: az keyvault create --name CdeVault --resource-group RG --location eastus
GCP
- Use VPC Service Controls for perimeter security and Cloud KMS for key management.
- Set up private service connect to limit exposure of services.
Include provider documentation links:
- AWS VPC docs
- Azure networking docs
- GCP VPC docs
When to use hosted fields or tokenization versus migrating raw PAN
- Use hosted fields/redirect when web servers are currently in scope and keeping them out of PAN handling is achievable. This option often yields the largest scope reduction.
- Use tokenization when legacy PANs exist in databases and cannot be immediately retired. Tokenize then purge PANs from backups.
- If business constraints require transferring raw PANs, plan for strict segmentation, encrypted backups, and extended QSA evidence.
Advantages, risks and common mistakes
Benefits / when to apply
- ✅ Significant scope reduction when adopting hosted fields/tokenization.
- ✅ Lower ongoing audit effort and shorter SAQ scope.
- ✅ Reduced breach impact because fewer in-house systems handle PAN.
Errors to avoid / risks
- ⚠️ Copying raw PANs to new provider without contract protections. This increases risk and liability.
- ⚠️ Failing to purge backups and snapshots, which leaves residual PANs.
- ⚠️ Under-architected segmentation that allows lateral movement into CDE after migration.
Comparison pros/cons
Compare: Hosted fields vs Tokenization vs Raw PAN migration
Hosted fields
✓ Removes web from scope
✓ Fast to implement
✗ Relies on payment provider
Tokenization
✓ Reduces DB scope
✓ Keeps ownership of tokens
✗ Requires migration of legacy PANs
Raw PAN migration
✓ Minimal app changes
✗ High compliance cost
✗ Higher breach risk
Evidence checklist for QSA and SAQ changes
- Pre-migration inventory and dataflow diagrams (timestamped).
- Provider attestations: SOC 2, ISO 27001, PCI AOC (if applicable).
- Contractual clauses and proof of signed agreement.
- Logs showing backup deletions, snapshot deletions, and secure erase operations.
- Security group/firewall configs and NSG rules exports.
- Pentest and segmentation test reports.
- Key management config and HSM access proofs.
- Updated SAQ selection rationale and ROC documentation.
FAQs: common questions about migrating payment PCI scope when changing hosting providers
What is the first step when migrating PCI scope to a new host?
Identify and document the full CDE inventory and data flows, then validate whether tokenization or hosted fields can eliminate PAN transit.
Can PANs be legally transferred to a new hosting provider?
Yes, but only with proper contractual protections, encryption in transit and at rest, and provider attestations; transferring PANs increases PCI scope and risk.
How to prove to a QSA that backups were purged?
Provide deletion logs, storage provider delete confirmations, snapshot delete receipts, and a manifest showing removed file checksums.
Does using a cloud provider reduce PCI scope automatically?
No. Cloud providers offer tools for scope reduction, but architectural choices (hosted fields, tokenization, segmentation) determine scope.
What documents should be requested from a new provider?
SOC 2 Type II, ISO 27001, PCI Attestation of Compliance (if processing payment data), encryption key policies, and breach notification SLA.
How long does a hosting migration affecting PCI scope typically take?
Small migrations with tokenization can take 2–6 weeks; complex legacy PAN migrations with purges and audits can take 2–3 months depending on remediation.
Will a migration change SAQ or ROC requirements?
Yes. If scope is reduced (e.g., hosted fields), the SAQ selection may simplify; maintain detailed documentation to justify SAQ choice for the QSA.
- Inventory: export a complete list of systems and flows that touch PAN and create a CDE map.
- Contract: request SOC 2 / ISO 27001 / PCI AOC from the new provider and add secure-erasure clauses.
- Test: deploy segmentation and tokenization in a test tenant and run a PAN discovery before cutover.
