A backup restoration can bring back customer data that was previously removed
An older backup contains the customer data as it was at capture time, including records that were later erased, anonymized or suppressed on the live store. Before restoring, list every completed privacy action with its date and scope, then compare that log against the restore's actual coverage so the recovery owner knows exactly which records would reappear. The ICO's UK guidance treats erasure as conditional, so valid exceptions and restrictions must be reapplied deliberately rather than silently reversed. Keep restored records out of operational use until the reconciliation is done and the authorized owner releases the environment.
For: An authorized owner or maintainer at a research-only merchant preparing to restore an older backup after privacy actions were completed on the live store.
List the privacy actions taken since the backup was captured
The restore's risk lives in the interval between the backup's capture time and now. Pull the log of completed privacy actions from that interval: erasure requests carried out, orders anonymized, marketing suppressions applied, accounts deleted under retention settings, and any agreed restrictions on using particular records. For each, record what was done, on which system, on what date and under whose authority.
Incomplete actions belong on the same list with a different label. A request received but not yet completed, or an erasure completed in the store but not yet in the email platform, describes work a restore could strand in an inconsistent state. The recovery owner needs the full picture, not only the closed cases.
Compare the restore's scope against that log
Establish what the recovery copy actually contains: which systems and data it covers, its capture time, and whether it includes the store database, connected marketing data or only part of the installation. Then map each logged privacy action against that scope. An action on a system outside the backup survives the restore; an action on data inside the backup will be rolled back unless someone reconciles it.
Record the mapping record by record for the customers concerned, using internal references rather than their details. The output the recovery owner needs is concrete: these specific erased records would reappear in the restored store, these suppressions would be lost from the restored mailing data, these restricted records would become usable again.
Reconcile before restored records reenter use
The ICO's UK GDPR guidance on the right to erasure treats the right as conditional, with exceptions and with backup treatment requiring consideration as part of implementation. That guidance is UK-specific and does not set a universal rule, but its operational point holds: reapplying a valid completed action after a restore is part of honoring it, while an unresolved open order or legal hold is not a blanket exemption from ever acting. Which exceptions apply to your records is a question for qualified review in your jurisdiction.
Plan the reconciliation before the restore begins, not after: which valid actions will be reapplied on the restored system, by whom, and how completion will be verified. Do not silently reverse a suppression because reapplying it is inconvenient, and do not promise that erasure reached every backup copy; backups are retained for recovery, and their treatment follows the merchant's documented approach and applicable obligations.
Release the environment on evidence, not uptime
Hold restored customer data out of operational use, including marketing sends, fulfillment flows and staff workflows, until the reconciliation items are closed. The release decision belongs to the authorized owner named before the restore, and the evidence is a checked-off reconciliation list, not the fact that the site loads. Record what was reapplied, what was consciously left under a stated exception and who approved it.
If the restore also exposed that your public privacy wording promises deletion behaviors your recovery process cannot sustain, a Prism website review can examine that public wording within an agreed scope; responsibilities, fees and terms are confirmed before work. The review does not perform the reconciliation or set retention rules.
Restoration privacy checklist
Complete this before authorizing a restore, using internal references for the customers concerned. An unmapped action or an unverified reapplication keeps restored records out of use; no row authorizes reversing a valid restriction or deleting backup copies.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Restoration privacy checklist. The last column is for temporary notes.
Checklist item
What it decides for the recovery
Your finding
Privacy-action log
What it decides for the recoveryEvery erasure, anonymization, suppression, deletion and restriction completed since the backup's capture time, with dates and authorizing roles.
In-flight actions
What it decides for the recoveryRequests received but not yet completed across all systems, so the restore does not strand them in an inconsistent state.
Restore scope
What it decides for the recoveryThe backup's capture time and which systems and data it actually covers, establishing which logged actions sit inside the rollback.
Record-level mapping
What it decides for the recoveryWhich specific restored records would reappear, lose suppressions or regain usability, recorded as internal references.
Reapplication plan
What it decides for the recoveryWhich valid actions will be reapplied on the restored system, the owner of each and how completion will be verified.
Exceptions and holds
What it decides for the recoveryAny action consciously left unreapplied under a stated basis, with qualified review identified where the exception is a legal question.
Reactivation gate
What it decides for the recoveryThe authorized owner's release decision and date; restored records stay out of operational use until reconciliation items are closed.
These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.
Limits
Erasure rights, exceptions and backup obligations depend on jurisdiction; this page cites UK ICO guidance and refers legal conclusions to qualified review. No universal backup-retention rule is set here.
This checklist does not promise erasure from every backup copy and does not authorize silently reversing valid suppressions or restrictions.
Keep the affected customers' details in authorized systems; the checklist holds internal references and decisions only.
Restore mechanics and post-backup order preservation are separate decisions with their own evidence; this page covers only the privacy-action timeline.
ICO: Right to erasure — checked 2026-10-01. Under the UK guidance, the right to erasure is conditional with exceptions, and backup treatment requires consideration as part of implementation; an unresolved order is not a blanket exemption.
Prism features — checked 2026-09-21. A Prism website review examines agreed public surfaces including store policies; findings are informational and do not certify data handling or legal compliance.