How to test a banking customer data deletion workflow

Banking customer data deletion workflow testing checks that a verified request moves through the bank's defined approval and processing steps, and that in-scope personal data is deleted or otherwise handled according to policy. It verifies scope, permissions, downstream systems, exceptions and completion evidence, while ensuring records that must be retained remain protected and correctly restricted.

Define the workflow and its boundaries

Start with the requirements that govern the request: who can submit it, how identity is verified, which customer records are in scope, who can approve exceptions and what constitutes completion. These rules may differ by product, data category, jurisdiction and retention schedule. Treat the bank's approved policy and applicable requirements as test inputs, rather than assuming that every record can be erased immediately.

Map the workflow from request intake to final status. A typical path includes identity checks, eligibility and retention checks, approval where required, deletion or restriction across systems, and customer notification. Identify integrations such as customer relationship management (CRM), document stores, analytics platforms and service providers. Include replicas, caches, search indexes, exports and backups where the requirements cover them.

Customer data deletion is distinct from account closure. Closing an account may leave records that the bank is required or permitted to retain. The workflow must apply the specified action to each data category: deletion, anonymisation, restriction or retention with access controls. Verify those outcomes separately.

Design tests around state, scope and control

Use state-transition tests for valid and invalid paths. Check that a request cannot be processed before identity verification, that an unauthorised user cannot approve it, and that a retention exception routes to the defined review state. Verify role permissions through the user interface and relevant application programming interfaces (APIs), where available.

Build a data inventory for the test customer and record the expected outcome for each system and data category. Use synthetic or approved masked data. Assertions should check that in-scope records are absent or transformed as specified, while retained records remain available only to permitted roles. A customer-facing screen alone cannot prove deletion from connected systems.

Exercise failure and recovery paths. For example, make one downstream service unavailable after the workflow has started. Confirm that the request remains visibly incomplete, failures are recorded for authorised operators, and retries do not skip required checks or create inconsistent states. Test duplicate submissions and repeated messages for safe, idempotent handling. Check for stale data in replicas and indexes after processing, using the system's documented consistency expectations.

Protect the audit trail. It should provide enough evidence to establish who initiated or approved an action, when it occurred, which systems reported completion and how exceptions were handled. It should not reproduce deleted personal data unnecessarily. Test access to the trail and ensure operational logs, alerts and error messages do not leak sensitive values.

Verify the outcome across systems

Define completion criteria before execution. They should specify which systems must acknowledge the action, how partial failures are represented, how long asynchronous processing may take under the test environment's requirements, and what happens if a backup is restored. Where restored data could reintroduce information, verify the approved control that reapplies deletion or prevents access.

Use controlled queries, service responses and operational status records to check the result. Avoid relying on row counts alone: unrelated records can change those counts, and a record may remain for a permitted reason. Confirm the customer's view, staff access controls and downstream system state, then reconcile each result against the data inventory. Preserve test evidence without copying sensitive customer data into reports.

Practical example

A synthetic customer submits a deletion request after closing a current account. The policy says selected profile fields can be deleted, while transaction records must be retained with access restricted. Test that the system verifies the requester, identifies both data categories, removes the in-scope profile fields from the CRM and marketing platform, and applies the specified restriction to retained transaction records.

Then make the marketing platform unavailable during processing. The expected result is a pending or failed downstream status, not a completed request. After restoring the service, retry the workflow and verify that the platform processes the action once, the request reaches the defined terminal state, retained transaction records remain available only to authorised roles, and the audit evidence records the outcome without exposing the deleted fields.

Record coverage and defects

Trace each requirement to its test cases and evidence. Record which data stores were checked, the expected treatment of each data category, and any environmental limitations, such as a backup process that cannot be exercised in the test environment. Raise defects for incorrect scope, premature completion, unauthorised processing, inconsistent downstream results or evidence that exposes sensitive data. Re-test the affected workflow and run regression checks on related customer offboarding and access-control paths.