Soft delete vs hard delete: which fits regulated software?

01Why delete is the wrong default in regulated products

In a regulated workflow, a record is rarely just a record. It is evidence. A transcript request ties together who asked, who approved, what price was set, when payment cleared and when the file was released. An invoice ties a package, a customer, a status and a payment. If any of those rows can disappear, the chain breaks, and the next dispute is decided by memory instead of data. This is part of our larger guide, AI security for SaaS: protect data and pass security reviews.

Health regulation in the U.S. makes the expectation explicit. The HIPAA Security Rule requires mechanisms that record and examine activity in systems holding protected health information, and policies that protect that information from improper alteration or destruction. Other regulated industries have their own versions. The common thread is that you must be able to show what happened, and that records are not changed or destroyed without control.

Hard delete makes both harder. You cannot examine activity on a record that is gone, and an unrestricted delete button is, by definition, uncontrolled destruction.

02Soft delete vs hard delete: suppress, archive and purge

Most products have one "delete" action that is asked to do three jobs. Splitting them is the core design decision.

Suppress is the everyday action. It answers "I do not want this shown" without answering "this never existed". Archive handles lifecycle: closed accounts, retired items, former staff. Purge exists for legal erasure, retention expiry and data the user has the right to have removed, and it should be logged, reviewed and rare.

03The real costs of soft delete, and how to contain them

Soft delete has critics, and they have a point. A well-known engineering essay by Brandur Leach argues that soft deletion is often not worth it: every query has to remember to filter deleted rows, foreign keys stop protecting you, and undelete is rarely used. He suggests moving deleted rows into a separate table instead.

In regulated products we still default to keeping records, but we take those costs seriously:

• Filter in one place. Put the visibility rule in the data access layer or in database views, not in every query. A missed filter is how a suppressed record reappears in search.
• Model state, not a deleted flag. A status such as active, suppressed or archived is clearer than a timestamp named deleted_at, and it fits status-driven workflows.
• Keep the audit log separate. The audit trail should be an append-only record of events, not reconstructed from the current state of rows. Then even a purge leaves a minimal entry that something was removed, when and by whom.
• Plan the purge path. If you keep everything forever, you have a different compliance problem. Decide retention rules early and build the job that applies them.
• Test restore. If archive promises restore, test it like any other feature.

The alternative Brandur describes, a separate table of deleted records, is a reasonable way to implement archive. The point is not which mechanism you pick but that the decision is made before the first customer depends on the history.

04What an audit trail must hold

An audit trail is useful only if it answers questions people actually ask in a dispute or a review. Design it backward from those questions:

1. 01

   Who acted?

   The authenticated user, with their role at that moment, not just an account ID.

2. 02

   What changed?

   The action and the before and after values for the fields that matter.

3. 03

   On which record?

   A stable identifier that ties every event in a lifecycle together, such as one request ID across request, approval, pricing, payment and release.

4. 04

   When?

   Server time, consistently recorded.

5. 05

   Why, where it matters?

   A reason for overrides, suppressions of sensitive records and manual corrections.

Tie the whole lifecycle to one identifier from the start. Retrofitting a lifecycle ID across tables that grew separately is one of the most expensive changes we see in mature products, and it is exactly the kind of foundation work that blocks AI features later. An agent that acts in your product needs the same audit trail a person does. For how that plays out when adding agents, see how to add AI agents to an existing SaaS product without rebuilding it.

05What we see in production

In a national legal marketplace that connects court reporting agencies and attorneys, every step of a transcript order is tied to one request ID: the attorney's request, the agency's review and pricing, payment, fulfillment and release. In the second phase we replaced delete with suppress, expanded the request statuses and added audit events and in-request messaging. Agencies can keep a record out of search without breaking the history of the requests attached to it. Sealed records are suppressed automatically, and protective-order records need extra authorization. Admins have no access to transcript contents, yet the platform still keeps a full audit trail per request.

For an upgrade-package and invoicing platform serving RV dealership groups, we built five roles with access scoped by franchise, invoices that move through statuses such as Pending Financing and paid, and an activity log. Status changes, not deletions, carry the financial story of each deal.

For a fitness technology product spanning gym machine tablets, a member app and an admin portal, admin profiles use soft delete and restore across a gym, branch and super admin hierarchy. Members can delete their own records and accounts after re-entering their password. That split is the pattern in small form: staff records are archived with restore, and personal data the member owns can be erased by the member, deliberately.

In that gym product, soft delete and restore for admin accounts arrived when the client asked for one owner to run several gyms, and member ID numbers are stored encrypted.

None of these was an AI project, and that is the point. The foundations that make AI safe to add later, a lifecycle ID, status-driven records and an audit trail, are ordinary engineering decisions made early.

06A day-one checklist

1. 01

   Replace the generic delete with suppress, archive and purge, each with its own permission.

2. 02

   Put visibility filtering in one shared layer.

3. 03

   Choose one identifier that follows each business lifecycle end to end.

4. 04

   Write audit events to an append-only store with actor, role, action, record, time and reason.

5. 05

   Define retention rules and build the purge job before you need it.

6. 06

   Give users a deliberate, confirmed way to erase data they own.

7. 07

   Test restore and test that suppressed records stay hidden everywhere, including exports and search.

Frequently asked questions