“Please delete my data.” Removing the CRM contact is quick. The same request may still exist in email, a chat transcript, a task list and a search index. A deletion plan for a Swiss SME therefore starts by identifying where each type of information is used and for which purpose. A missing contact record does not prove that deletion is complete.
Immediately removing every document is not always the right response either. Some records may be subject to retention duties or other justified reasons for keeping them. Those cases need documented assessment. The workflow should distinguish deletion, restricted retention and information still needed for a valid purpose. One deadline applied to all customer records cannot do that job.
Organise the register by purpose
Start with information types: contact details for an open enquiry, a conversation for case handling, an invoice as a business record and technical logs for diagnosis. Record purpose, owner and systems involved. “Everything is in the CRM” is insufficient when an automation service makes copies or forwards messages elsewhere.
Follow a typical submission. A form creates an email, CRM task and perhaps a chat summary. Which identifier connects them? Which copies are necessary? Without answers, every deletion request becomes a search for filenames. A simple register with stable identifiers is often the most useful first step.
Retention rules need a reason
The Swiss FDPIC guidance on individual rights explains deletion when information is no longer required for its original purpose, alongside possible grounds for retaining it. It does not establish one period for every customer document. Assess the particular purpose and applicable duties.
A rule such as “after the enquiry closes and the defined review period ends” is more useful than an arbitrary date. Record who approves the rule and when it is reviewed. Obtain business-record requirements through the relevant accounting and legal assessment. Do not apply that period indiscriminately to chat histories, marketing contacts or diagnostic logs.
A small starting register
| Information | Review trigger | Evidence |
|---|---|---|
| Open enquiry | Completed or abandoned. | Status and responsible person. |
| Conversation copy | Handling purpose ends. | Systems affected and steps performed. |
| Business record | Applicable retention requirement. | Documented duty and access restriction. |
| Technical log | Defined diagnostic period expires. | Expiry rule and execution check. |
This is an operational template, not a universal statutory retention table. Add rules specific to the business. Where information serves several purposes, distinguish them. An invoice address may be needed for the retained record without justifying continued marketing messages to that person.
Make the request traceable
Receive the request, perform the necessary identity check and identify the relevant records. Ask only for proportionate evidence. A general email address may be ambiguous; a complete identity-document copy may create unnecessary material. Define verification according to the actual information and access involved.
Decide and execute separately for each system. One record can be removed while another remains restricted under a verified retention ground. Document reason, scope and owner. The reply should describe what was actually completed. “Everything has been deleted” is unsuitable when an archive or external service remains unexamined.
What a knowledge chatbot adds
The FDPIC guidance on everyday AI confirms that purpose limitation and proportionality apply there too. If customer documents enter a knowledge-search collection, deleting the original alone may be insufficient. The index can contain passages, metadata and references. Use stable document identifiers to find and remove these entries or rebuild them appropriately. Afterwards, test whether retrieval still returns the removed material.
Include caches and previously prepared answers. An old passage should not reappear from a cache after its source was removed. Separate general knowledge material from personal case data where the workflow permits. Fewer unnecessary copies make later deletion easier and reduce the number of locations you must verify.
Backups and restoration
Document the treatment of backups separately. Ask each provider which deletion mechanisms exist and when backup sets expire. An active deletion should not be silently reversed during a later restoration. A minimal deletion register with suitable identifiers may be needed for that reconciliation; give it a limited purpose and restricted access too.
Test restoration with fictional records. Delete a test contact, restore an earlier test instance and check the subsequent reconciliation. This is a proposed procedure, not a customer case report. It establishes whether the rule survives an operational recovery rather than working only during ordinary operation.
Include your suppliers
Record which services receive information and how a request is executed there. Closing the local contact does not automatically remove its copy in a support platform. Ask about execution, acknowledgement and backups. Where no automated interface exists, assign a person and require a verifiable confirmation for the manual step.
Review recurring imports as well. A nightly sync from an old spreadsheet can recreate a recently deleted marketing contact. The process must account for the source and the next synchronisation. Otherwise deletion technically succeeds and becomes ineffective again the following morning.
Check the plan in normal operations
Review expired records, unfinished requests and missing acknowledgements. Also choose a fictional test record whose path you follow across the systems. That tests the process without distributing real customer information unnecessarily. Keep only the evidence needed for the check.
Give the operating team a simple way to report a new destination. Adding a notification service or search feature can create another copy that the current register does not describe. Include that update in the release checklist. A register nobody maintains becomes an old diagram rather than a working deletion plan.
Make the status clear without copying the content
The case owner should be able to identify unfinished steps without copying the material being deleted into another spreadsheet. Depending on the actual need, a limited reference, system name and processing status may suffice. Define when this evidence is no longer needed and should itself be removed. The register should not quietly become a second complete customer database.
If two accounts share a contact address, check which records the request concerns and which association has been verified. A broad email search could otherwise affect unrelated or still-needed entries. Test this with fictional contacts sharing some attributes. The workflow should either identify the proper scope or request clarification.
Our article on phone-assistant data privacy covers earlier design decisions. For process automation, bring information types, connected systems and current deletion steps. They provide a basis for an executable plan that handles exceptions visibly and can demonstrate completion.
Swiss payment documents need separate checks. Our guide to automated QR-invoice processing distinguishes extracted data, duplicate review and actual payment approval.
FAQ
Does one retention period cover every customer record?
No. Assess purpose and applicable duties for each information type. A business-record requirement cannot automatically be applied to marketing contacts or diagnostic logs.
Should the plan cover the search index?
If personal material is processed there, include the index. Remove affected passages and metadata using suitable identifiers, then check retrieval and relevant caches.
How can deleted information be kept from returning?
Account for restoration and recurring imports. A limited record of completed deletions can help reconciliation. Define the purpose, access and retention of that record as well.