Why is deletion so difficult in legacy landscapes?
A customer appears in the core system, the claims or case management system, accounting, the CRM and the archive. The systems come from different vendors, some are decades old, and the data is interdependent: a contract refers to a person, a payment to a contract.
If each system deletes on its own, gaps and contradictions arise. Some systems have their own reasons for keeping data longer. And without a response, nobody knows in the end whether the data really is gone everywhere. Manual deletion system by system is expensive and hard to prove.
What must deletion orchestration deliver?
| Requirement | Why |
|---|---|
| The right sequence | Dependent data is deleted first; no reference to already deleted data is left behind anywhere. |
| Objections | An application can object because it still needs the data. |
| Deletion holds | A legal hold stops deletions for individual cases, for example in the event of litigation. |
| Approvals | Where the risk requires it, an authorised person approves the deletion before anything is deleted. |
| Response | Each application confirms what it has deleted. |
| Monitoring | If a response is missing, an alert is raised. |
| Log | One proof per deletion run for internal audit and the regulator. |
Orchestrate centrally, delete locally
Each application knows its own data structure and business logic best. That is why it should do the deleting itself – using its existing deletion functions. Central orchestration does not interfere with the databases; it specifies what is deleted when, runs checks and collects the responses.
The applications are connected via an open interface, such as REST, or via messaging, for example with Azure Service Bus. This allows applications to be connected step by step without switching everything over at once.
Delete, anonymise or archive?
Not every application should respond in the same way. Depending on the data type and obligation, data is deleted, anonymised – for example when it is needed for statistics – or archived if a retention obligation is still running. Good orchestration lets you define this per application and records what happened in each case.
In practice
At Pax, the Swiss pension insurer based in Basel, Espresso Data Privacy has been deleting data automatically across SAP and non-SAP systems since 2024 – with deletion chains that take into account the dependencies between applications and business objects.