Can You Leave? Data Export, Portability and Permanent Deletion

Every serious vendor evaluation ends with two questions, and they are almost always asked in the wrong order — last, instead of first. Can I export my data and leave whenever I want? And can I delete everything, permanently, and show that I did? By the time anyone asks, the platform holds four years of submissions, three teams depend on it, and the honest answer has become expensive to hear.

Two Different Questions That Get Conflated Constantly

«Data portability» in a procurement meeting usually means «can we migrate away». That is not what the statutory right is about, and mixing them up leads to arguments nobody wins.

The practical consequence: a respondent asking for their data is your obligation, and you discharge it with the platform's export. A vendor that cannot produce one submission in a portable format has handed you a compliance problem you will have to answer for personally. And your own exit — the thing you actually care about in the meeting — needs writing into the contract, because Swiss law will not supply it. Art. 28(3)(h) GDPR at least requires an EU processor to delete or return everything at the end of the service at the controller's choice; Art. 9 nFADP prescribes no such clause list, which is precisely why it belongs in your agreement. See do you need a data processing agreement for your form tool.

What a Usable Export Actually Contains

«We support CSV export» is not an answer, it is a format. The question is what survives the round trip.

Five Things That Rarely Survive a Migration

1. Form logic. Conditional branches, validation rules, scoring and calculations are vendor-specific and essentially never exportable. Budget for rebuilding every form, and treat that as the true cost of switching — not the data move.
2. Attachments, for the reason above.
3. Signatures. Captured as images or vector data in a proprietary field. They may export as a picture, as a text placeholder, or not at all. If the signature is the legally interesting part of the record, verify this before it matters.
4. Metadata and timestamps. Received-at, read-at, tags, internal notes and status. Many exports carry the answers and drop everything your team added around them, which is often what made the record useful.
5. Continuity of the link. The public URL of a live form belongs to the old vendor. Any QR code you printed, any link in a signed contract, any bookmark on a partner's intranet points there. Plan a redirect window, or budget for reprints.

Deleting a Record Is Not Deleting the Data

Deletion is where the honest gap between what a product shows and what a product does is widest. When you click delete, some or all of these may happen — and it is entirely reasonable to ask a vendor which:

• The row is flagged hidden and remains in the database. Common, rarely disclosed, and the reason «soft delete» belongs in every vendor questionnaire.
• The database row goes, the stored file stays. The classic orphan: a submission disappears from the inbox while its attachments sit in object storage indefinitely, referenced by nothing and deleted by nobody.
• Both go, but backups keep a copy for the backup retention period. This is normal and defensible — but it needs to be stated, with the period, and paired with a rule that restores re-apply deletions.
• Copies that left the platform are untouched: exports on laptops, notification e-mails containing answers, a data-warehouse sync, a CRM integration, a support ticket with a screenshot attached.
• Derived data persists — search indexes, aggregate statistics, audit entries. Some of it should persist: an audit log that can be edited by deleting the thing it recorded is not an audit log.

Deletion Evidence — What an Auditor Actually Asks For

Neither the nFADP nor the GDPR asks you to produce a certificate for each deleted record. What they ask, in effect, is that you can demonstrate the rule and its execution. In Switzerland the erasure claim runs through Art. 32 nFADP and the personality-protection provisions of the Civil Code rather than a standalone «right to be forgotten» article, but the practical expectation is the same as under Art. 17 GDPR. Be able to show four things:

1. The rule, in writing, per data category: how long submissions are kept, what happens at the end, and who owns the decision.
2. The mechanism — automatic where possible. A retention policy executed by a person who remembers to do it is a policy that failed on the first busy month.
3. A record that it ran: date, scope, number of records, who triggered it. Not the deleted content, which would defeat the purpose.
4. The vendor's confirmation for end-of-contract deletion, with a date. Ask for it in writing; a vendor that will not confirm deletion in writing has told you something important.

One nuance worth getting right: audit trails and deletion logs are supposed to survive the deletion. Keeping «submission 4f2a was deleted on 12 March by A. Müller» is not a failure to erase — it is the evidence that erasure happened. What must not survive is the content.

Where Encryption Helps — and Where It Cuts Both Ways

End-to-end encryption changes both halves of this article, and not entirely in one direction. On the deletion side it is a genuine advantage: if the provider only ever held ciphertext and the key never left your side, then residual copies in a backup are inert to the provider. That does not release you from deleting them, but it materially changes the risk of a copy you have not yet reached.

On the export side it forces a design question the industry mostly ducks: if the server cannot read the data, the export has to be built in the browser after local decryption. That is more engineering, and it is the reason some «encrypted» platforms quietly decrypt server-side for exports — which tells you what their encryption actually is. And the honest cost: with real end-to-end encryption, losing the key means losing the data. That is not lock-in, but it is a real operational risk, and the answer is key custody discipline rather than a weaker product.

How Schweizerform Handles Both

Same principle as the rest of this series: we publish it because we ask other vendors for it.

Getting data out

• CSV export is available on every plan, including Free. It is UTF-8 with a byte-order mark and RFC-4180 quoting, so umlauts and accents open correctly in Excel rather than turning into mojibake.
• Excel, PDF and ZIP are paid-plan formats. We would rather say that plainly than pretend otherwise: the format that carries attachments is on the paid tiers, and CSV — which always works — is not.
• The ZIP archive carries the real bytes: a spreadsheet of answers plus a files/ folder organised per submission with the original filenames, signature images included, optional AES-256 password on the archive, and an errors file listing anything that could not be decrypted rather than failing silently.
• Decryption happens in your browser. The server sends ciphertext and wrapped keys; your browser decrypts, formats the file and saves it. The only plaintext that ever exists is the file you deliberately saved — which is also the moment your own retention obligations start on that copy.

Getting data deleted

• Deleting the account is a hard delete of the database rows and the encrypted objects in Swiss storage — not a flag, and not rows-only.
• No orphans, no misdeletes. The objects to purge are recorded by their stored path inside the same database transaction that deletes the rows, so a purge can only ever touch data whose rows are already gone, and bytes cannot be left behind. Anything a crash or a storage hiccup misses stays queued and is drained by a sweeper that runs automatically in production.
• Other people's data is protected from your delete button. If you own a workspace with other members, deletion is refused until you transfer or remove it; forms you created inside someone else's workspace are re-anchored to that workspace's owner instead of being destroyed with your account.
• Audit entries survive, without you. Records of past actions are kept with the actor id removed and an e-mail snapshot retained — the evidence stays, the account does not.
• The honest caveat: deletion is immediate and irreversible, and we cannot recover a deleted account or its submissions for you afterwards. Export first if you might want the data. And because responses are encrypted to your Vault key, losing that key makes the data unreadable — the recovery path exists, but it is your discipline, not our database.

What we deliberately do not claim here is a backup-retention figure, because a number we have not published is not a promise you should rely on. Ask us — and ask every vendor — in writing, and keep the answer with a date. That is exactly the standard this article asks you to apply to us.

Run the Exit Test Before You Need It

A platform you cannot leave is not a platform you chose. It is one you are still choosing, every month, without being asked.

Bottom Line

Portability rights belong to your respondents; your exit belongs to your contract and to whatever the export button really produces. Deletion has four meanings and vendors rarely specify which one they are offering. Both questions are cheap to answer while things are going well and expensive to answer when they are not — so run the exit test now, in an hour, on a real form.

The deeper point is that lock-in is rarely a clause; it is an accumulation. Attachments that only exist behind an authenticated URL, forms whose logic nobody documented, links printed on material you cannot recall, response content scattered through mailboxes. None of it was decided. All of it is why organisations stay with tools they stopped trusting years ago — which, if you have read the hidden cost of «free» form tools, is a familiar pattern by now.