Delete or defend? The question that’s causing data deletion to become a Board-level crisis

For many years, and mostly to conserve expensive storage resources, ERP data deletion has been a routine IT housekeeping job. The process was largely straightforward: the moment a record reached a defined milestone or age, it was deleted to free up storage, and then the cycle repeated itself over and over.

This is now an outdated and high-risk view of data management. 

It can expose organisations to regulatory fines, civil claims, and in some more serious cases, corporate criminal investigation.

This means that Boards must now take a more active interest in how data decisions are made and are being applied across the organisations they lead. The question now goes well beyond IT, or even the ERP business owner, asking themselves  'should we delete this?' It becomes whether the organisation can credibly defend its decision if it ever gets challenged by a regulator.

It’s a big question that changes everything about who really owns this problem.

And this is where it becomes tricky: Boards are generally accountable for decisions they cannot always see, made across systems they do not fully control, but which they are expected to defend under scrutiny. Data deletion has moved into the same category as financial reporting and risk management. It demands oversight, challenge, and evidence at the highest level. And many organisations have not caught up with this shift.

‍

The entire regulatory ground has shifted

Here's what's changed. And it’s only a snapshot:

• The UK Information Commissioner's Office (ICO) now treats failure to delete as a data protection incident. 
• The Energy sector regulator has started fining companies millions for data retention failures. 
• The Public Sector can face criminal charges for erasing records after a subject access request. 

‍

In August 2023, Ofgem imposed a £5.41 million fine on Morgan Stanley for failing to record and retain trading communications made on WhatsApp between 2018 and 2020. 

On the surface, this looks like a small policy failure where some of the firm's traders casually used an unauthorised messaging tool to communicate. But in practice, it was a data governance turning point. The regulator took a platform agnostic view to the case, instead focusing its concern on Morgan Stanley being unable to prove what it kept, why it kept it, and when it deleted it.

At a stroke, the case brought personal collaboration tools, often on personal devices, into scope. It means that regardless of platform, organisations should be routinely asking and assessing its data storage policies, even on downstream tools. 

Deletion has now become a governance problem rather than a technology problem. This means that the Board of Directors’ is now firmly in the mix. Governance committees have a fiduciary duty to understand why data is being kept for the periods it is, ensure that auditable  guardrails are in place to enforce correct tooling, and to satisfy themselves that the organisation is not deleting data before it can prove what happened if it is ever challenged.

‍

The deletion puzzle that eludes so many

Hear the word ‘deletion’ and you’d think of a binary ‘keep it or delete it’ choice. ERP data doesn't work that way.

The UK GDPR says you must delete personal data once you no longer need it for your stated purpose. This looks sensible and straightforward, but it comes with a list of exemptions: legal obligation, defence of legal claims, public task, archiving in the public interest. 

With this in mind, deletion is now much more contextual choice than it is binary.

For example, you might need to retain records for seven years because the various regulators say you must. But what if someone takes your organisation to court and your records have become evidence? Or what if a data subject requested access to their information meaning you can't delete the data until you’ve fully satisfied the request? In these two, and countless more scenarios, it is fundamental that the records stay.

This is where Boards get uncomfortable. You need a 'hold' capability that actually works, and a 'release' capability that's robust and equally defensible. The vast majority of organisations have neither.

The backup problem makes it worse. The ICO says you must delete from backups too. But if you can't overwrite backups immediately, you must put the data 'beyond use' which is  jargon for 'locked away on a schedule.' If you can't do that, you're storing personal data longer than you can justify, and that's non-compliance.

Perhaps you’re now mulling over a future where you ‘erase, erase, erase,’ if a non-compliant case rears its head. The Freedom of Information Act makes it a criminal offence to delete information after someone requests it, if you intended to prevent disclosure. The Data Protection Act creates a parallel offence for erasing personal data after a subject access request, and this law applies to the controller and to staff.

This is a deletion puzzle that so many organisations are facing: delete what they don't need, retain what they must, prove they did both. And legacy technology investments - especially ERP platforms - struggle with this because they’re designed event-based to delete rather than designed to be either evidenced or judgement-based.

‍

Where deletion doesn’t lead to destruction

The National Audit Office disclaimed the College of Policing's 2023-24 accounts after a difficult transition to the Home Office’s Metis ERP system. The NAO found unresolved migration issues, unauthorised transactions, an absence of audit trails, and difficulties providing audit evidence. Underpinning much of this was data deletion. 

This isn’t a one-off either. The NAO has also flagged inconsistent ERP configurations across UK government shared services, with data convergence difficulties creating ‘knock-on impacts’ including uncontrolled copies and uncontrolled deletion caused by various interfaces and integrations.

There is the hidden cost of deletion: most organisations think that deleting from their ERP is deletion. It isn't. Data spreads into integrations, reporting layers, data lakes, exports, shared services, archives, and even downstream systems. If you delete from the ERP and the data remains in any of those places, you haven't really deleted the data, and you’re still liable for it.

‍

What ‘provable deletion’ really means

Again, the direction that Boards need to give isn't ‘delete more data’, but ‘prove what you delete’. Framed this way, the question that the Board poses goes further than a binary ‘delete or defend’ answer.   

After all, the organisation has to do both. It must delete where the law and purpose demand it, and must defend every decision it makes along the way. Focusing on one without thinking about the other creates risk. 

Provable deletion is a capability. It means demonstrating, end-to-end, that you disposed of data lawfully, securely, and completely, while still preserving any defensible evidence where the law requires retention.

The ICO's own retention and disposal policy is a practical model. It links retention extensions to statutory or regulatory need, litigation, information requests, disputes, and public inquiries. It defines legal hold as a freeze on destruction for information relevant to legal proceedings. It expects deletion to include backups and cover all copies. And it calls out the need for records of destruction.

Here's what an operating model for provable deletion usually needs:

• Clear retention triggers. Tie deletion decisions to processing purpose, statutory obligation, and evidential need. Capture this in a retention schedule that teams actually use. This isn’t a document that sits in SharePoint, instead it’s a schedule that's part of your data governance system and is actively consulted.
• A legal hold mechanism. When litigation is threatened, a request comes in, or regulatory scrutiny arrives, you need to pause deletion, mark all of the held data, and control release after review. This can't just be a spreadsheet because it needs to be auditable and enforceable.
• A defensible backup approach. Define what 'beyond use' means in your environment. Set rotation schedules and be clear about what happens to backups. Communicate this to data subjects if relevant. Most organisations stumble with this because they treat backups as a technical rather than a governance question.
• Coverage mapping. Deletion doesn't stop at the ERP boundary. Map where data flows: integrations, reporting systems, data lakes, test environments, logs, shared services. Each place is a deletion obligation in itself.
• Evidence packs. Document detailed evidence packs. Some things you might want to document include who approved deletion, what was deleted, what couldn't be deleted and why, what was anonymised instead, and what remained under hold. You create a policy that requires these packs to be retained for as long as you might need to defend your decision.

‍

The four key deletion approaches… and where they break!

There are several deletion strategies that Boards can adopt. They suit different situations, but in reality, your organisation will need to combine them. They rarely work in isolation.

• Soft delete. In this strategy, data is retained in the database but is kept hidden from users and processes. This provides very strong traceability, especially where the audit trail is immutable. But remember, the data still exists, so questions around the impact of a breach and the lawful basis to retention will remain. A soft delete strategy breaks whenever reporting extracts or data replicas carry the data downstream.
• Hard delete. In this strategy,  records are physically removed (and mostly destroyed) from the primary database. This is a viable strategy only if you log exactly what has changed and preserve any required evidence elsewhere. The hard delete strategy often fails when interdependent tables fail, referential integrity breaks, or something that should be kept under hold is deleted. 
• Anonymisation. Here identifiers are removed so that the data is no longer identified or tied to an individual. This strategy can preserve analytical value, but it can be easily reversed or linked if the anonymisation efforts have been poorly executed. An anonymisation strategy breaks data lakes, free text fields, attachments, or metadata where hidden identifiers often hide.
• Retention hold. This approach freezes deletion for potential litigation, dispute, or regulatory cases. It is a strong approach when it is coupled with case numbering and access controls, but it breaks when data accumulates and never expires because nobody is actively reviewing them.

• Backup retention. This approach supports resilience and recovery, working if data is kept 'beyond use' and rotated out on a defined schedule. But it breaks when long-lived snapshots turn backups into a default form of permanent retention.

In most cases, a combination of approaches is often best. A retention hold when scrutiny arrives, a soft delete to retain traceability, anonymisation where data value matters but identity doesn't, and hard delete with evidence packs for everything else. 

Workday and other cloud ERP platforms have configuration options for masking, purging, and audit trails, providing capabilities that enable the Board to probe why their organisation isn’t able to do this while others do. It takes the form of a simple question: ‘if the system is able to do this, then why aren't we doing it?’

What and how much to delete reflects the level of risk that’s willing to be taken. These are not technical decisions that should be delegated to systems or teams, but should sit with the Board because they transcend operations and shape how the organisation stands up to scrutiny. If the organisation cannot evidence why a decision was taken, then it loses the ability to defend it.

We recommend the following :

• Establish clear retention schedules. They should be consistent and run across all data-generating parts of your business, with an added focus on the high-risk parts of the business: HR, finance, customer relationship and procurement. 
• Build a legal hold system. Beware of outsourcing this as a side of desk function and avoid the temptation to manage it as a spreadsheet. You should ensure the organisation implements a robust system that pauses deletion, marks data, and tracks releases.
• Make sure that data flows are mapped. You should be comfortable that the organisation knows where its ERP data goes after it leaves that ERP. The IT function should urgently map all integrations, reporting, data lakes, test systems, shared services and downstream systems. Each one is a deletion obligation. Remember that they may have integrations too, so they may need a similar treatment.
• Insist on defensibility as a design principle. Every deletion decision should come with evidence of approval, scope, exemptions, and what alternatives have been tried (like anonymisation). That evidence pack is the organisation’s defence.
• Treat backup rotation as governance, not just operations. Ensure that 'beyond use' has been defined in the environment. 

At its core, this is about control over the decisions made about the organisation’s data. Organisations that treat deletion as a deliberate, governed process will be able to meet scrutiny with confidence. Those that do not will find themselves reconstructing decisions after the fact, under pressure and without the evidence to support them. This is not a technology problem. Instead, it is about recognising how expectations are shifting and taking ownership before the organisation is forced to.