Are backup and disaster recovery sites in PCI DSS scope

Are backup and disaster recovery sites in PCI DSS scope?

A hot or warm disaster recovery site is in PCI DSS scope, and so is any backup that holds cardholder data. A cold site with no cardholder data environment (CDE) systems, no stored account data and no connection to the CDE may be out of scope while it sits unused, but it must meet every applicable requirement once it is activated. The answer for your design depends on three things: what the copy contains, how it connects to the CDE, and whether it can be brought into service quickly. A site that holds running systems, ready-to-restore images or cryptographic key components is treated as part of the CDE from the start, not at the moment of a disaster.

Start with an inventory of every copy of account data your plan creates: replicated databases, snapshots, tape or object storage, log archives and any cloud region that receives them. For each copy, record its location, its encryption and key location, who can restore it and how long it persists. Ask whether activation would require a switch of network paths or only a restore. Those answers determine the scope boundary, and your QSA will test them against your data-flow and network diagrams. The organization owns the scope decision and documents it. The QSA independently validates that decision during the assessment, and any significant change to storage or data flows, such as a new replication target, should trigger a scope review.

Confirm the rules for deletion and testing before you sign off the design. PCI SSC FAQ 1323 says cardholder data must be securely deleted from a DR site when its use ends, and that simulated activation is in scope when it involves cardholder data or components that affect its security. Ask your cloud or hosting provider how it meets the deletion requirement for every geographic copy, and get that answer in writing. Keep an offline backup location review on a 12-month cycle and a media inventory covering backup media. Those recurring tasks are what an assessor asks to see, so build them into the plan now.

How hot, warm and cold sites change the scope answer

Whether a disaster recovery environment is in PCI DSS scope depends on what it holds and whether it can run cardholder data systems right now. The cards below walk through each site type and backup store, with the condition that moves it in or out of scope.

Hot site with a running CDE copy

A hot site runs CDE systems continuously, so it sits inside the cardholder data environment and needs every applicable requirement met. Under FAQ 1323, a running or ready copy of CDE systems puts the site in scope. Check that the site is covered by the same network controls, access reviews, logging and vulnerability scanning as production, and that its records appear in your scope documentation and data-flow diagrams.

Warm site with ready cardholder data

A warm site holds systems or data that can be brought online with some preparation, and the SSC treats it as in scope for the same reason as a hot site. Confirm which components are staged there, including configuration files, cryptographic keys and database copies. Each staged component counts, even when no traffic flows through the site during normal operation.

Cold site with no CDE connection

A cold site holds no CDE systems, no cardholder data and no connection to the CDE, so it may sit outside scope while unused. The condition that changes this is activation: once it is brought into service, all applicable requirements apply. Ask whether any sync job, replication link or staged image would push data to the site, because a single data flow can move a cold site into scope.

Backup-only stores and tape

Backups of cardholder data are in scope wherever they live, including tape, object storage and replicated volumes, because Requirement 3.5 covers non-primary storage such as backups. Inventory each copy, confirm encryption and access controls apply, and check that the offline backup locations are reviewed at least once every 12 months under Requirement 9.4.1.2. Cloud copies also count as geographic copies that must be deleted when the retention period ends.

Cloud and geographic replicas

A replica in another region or with a cloud provider holds cardholder data even when no one queries it. Under the SAQ D note to Requirement 3.2.1, you must work with a provider that stores account data to understand how deletion covers all geographic copies. Ask the provider to show how it deletes every replica, including snapshots and cross-region copies, and record the answer in your third-party responsibility records.

Changes that trigger a scope review

Moving a site from cold to warm, adding a replication job or changing where backups are stored are all significant changes under FAQ 1317. Each one can change the scope answer for a DR site, so route them through your change process. Re-check the scope determination and update the data-flow diagram before the change goes live, not after an audit finds it.

Which copies of cardholder data count as backups

Any copy of cardholder data that can be restored is in scope, whatever it is called. For a disaster recovery program, that includes backup sets, database snapshots, replicated volumes, audit logs and troubleshooting logs that happen to contain a primary account number. The SAQ D notes to Requirement 3.5 make clear that protection of stored account data reaches non-primary storage such as backups, audit logs and troubleshooting logs, so the copy does not need to be the system of record to carry the same obligations. Start by listing every backup job, replication target, snapshot policy and log sink that touches the cardholder data environment, then confirm for each one whether the data inside is readable and whether the store holds cardholder data at all.

Cryptographic keys are treated as components that affect security, so a DR site holding them is in scope even if it holds no card data. A recovery site that can decrypt a backup needs the key material, key custodians, key-encrypting keys and the systems that manage them. Check whether key backups are stored separately from the encrypted data, who can restore them, and whether the key store is covered by the same access and logging controls as the production key management system. The same reasoning applies to replication and cloud copies. A snapshot in another region, a cross-account bucket or a managed database replica is a copy, and the analysis is the same as for a tape in a vault. Ask your cloud provider how each geographic copy is created, where it is stored and how it is deleted, and record the answers before you decide the copy is out of scope.

How DR activation and testing affect the scope review

This sequence shows how a disaster recovery design, its copies of cardholder data, and its test activations each feed the scope decision, so the merchant or service provider can prove the DR site is in or out of the CDE and stays that way after changes.

Map the DR design against the CDE
Start by listing every DR configuration the organization uses or plans to use: hot, warm or cold sites, standby virtual machines, replicated databases, backup repositories and any cloud copies. For each one, record whether it runs CDE systems, holds backups of cardholder data, or stores components such as cryptographic keys. Hot and warm sites with a running or ready copy of CDE systems, or with backups of cardholder data or key components, fall in scope. A cold site with no CDE systems, data or connection may be out of scope while idle, but it must meet all applicable requirements once activated. The output is a DR inventory tied to the CDE boundary diagram, reviewed by the network and data-flow owner and signed off by the compliance lead.
Confirm which copies hold account data
Trace the account data path into each DR copy. Check replication jobs, backup schedules, snapshot policies, log shipping and troubleshooting exports, since non-primary storage such as backups and logs falls under the storage requirements in the same way as primary systems. For cloud or third-party copies, obtain the provider's written explanation of how it meets the relevant requirement, including deletion of all geographic copies. The output is a copy register that lists each location, the data type, the encryption and key custody model, and the named owner. Engineers should be able to reproduce each entry from configuration, not from memory.
Run a simulated activation with scoped data
Plan a DR test that activates the recovery environment as it would run in an incident. If the simulation involves cardholder data, or uses components that affect the security of that data, the test itself is in scope. Use a controlled test data set where possible, restrict who can access the recovery environment during the exercise, and keep the same logging, access control and change management that apply to production. Record the start and end times, the systems activated, and the people involved. The output is an approved test plan and a signed activity record that the assessor can match to the DR inventory.
Verify deletion and access after the test
Once the test or any real failover ends, confirm that cardholder data created or copied during the exercise has been securely deleted from the recovery site when its use ends. Check that temporary access accounts were removed, that keys and credentials used in the test were rotated where required, and that logs of the activation were retained and protected. The output is a closure checklist with evidence of each deletion, such as system reports or deletion job logs, and a named reviewer who confirms that the recovery site returned to its approved state.
Record test results and gaps
Document what the test proved and what it did not. Compare actual recovery behavior with the DR design, noting any copy that appeared outside the register, any control that was missing in the recovery environment, and any step where cardholder data moved to an unplanned location. Log each gap with an owner and a remediation decision. The output is a test report that links every finding to a control, a system and a status, which becomes evidence for the annual review of offline backup security and media inventories.
Trigger a scope review on significant change
Compare the test results and any new DR architecture against the triggers for a scope review. Under the significant change guidance, a scope review is needed when new CDE hardware or software is added, when data flows or storage change, or when the CDE boundary or supporting infrastructure changes. A new replication target, a new cloud region or a changed backup retention setting may each meet that test. The output is a documented decision: either the change is recorded as a scope-neutral update with reasons, or the DR inventory, network diagram and data-flow diagram are revised and the validation scope is updated before the next assessment.
Carry the results into the assessment file
Give the QSA or internal assessor the DR inventory, copy register, test plan, closure evidence, gap log and scope review decision as one package. Confirm that the package matches the current network and data-flow diagrams and the stated scope. Ask the assessor to confirm which items they will sample. The output is an assessment evidence index that shows each DR copy, its status and the proof behind it, so the scope statement in the Report on Compliance or the self-assessment questionnaire can be defended without reconstruction.

Protecting backups and deleting cardholder data across copies

A backup of cardholder data is stored account data, so it needs the same core protections as the primary database. Requirement 3 covers protection of stored account data, and the SAQ D guidance on 3.5.1 makes clear that it extends to non-primary storage such as backups, audit logs and troubleshooting logs. Requirement 7 then governs who can reach those copies, on a need-to-know basis. Assessors usually look at the backup platform itself as well as the data, because a well-encrypted archive can still be exposed through an over-privileged administrator account.

Encryption of the backup set: Confirm that cardholder data in backup files, snapshots and replicas is rendered unreadable and that the key management approach is documented.
Key separation: Check whether backup encryption keys are held apart from the backup store, and who can use them to restore.
Access restricted by need to know: Review which roles can list, copy, restore or export backup sets, and remove standing access that a restore process does not need.
Logging of backup access: Confirm that restores, exports and configuration changes to the backup platform are logged and reviewed.
Scope of the backup platform: Decide whether the backup software, its management console and its administrators are in the CDE, since they can reach the data.

Before you rely on this tab, confirm with the people who run backups which copies exist today, not only the ones in the original design.

What makes the DR scope larger or smaller

A disaster recovery site is in scope to the degree it holds cardholder data or components that protect it. Five levers decide how much of your DR estate falls under PCI DSS: how many copies exist, who holds them, how often they change, who can restore them, and how often you prove the recovery works.

Number of geographic copies

Every region, data center or cloud zone holding a copy of PAN is another place the standard applies, and each one needs its own deletion path when data reaches end of use. Ask for a map of every location that holds a copy, including snapshots, replicas and cold media. Reducing the count of copies, or keeping PAN in one primary region with tokens elsewhere, shrinks the set of sites you must secure, monitor and clean up.

Cloud providers holding account data

When a cloud provider stores backups or replicas of cardholder data, you still own the outcome. The SAQ D guidance on Requirement 3.2.1 expects you to work with that provider to understand how deletion reaches all geographic copies. Confirm in writing which provider services hold account data and obtain the provider's current PCI DSS responsibility documentation before you choose the region.

Replication frequency

Continuous replication keeps a warm DR site close to live data, so every change in production flows into it immediately and the site stays in scope as an active CDE extension. Less frequent snapshots create older copies that may hold PAN longer than your retention rule allows. Document the replication schedule, the retention period of each snapshot, and which copies are kept for longer than the primary.

People with restore access

Anyone who can restore a backup or start a DR environment can read the cardholder data it contains, so restore rights are part of your access control scope. Limit restore permissions to named roles, require approval for each restore, and review the list on a schedule. Keep the restore access list short and reviewed, because each added name extends the set of people who must be covered by your access controls.

Frequency of DR tests

Simulated activation with live cardholder data or with components that affect its security is in scope. Testing with synthetic data, or with a restored copy that has PAN masked or removed, keeps the test environment out of the DR scope. Schedule tests, record whether real card data was used, and delete any test copies once the exercise ends so they do not become stray storage.

Options for a DR design: in scope, out of scope or reduced

This table compares three ways to design a disaster recovery site for cardholder data: a full-copy hot or warm site, a cold site with no data or connection, and a tokenized design that keeps only tokens outside the CDE. Read each row as a question to answer with your QSA before the design is built, since the scope outcome depends on what the site actually holds at each point in time.

Design option	Scope position and what it means	When it fits and what to bring to the QSA
Full-copy hot or warm site	In scope. A running or ready copy of CDE systems, cardholder data backups or cryptographic keys brings the site under all applicable requirements.	Fits when recovery time needs a live environment. Evidence covers the full requirement set, including access reviews, logging, file integrity monitoring and deletion records for every geographic copy.
Cold site with no data and no connection	Out of scope while unused, provided it holds no CDE systems, data or connection. All applicable requirements apply once it is activated.	Fits when recovery can tolerate rebuild time. Keep dated records showing no data, no connection and no staged keys, and plan activation as a significant change to scope.
Tokenized or non-PAN design	Only tokens sit outside the CDE if the token vault and detokenization stay inside it. The DR site then needs no PAN to run payment functions, which narrows what must be assessed there.	Fits when the business can run recovery without raw PAN. Confirm with the QSA that the token service and any keys remain in the CDE and that no PAN reaches the DR network.
Backups of cardholder data	Backups are in scope wherever they reside, including cloud copies and offline media. Requirement 3.5 covers non-primary storage such as backups and logs.	Applies to every option that keeps any backup containing PAN. Evidence includes media inventories, offline location reviews and deletion logs for each copy.
Testing and simulated activation	Testing is in scope if it uses cardholder data or components that affect the security of the data.	Plan tests with synthetic data where possible. Record which test data was used so the QSA can confirm the test did not bring the site into scope unnoticed.
Cloud provider copies	The provider's share of control depends on the service. Obtain the provider's responsibility matrix and confirm deletion of all geographic copies.	Applies when the DR copy sits in a third-party region. Ask the provider for its PCI DSS attestation and written evidence of how it meets deletion and encryption duties.
Scope change triggers	Activating a site, moving data into it or changing the data flow are significant changes that prompt a scope review.	Document each trigger in the change process so the scope confirmation reflects the current design rather than the original plan.

What evidence the QSA will ask to see

A QSA testing a disaster recovery site starts with the documents that show where cardholder data lives and whether that answer is current. The organization produces and owns this evidence; the QSA tests it. Expect to provide updated data-flow and network diagrams that show every DR copy, every replication path and every connection between the primary CDE and the recovery site, along with a written DR scope statement that classifies the site as hot, warm or cold and explains why. For a cold site, the statement should show that no CDE systems, data or connections exist while the site is idle, and it should name the activation steps that bring it into scope. Confirm with your QSA which format they accept for these diagrams before you build them.

The assessor will then test whether the copies are controlled. Ask for activation test records that show what was tested, which cardholder data or cryptographic components were present during the test, who approved it, and how the test data was removed afterward, since PCI SSC FAQ 1323 treats DR testing that involves cardholder data as in scope. Pair these with deletion logs for each copy, covering the primary database, replicas, backup sets, cloud snapshots and any geographic copies held by a provider. Where a cloud provider holds the data, the assessor will also want the provider's responsibility documentation showing how it deletes every copy, as the SAQ D guidance on Requirement 3.2.1 requires.

Finally, the QSA will check the recurring tasks that keep backups and DR media under control. The 9.4.5.1 media inventory must list electronic media holding cardholder data and be refreshed at least every 12 months, so backup tapes, drives and archive volumes belong on it. The 9.4.1.2 offline backup review must document the security of each offline backup location and show that the review happened within the last 12 months. Ask your team now whether these records exist for every site, and whether a significant change such as a new replication path has triggered a scope review under PCI SSC FAQ 1317.

Who owns the scope decision, the DR build and the assessment

Your organization owns the scope decision for every DR site, backup store and cloud copy. That includes deciding whether a site is hot, warm or cold, whether it holds cardholder data or components such as cryptographic keys, and when its status changes. Your team also owns the controls that apply to those copies and the decision to keep or delete cardholder data once its use ends. No outside party can make these calls for you.

Scope determination: Record which DR sites and backup stores hold CDE systems, cardholder data or key material, and reconfirm the record after significant changes.
Retention and deletion rules: Set the retention period for each copy and approve the deletion procedure for every geographic location.
Control ownership: Assign named owners for backup encryption, access to backup media and the periodic review of offline backup locations.
Activation and test approval: Authorize when a cold site is activated and approve any DR test that uses real cardholder data.
Provider oversight: Obtain and review evidence from any cloud or backup provider that stores account data for you.

Check that someone on your team can name the owner of every backup copy and explain why each one is in or out of scope.

Frequently asked questions about DR sites and PCI DSS scope

Is a cold DR site always out of PCI DSS scope?

No. A cold site with no CDE systems, no cardholder data and no connection to the cardholder data environment may be out of scope while it sits unused. The moment you activate it, it must meet every applicable requirement. Hot and warm sites that run or hold ready copies of CDE systems, cardholder data backups or cryptographic keys are in scope at all times. The practical test is whether the site could hold card data or affect the security of the CDE once it is switched on. Document that reasoning in your scope confirmation, and review it whenever the site's configuration, data flows or connections change. Confirm the boundary with your QSA before you rely on it.

Do we have to test DR with live card data?

Not necessarily, but the test is in scope if it involves cardholder data or components that affect the security of that data. A simulated activation that uses real card data, real keys or live production connections brings the test environment under the same controls as the site itself. Many teams reduce that exposure by testing with synthetic or masked data, by limiting which systems are switched on, and by keeping test access under the same controls as production access. Whatever you choose, record the test scope, the data used and the deletion steps afterward. Ask your assessor how they want that evidence presented.

Does a cloud backup in another region count toward scope?

Yes, if it holds cardholder data. Geographic copies count as stored account data, wherever they sit. Requirement 3.5 also reaches non-primary storage such as backups, audit logs and troubleshooting logs. If a cloud provider stores your account data, work with that provider to understand how it meets the requirement, including deletion of every geographic copy. Ask the provider for its PCI DSS Attestation of Compliance, the services covered by that attestation, and the shared responsibility split for storage, encryption and key management. Confirm the replication settings, snapshot retention and deletion procedure for every region, because a forgotten replica is a common gap.

How often must offline backups be reviewed?

At least once every 12 months. Requirement 9.4.5.1 calls for inventories of electronic media that hold cardholder data at the same interval, and Requirement 9.4.1.2 calls for the security of offline backup locations to be reviewed on that cycle. Your assessor will expect dated records, a list of the media and locations reviewed, the findings and the actions taken. Many organizations schedule these reviews alongside the annual scope confirmation so that the backup inventory, the retention settings and the physical location checks are reviewed together. Confirm the exact wording and evidence expectations with your QSA for your validation type.

Can we do this ourselves?

Often yes, if you have staff who understand your architecture, your data flows and the relevant requirements. Your organization owns its controls and must be able to show them. Internal work typically covers mapping every DR site, backup store and cloud copy, confirming which ones hold cardholder data, setting deletion and retention rules, and keeping dated evidence. Outside help is most useful for preparing systems and evidence, testing controls and checking your scope reasoning before assessment. Only an independent Qualified Security Assessor (QSA) can issue a Report on Compliance, and only a QSA or the correct self-assessment questionnaire with its Attestation of Compliance documents validation. Where a QSA will assess the environment, agree the boundary with them early.

What does it cost and how long does it take?

The cost depends on how many DR sites, backup stores and cloud copies you run, whether they hold cardholder data, how many regions are involved and which validation type applies. Those factors also set the effort for scope reduction, testing and evidence. No cost or duration figures are supplied for this topic, so ask for them in writing. A fixed-scope quote from DeployOpen follows from an agreed written scope covering the systems, deliverables and timeline. Ask any consultant or assessor to separate one-time work, such as mapping and remediation, from recurring work, such as annual reviews, deletion checks and retesting. Ask your QSA for their own fee breakdown, since assessment and consulting must remain independent.

How DeployOpen prepares DR scope and evidence for assessment

DeployOpen works as an implementation partner on the disaster recovery and backup side of a payment environment. Before any build work starts, we agree the scope in writing: which DR site type is in use (hot, warm or cold), which backup stores, cloud copies and log archives may hold cardholder data, and which systems would be activated and tested. We then plan, configure and document those systems inside your own cloud accounts, data centers or private network. Your organization keeps ownership of the controls, the decisions about what is in scope, and the assessment itself. We do not decide scope on your behalf, and we do not issue reports, attestations or certificates. Only your independent Qualified Security Assessor can do that, and we do not guarantee any assessment result.

The evidence work is where most DR gaps appear, so we focus it there. For each in-scope copy we prepare a deletion procedure that covers every geographic replica, including copies held by a cloud provider, and we record how the provider's responsibilities were confirmed. We build the review routines for offline backup locations and the electronic media inventory that Requirements 9.4.1.2 and 9.4.5.1 require at least every 12 months, and we set up the logs and configuration exports that show those reviews happened. Where a DR test would use live cardholder data, we document how that test is controlled. Ask us to show you the artifacts before the assessor arrives, and ask your QSA which of them they will accept.

Before engagement, confirm three things with your assessor and your payment brand: which DR configuration they consider in scope, which evidence formats they accept, and whether any change to DR design would count as a significant change under the scope review process. We can then hand over a written package of diagrams, procedures, inventories and test records that maps directly to what the assessor will sample. Scope, deliverables and timelines are fixed in the agreement before work begins, and any later changes to the DR design are handled through the same written scope.

Are backup and disaster recovery sites in PCI DSS scope