Data Retention Policy and Customer Data Deletion in Business Applications

Most businesses are diligent about collecting data and rarely think about when to let it go. The customer database keeps growing, logs pile up for years, old backups are never deleted, and export files sit in shared folders. The more data is kept without a reason, the larger the risk surface: breaches that involve more people, needless storage costs, and legal obligations that become harder to meet.

A data retention policy answers a simple question: for each type of data, how long is it kept, why, and what happens afterward. This article explains how to draft that policy for business applications, including how to handle deletion requests from customers, manage backups and logs, and implement it in systems without breaking reports and bookkeeping obligations.

Summary

• Data retention is the rule for how long each type of data is kept and how it is destroyed or anonymized
• The basis for setting it: legal and tax obligations, operational needs, and the principle of data minimization
• Different data has different retention periods; there is no single number for everything
• Customer deletion requests need a clear flow and documented exceptions
• Backups, logs, and copies in other systems are often missed and must be part of the policy
• Automate deletion; a policy that exists only in a document is rarely carried out

Why data retention matters

There are three business reasons beyond compliance.

• Reducing risk: data that does not exist cannot leak. In a security incident, the number of affected records determines the scale of loss and notification duties. The response plan is in [cybersecurity incident response plans](/blog/rencana-respons-insiden-keamanan-siber-untuk-bisnis)
• Reducing cost: storing, backing up, and indexing old data inflates cloud bills and slows systems. See [slow database performance](/blog/performa-database-dan-aplikasi-bisnis-yang-melambat) and [controlling cloud costs](/blog/mengendalikan-biaya-cloud-untuk-bisnis)
• Improving quality: stale data, such as old phone numbers and addresses that have moved, degrades campaigns and reports. Discussed in [data quality and data governance](/blog/kualitas-data-dan-tata-kelola-data-untuk-bisnis-menengah)

From a legal perspective, Indonesia's Personal Data Protection Law expects data controllers to keep data only as long as needed for the processing purpose, and to delete or destroy it when the purpose is achieved or when the data subject requests it under the rules. On the other side, there are duties to keep certain documents, especially bookkeeping and tax documents, for periods set by regulation. These two demands do not conflict, but they must be mapped per data type. For the compliance basics, read personal data protection for websites and applications. This article is not legal advice; confirm the retention periods that apply to your sector with legal counsel or a tax consultant.

Step 1: inventory the data

You cannot set retention for data you do not know about. Make a list:

• What data is collected (name, contact, address, transaction history, photos, identity documents, location, voice recordings)
• Where it comes from (forms, point of sale, apps, integrations, purchased lists)
• Where it is stored: main database, spreadsheets, email, messaging apps, cloud storage, employee laptops
• Who has access
• What purpose it serves
• Which parties it is shared with (payment processors, couriers, marketing tools)

This inventory is also the foundation of an honest privacy policy. Many businesses are surprised to find copies of customer data in places they never expected, such as report exports downloaded years ago.

Step 2: group the data and set retention periods

Group data by its nature and legal basis for keeping, then set a period for each group.

Transaction and financial data

Invoices, payment proofs, and bookkeeping records usually must be kept for years under tax and accounting rules. This applies even if a customer requests deletion; the solution is to restrict use, not to delete. Context on electronic documents is in e-invoicing and tax compliance with ERP, and archiving in document management and digital archives with ERP.

Customer and account data

Profiles, contacts, preferences. The basis is an ongoing relationship. Set rules such as "accounts with no activity for 24 months receive a warning, then are anonymized or deleted after 30 days without a response."

Marketing data

Prospect lists, campaign results, and subscription consents. Prospect lists that never responded within a period should be cleaned. Keep records of consent and unsubscribes as long as needed to prove compliance, as discussed in email marketing and automation.

Employee and applicant data

Active employee files are kept for the employment period plus whatever labor and tax rules require. Data from rejected applicants should be deleted after a reasonable period, or kept longer only with permission. See protecting employees' personal data and recruitment and applicant tracking systems.

Logs and technical data

Access logs, error logs, and audit trails. Technical error logs can be kept briefly, for example 30 to 90 days. Audit trails for internal control are usually kept longer; see audit trails and internal controls in ERP. Make sure logs do not contain unnecessary personal data such as passwords or card numbers.

Recordings and communications

Customer service call recordings, chat history, and tickets. Keep them only as long as they are useful for service quality or disputes. Voice recordings from AI agents need special attention; see AI voice agents for customer service.

Step 3: decide the action at the end of the period

Deleting does not always mean discarding entirely. There are several options.

• Permanent deletion: the record disappears from the system and, in time, from backups
• Anonymization: identity is removed but aggregate data stays useful for analysis, such as sales per product without buyer names
• Pseudonymization: identity is replaced by a code, with the mapping key stored separately and restricted
• Restricted archive: data moves to cold storage opened only for legal needs
• Use lock: mandatory-retention data stays but is flagged so it is not used for marketing

Proper anonymization is more than deleting a name. A combination of birth date, postal code, and transaction history can often still identify someone. Test whether data after anonymization can still be linked back to a specific person.

Handling deletion requests from customers

Customers have the right to request deletion of their data under certain conditions. Prepare a flow that does not depend on any one person's memory.

Suggested flow

• Receive requests through an official channel, such as a form or dedicated email address, and record the date received
• Verify the requester's identity so data is not deleted or handed to the wrong person
• Find all locations of the requester's data using your inventory
• Determine which data must be retained due to legal duties, and explain the reason to the requester
• Delete or anonymize the rest, including in third-party processor systems
• Record the actions taken and confirm to the requester within a reasonable time

Legitimate exceptions

Bookkeeping data, ongoing disputes, and reporting duties can justify refusing part of a deletion. Document the reason. Refusing without explanation triggers complaints.

Why design this from the start

Deleting one customer from a database not built for it is hard: old orders, invoices, and reports reference customer data. Design the schema so identity data is separate from transaction data, so identity can be anonymized without breaking sales figures. The master data principles in ERP master data help here.

Backups, logs, and hidden copies

Retention policies often fail in places nobody sees.

Backups

If you delete a customer from the database but daily backups are kept for two years, the data still exists. A commonly accepted approach: let backups expire on their normal cycle, and never restore deleted data into production. If a backup is ever restored, rerun the deletion list. Also keep a deletion record that does not itself contain the personal data. Backup details are in business data backup strategy and disaster recovery plans.

Test and development environments

Copies of the production database on developer laptops or test servers are often forgotten. Use synthetic or masked data for development.

Third-party tools

Customer data may exist in marketing tools, helpdesks, analytics, and payment providers. Make sure contracts with them cover deletion and that you know how to trigger it. This data supply chain aspect lines up with real-time integrations between systems.

Export files and email attachments

Spreadsheet exports containing customer data sent by email spread without control. Limit exports, put expiry dates on sharing links, and train the team to delete temporary files.

Technical implementation in systems

Date and status columns

Add markers such as last activity date, retention basis, and retention due date. Without them, a deletion job cannot find expired data.

Scheduled jobs

Create periodic tasks that find records past their retention period and process them: flag, warn, then delete or anonymize. This kind of work suits scheduled functions, as reviewed in serverless and edge computing.

Soft and hard deletion

Soft deletion (marking a record as deleted) helps recover from mistakes but does not meet the duty to delete. Set a time limit after soft deletion, then carry out hard deletion.

Deletion audit trail

Record that a deletion occurred, when, on what policy basis, and by which process, without storing the deleted data again. This is your proof of compliance.

Testing

Test deletion in the development environment: make sure reports remain consistent, relationships do not break, and no errors occur when an anonymized customer appears in old data. Testing migrations and schema changes is covered in database migration without downtime.

Governance and habits

• Appoint a policy owner, such as the head of operations or a data protection officer
• Review the policy every year or when a new system arrives
• Include retention in the checklist when choosing vendors and building new features; see [reading software house proposals](/blog/membaca-proposal-software-house) and [key points of software development contracts](/blog/poin-penting-kontrak-pengembangan-software)
• Train the team: what may be downloaded, how long it may stay on personal devices
• Document everything in language non-technical people can understand

A simple example retention table

The following is only an illustration of how to structure it, not figures that apply to every business. Adjust to your sector's regulations.

• Invoices and bookkeeping documents: per tax and accounting rules, locked from marketing use
• Active customer profiles: for the duration of the relationship, reviewed yearly
• Inactive accounts: warning after a set period, anonymization if no response
• Prospects who did not respond: delete after several months
• Technical logs: 30 to 90 days
• Financial audit trails: per internal control and audit needs
• Rejected applicant data: delete after a reasonable period unless permission to keep exists
• Customer service recordings: per quality and dispute purposes, not forever

Frequently asked questions

Is it safer to keep everything forever?

No. Data that is not deleted still must be secured and backed up, and can become a liability in a breach. Storing without purpose also conflicts with data protection principles.

What if a customer asks for deletion but still has an invoice outstanding?

Data needed to collect payment and meet bookkeeping duties can be retained, with an explanation to the customer. The remaining data that is not needed is deleted or anonymized.

Does a small business need this too?

Yes, at a simple scale. One page listing data types, retention periods, and who is responsible is enough, plus a habit of cleaning up regularly.

Is anonymization enough?

If done properly so it cannot be linked back to a person, yes. If someone can still be identified through combined data, it is only pseudonymized and is still treated as personal data.

Conclusion

A data retention policy is not a complicated legal document but an operational habit: knowing what you keep, why, until when, and how to let it go. Start with an inventory and a one-page retention table, add markers and scheduled jobs in the system, and test the deletion flow before the first request arrives. That way risk, cost, and compliance burden fall together.