Can You Delete Data When You Need To? A Retention and Deletion Checklist for Self-Hosted Applications

Why deletion is an application-selection requirement, not only a privacy-policy task

An application can be easy to deploy, export and back up yet still be difficult to govern when information must be removed. The practical question is not simply whether the interface has a Delete button. It is whether your team can locate the relevant data, apply the right retention rule, preserve justified exceptions, and produce evidence of what happened.

This matters for personal data, but it is also an operational concern for customer records, employee data, uploaded files, comments, credentials, project material and diagnostic information. The European Commission’s GDPR guidance describes storage limitation as keeping personal data no longer than necessary and establishing time limits to erase or review it. That is a useful operating principle even where the GDPR is not the only framework that applies to your organisation.

Treat deletion capability as an adoption criterion. Assess it during a trial or proof of concept, while you can still choose a different application or design compensating controls. Do not assume self-hosting makes deletion simple: data can be distributed across the application database, persistent storage, backups, logs and connected services.

• Make retention and deletion a documented acceptance criterion alongside access control, exports, backup and restore.
• Evaluate actual deployment components, not just product documentation or interface labels.
• Require a repeatable test with sample data before placing production information in the system.
• Escalate legal, contractual and sector-specific retention questions to the appropriate internal or external advisers.

Start with a data inventory: records, files, comments, user profiles, audit events, logs, exports and derived data

You cannot reliably delete information you have not mapped. Build an inventory around data types and copies, rather than relying on a single category such as “customer data.” Begin with what users can see, then trace the technical paths that process, replicate or retain it.

For each category, record the system location, data owner, purpose, retention rule, deletion method, access roles, integrations, backup treatment and evidence source. NIST’s log-management guidance is a useful reminder that retention and disposal apply at both system and infrastructure layers; application data alone is not the full inventory.

Include derived and operational copies. A name or identifier might appear in a comment, attachment filename, exported spreadsheet, notification, search index, cache entry or log metadata. Docker documentation also notes that logging drivers can add container environment-variable and label values to log output, so review what your deployment places in those fields.

• Primary records: contacts, transactions, projects, tickets, content, forms and business objects.
• User-related data: profiles, authentication identifiers, roles, preferences and account status.
• User-generated material: uploads, attachments, comments, revisions, images and embedded documents.
• Operational data: audit events, application logs, container logs, database logs, error reports and metrics where relevant.
• Derived copies: exports, reports, search indexes, caches, previews, notifications and background-job payloads.
• Storage and resilience copies: database dumps, persistent volumes, file-store snapshots and backup archives.
• External copies: email providers, identity providers, webhook recipients, analytics platforms, automation tools and object storage.

Define the events that trigger retention, deletion, anonymisation or legal hold

A retention schedule should be event-driven. “Keep for two years” is incomplete unless everyone understands when the clock starts, what ends it, who approves an exception and how the rule is executed. Common trigger events include account closure, contract end, project completion, consent withdrawal, completed support work and an approved deletion request.

Separate deletion from anonymisation. Deletion aims to remove the identified data within the defined system scope. Anonymisation may allow a record to remain useful for reporting only if it no longer identifies an individual in the relevant context. Do not label a simple removal of a display name as anonymisation without evaluating the remaining fields and linkability.

Also define legal hold or preservation procedures before an urgent case occurs. Article 17 of the GDPR establishes a right to erasure in specified circumstances, but it is conditional rather than absolute. NIST guidance similarly calls for preservation requests to specify how affected log records are marked, stored and protected. Your workflow needs a documented way to pause routine destruction where a valid obligation applies, while limiting the hold to the affected information and reviewing it periodically.

• For every data class, define: trigger event, retention period or review interval, action, approver, exception route and evidence retained.
• State whether the action is permanent deletion, archive, restricted retention, anonymisation or pseudonymisation.
• Record the scope of a legal hold: affected matters, data sources, start date, custodian, access restrictions and review date.
• Log the reason when a deletion request is refused, delayed or only partly fulfilled.
• Define how a hold ends and how normal lifecycle processing resumes afterward.

Test what “delete” means in the application: soft deletion, permanent erasure, archive and account deactivation

Terms in an interface are not technical guarantees. “Delete,” “remove,” “archive,” “disable” and “deactivate” may produce very different outcomes. A deleted item may be hidden from normal users but remain available to administrators; an account may be unable to sign in while its profile and content remain intact; an archive may intentionally retain the complete record.

Run a controlled test using synthetic, uniquely identifiable data. Create a record, related comments, an attachment and a user account where the application permits it. Then perform each available action and inspect the expected user-facing and administrative results. Test role boundaries: can ordinary users, managers, administrators and API clients still find or retrieve the content?

If the application uses PostgreSQL, distinguish application-level visibility from immediate physical removal of old row versions. PostgreSQL explains that, under MVCC, a DELETE or UPDATE does not immediately remove the old row version; VACUUM later reclaims space for reuse. Standard VACUUM generally makes space reusable rather than returning it to the operating system, while VACUUM FULL rewrites a table to compact it. This is a database-maintenance fact, not a reason to bypass application controls or make unsupported claims about recoverability. Establish the appropriate verification standard for your use case with qualified technical and compliance stakeholders.

• Is the item absent from ordinary views, searches, APIs and administrative screens?
• Can an administrator restore it? If so, under what role and for how long?
• Does deletion cascade to child records, comments, attachments and revisions?
• Is an account deletion different from deactivation or access revocation?
• Does the application provide an export or audit record of the action without retaining unnecessary content?
• Are bulk deletion and automated retention actions available, or is manual processing the only route?

Trace related data: attachments, revisions, search indexes, notifications, caches and background-job data

A successful deletion test follows relationships, not only the main record. Start with a known marker in your synthetic record and search for it across related content. Review database tables only where you are authorised and competent to do so; otherwise, ask the application maintainer to explain the data model and provide supported evidence.

Attachments need special attention because they may live in a database, a local persistent directory or external object storage. Revisions and document previews can outlive the current version. Search indexes and caches may remain temporarily stale. Email notifications and queued background jobs may already contain copied values. Decide what delay, if any, is acceptable for each component and how you will verify eventual removal.

Object storage configuration can change the meaning of delete. AWS documents that, in a versioning-enabled S3 bucket, a delete request without a version ID adds a delete marker rather than permanently deleting the object. Permanent deletion requires deletion of the specified retained versions. If an application uses versioned object storage or a compatible service, test the exact storage behaviour and your ability to identify every relevant version.

• Record the attachment location and whether files are copied, transformed or previewed.
• Check revisions, history, trash or recycle-bin features and their expiry settings.
• Search for the test marker before and after deletion through supported application search and APIs.
• Identify cache and index refresh behaviour, including any asynchronous jobs.
• Inspect notification templates, email delivery paths and job queues for copied content.
• For external object storage, verify versioning, delete markers, lifecycle rules and deletion evidence.

Check connected systems: identity providers, email services, webhooks, analytics, automation tools and external storage

Integrations make application data more useful, but they expand the deletion boundary. An application can remove a local record while an email provider retains a notification, an automation workflow stores its payload, a webhook destination receives a copy, or an identity provider retains account attributes under its own lifecycle rules.

Document each outbound and inbound connection. For outbound flows, identify which fields are transmitted, whether a full payload or identifier is sent, whether retries or dead-letter processing retain data, and whether the recipient can delete it. For inbound flows, identify whether the external system can recreate a record after deletion.

This is also a decision point. If a critical integration cannot support your retention requirements and there is no acceptable architectural alternative, do not treat a local application Delete button as sufficient. Choose a different integration design or application.

• Identity: account identifiers, profile attributes, deprovisioning process and source-of-truth rules.
• Email: message content, attachments, delivery logs, suppression lists and retention controls.
• Webhooks and automation: payload content, retries, workflow histories, execution logs and downstream recipients.
• Analytics: event fields, identifiers, IP-related data where relevant and deletion interface.
• External storage: object lifecycle, versioning, replicas, access controls and audit records.
• Document a contact or owner for each connected system and each deletion path.

Separate live-data deletion from backup retention and restoration procedures

Live-data deletion and backup expiry solve different problems. Removing information from the production application does not automatically remove it from already-created backup archives. Conversely, expiring backups does not prove that the live application has deleted a record. Document both lifecycles explicitly.

Docker notes that a data volume persists after its container is deleted. Deleting or recreating a container is therefore not evidence that the underlying application data has been removed. Docker also documents procedures for backing up volume contents and restoring them into the same or another container volume, which is why restore paths belong in the assessment.

For an Airbip-managed application, instances run as Docker workloads on Airbip cloud servers, and Airbip provides configurable daily, weekly and monthly backups. Customers should define the required backup schedule and retention configuration, then confirm how that configuration aligns with their application-level deletion rules. Managed infrastructure can make lifecycle operations practical, but it does not decide what your organisation must retain, delete or preserve under a hold.

Test restoration safely. Restore a backup into an isolated, access-controlled environment where permitted, verify that the expected historical data is present, and confirm that it cannot be mistaken for current production data. Define who can authorise a restore, what post-restore controls apply, and how restored data is handled after the test or incident ends.

• Create a separate retention schedule for production data, backups, snapshots and exported archives.
• Identify all backup locations, frequencies, retention windows, encryption and restore authorities within your documented environment.
• State whether deletion requests affect future backups only, and how long historical copies can remain under the backup schedule.
• Test a restore procedure without overwriting production data.
• Set controls to prevent an obsolete backup restore from silently reintroducing data into production.
• Do not equate container removal, volume removal, backup expiry and media sanitisation; they are separate controls.

Assess administrator evidence: deletion logs, audit trails, exportable reports and documented limits

A deletion process is easier to defend and operate when it produces proportionate evidence. At minimum, you should be able to identify the request or trigger, the decision, the operator or automated process, the date, the systems in scope, exceptions and completion status. Avoid creating an audit trail that unnecessarily reproduces the data you were trying to remove.

Check whether the application offers audit events, administrative reports or supported APIs that can produce this evidence. If the evidence is incomplete, consider whether a documented operational record can close the gap. A manual register may be acceptable for low-volume activity, but it becomes fragile when many users, integrations or storage locations are involved.

Logging needs its own controls. NIST advises organisations to address retention, disposal, preservation and responsibility for log-management infrastructure. Docker supports multiple logging drivers and destinations. It also states that changing default logging configuration applies to newly created containers, while existing containers keep their existing configuration until recreated. Verify the deployed configuration rather than assuming a policy change has already altered every workload.

• Can you export a deletion report showing status and timestamps without exposing unnecessary sensitive content?
• Does the audit trail distinguish a user action, an administrator action and an automated retention job?
• Can you document partial completion, a legal hold or a justified refusal?
• Where do container, platform and application logs go, and who owns their retention and disposal settings?
• Do configuration changes require workload recreation before they take effect?
• Are evidence records access-controlled and retained only as long as needed?