How can an SME erase customer data across working copies and backups?

Start with the purpose, not the delete button

A request to remove a customer profile is a useful trigger for review, but it does not by itself establish that every associated record should disappear. The Hong Kong government's explanation of Data Protection Principle 2 says personal data should not be kept longer than needed for the purpose for which it is used; it also describes the section 26 duty to take all practicable steps to erase data that is no longer required. Start a case record with the person or account concerned, the data categories, the original and directly related purposes, and the person who can decide whether each purpose has ended. An account preference, an unfulfilled order, a payment record, and a service complaint can have different purposes. Treating them as a single database row produces either premature destruction or indefinite retention.

Write the decision at the level of a record class, not a vague instruction such as 'delete user'. For each class, record the present purpose, the event that ends that purpose, any applicable legal or dispute hold to be checked by the responsible person, the system owner, and the proposed action. If a purchase record still needs to be retained, decide whether optional marketing preferences and an abandoned basket can be removed separately. Restrict access to retained material and give it a review date tied to its actual purpose. Do not silently keep a full customer profile simply because one associated transaction remains. Conversely, do not promise total erasure before checking obligations that may require a transaction record. The answer sent to the customer should reflect those distinctions in ordinary language.

Find copies that a profile screen cannot show

A workable map follows the data from collection to every place that can hold it. Include the primary application database, search index, reporting warehouse, support desk, email and messaging tools, spreadsheet exports, staff downloads, attached documents, paper files, and a processor acting for the business. Record which system is authoritative, which receives a copy, how the copy is refreshed, and who can erase or anonymise it. A database delete that leaves a search index or a monthly spreadsheet intact has not completed the operational task. Equally, a processor deletion instruction should be tied to an actual data set and acknowledgement, rather than a general contract clause with no execution trail. This map is valuable even before a request arrives because it reveals which copies have no clear owner.

Distinguish an irreversible removal from hiding a row in a user interface. An inactive flag may be appropriate while a justified retention period continues, but it is not evidence that the data has been erased. Pseudonymising a record can reduce routine exposure, yet a reversible link or another dataset may still identify the person; assess the combined data before calling it anonymous. If reporting needs only aggregate counts, remove direct identifiers at the point where individual records are no longer needed. Keep a narrow audit entry stating what action was taken, by whom, and when, while avoiding a duplicate copy of the very personal data meant to disappear. The audit entry is a control, not a substitute reason to retain the original profile.

Plan for backups and later restoration

Backups create a different problem from a live database. A point-in-time archive may contain the record even after the active system has been changed. The section 26 duty to take all practicable steps makes the backup question part of the business decision. Deleting one individual record from a mixed-retention backup may require a different technical approach from deleting a live row. Translate that operational challenge into a documented rule: identify backup sets and their expiry, limit who can restore or inspect them, and prevent expired copies from becoming an indefinite shadow archive. If individual deletion is technically possible, assess and use it. If it is not reasonably practicable, document why, how long the protected backup remains, and what will happen if it is restored. Do not call an untouched backup 'already erased'.

A restore runbook should include an erasure ledger or equivalent controlled list of post-backup changes. Before a restored copy is released to ordinary staff or customers, replay the approved removals and restrictions, check that search and downstream exports are rebuilt safely, and test a sample case. Protect the ledger itself: keep only the identifiers and evidence needed to apply the change, restrict access, and define its own retention purpose. This is an engineering pattern for meeting a recorded decision, not a claim that every backup platform has the same deletion capability. Rehearse with synthetic records so the team knows whether restoration takes hours or days and which step blocks re-exposure. A backup policy that describes expiration but never tests restoration leaves a serious gap.

Walk through one realistic customer case

Imagine a small retailer receives a former customer's request after a completed purchase and an old newsletter subscription. The account database contains address and contact details; the order system contains a historical transaction; a support ticket records a past delivery query; the campaign platform still holds an audience entry; a monthly spreadsheet was emailed to a manager; and last week's protected backup contains all of these. The case owner first verifies identity without asking for more information than necessary, then maps each record to its purpose. They stop marketing use and remove the obsolete audience entry and optional profile data once those purposes have ended. They separately assess the order record against applicable record-keeping and dispute needs, retaining only what remains justified with access limited to the relevant staff.

The technical owner records the live deletion, propagates it to the search index and reporting copy, retrieves or destroys the manager's export under a defined procedure, and obtains a specific completion response from the campaign processor. The backup owner records that a named protected backup remains until its normal expiry and that any intervening restore must replay the erasure decision before use. A second staff member checks a read-only search across the known systems, the processor response, and the restore instruction. The customer receives a precise explanation: which data was removed, which limited records remain for a stated purpose, and what happens to inaccessible backup copies. If the team cannot verify a system, it marks the case open and explains the outstanding step instead of issuing a blanket completion statement.

Make the decision repeatable

Set a regular review for record classes whose purpose can end without a customer request, such as abandoned applications or expired support attachments. Name the business owner who decides purpose and the technical owner who executes changes. Require a short evidence record of system, action, result and exception; keep that record proportionate. For a new vendor or feature, add the copy to the map before data begins flowing, and confirm the contract or operating process can support retention limits and deletion instructions. A change to a report or integration should update the map. These are small governance tasks, but they prevent the next deletion case from becoming an emergency search through staff inboxes and unknown databases.

Set explicit handoffs for a request that crosses departments. The customer-facing colleague should record what was asked and give a case owner a secure way to review it; they should not forward identity documents around ordinary email threads. The case owner makes the purpose decision, the system owners perform the approved actions, and a checker verifies the results against the data map. Where a record is held for a continuing purpose, record the reason, access restriction and next review event. If a processor cannot confirm completion, escalate that gap rather than silently closing the case. This separation makes accountability visible without pretending that an informal message from one employee proves the whole business has erased every copy.

Measure completion by evidence, not by a green status badge. A useful case record has a row for each known copy with the decision, executor, action date, verification method and any exception. Verification might be a targeted search in a system, a processor acknowledgement that names the relevant dataset, or a restore rehearsal showing that an older backup does not republish removed records. Avoid putting the customer's complete details into the evidence sheet; a controlled case identifier is usually enough to connect the steps. Review exceptions at a scheduled date. This record helps the business answer a follow-up question accurately and exposes a recurring system defect, such as a report export that cannot be traced after it leaves the application.

The important boundary is truthful communication. A case can be complete for live operational systems while a protected backup remains subject to a documented expiry and restore procedure; say exactly that if it is the verified state. A case can also remain open because an external processor has not responded; say that too. Do not describe temporary access restriction as deletion, or a planned task as finished. The operational design should make those statements easy to support with evidence. A business that knows which copies exist, why any records remain, and what restoration would do is in a stronger position than one that simply exposes a prominent 'Delete account' button.