File Conversion and GDPR: What Retention Actually Costs You

This is an engineering and procurement perspective, not legal advice. Your obligations depend on your jurisdiction, your role and your data - take the checklist to your own counsel or DPO rather than treating it as a compliance verdict.

File conversion looks like the least interesting integration in a product. You need DOCX to PDF, there are a dozen APIs, you pick one on price and move on to something that matters.

Then a security questionnaire arrives from an enterprise prospect and asks you to list every sub-processor that touches customer data, where it is located, and how long it keeps things. Suddenly the converter you chose on price is a line item you have to defend, and the answer "I think they delete files after 24 hours" is not one that closes a deal.

The uncomfortable part is that this is not really about the vendor. It is about what you inherited when you picked one.

What you actually inherit

If the files your users upload contain personal data - contracts, CVs, invoices, scans, medical documents, exports with names in them - then sending them to a third party to convert generally makes that third party a processor acting on your instructions, and a sub-processor from your own customer's point of view.

That relationship exists whether or not the vendor stores anything. It is the nature of processing, not of retention. But retention is what makes the obligations expensive, and it does so in four separate ways that are worth separating because they land on different teams:

• A period you have to justify. Personal data should not be kept longer than necessary for the purpose. "We delete after 24 hours" invites the obvious question: necessary for what? A conversion completes in seconds, so a 24-hour window is a caching or convenience decision, and you are the one who has to articulate why your users' documents sat in it.
• A location you have to disclose. Stored copies live in specific regions on specific infrastructure. That means naming the vendor, and often its own hosting provider, in your sub-processor list and your privacy notice, and keeping that list current as they change.
• Deletion requests that have to reach it. When a user exercises erasure rights, you have to be able to say the deletion propagated. If a copy of their document is in a third-party bucket, your deletion workflow has to reach into that bucket - or you have to wait out the vendor's retention window and hope.
• A breach surface that is not yours. This is the one that actually hurts. A stored corpus of customer documents is a target, and it is a target you do not control, cannot audit directly and did not harden. If it is breached, the notification obligation still runs through you to your users.

None of that is exotic. It is just work that lands on you at the least convenient moment, having been created by a decision made on price.

Retention windows are usually about cost, not about you

It is worth understanding why so many converters keep files at all, because the reason is rarely a benefit you asked for.

Storing the upload makes a vendor's engineering easier. You can retry a failed conversion without a re-upload, you can offer a download link that survives a dropped connection, you can queue work across machines without holding bytes in memory, and you can hand the customer a job id to poll. Every one of those is a legitimate design choice. None of them requires your users' documents to persist for a day, and none of them is worth much to you if the price is a sub-processor disclosure and a breach surface.

The alternative design - convert in memory, return the result, keep nothing - is harder to build and removes those conveniences. What it buys is that most of the four obligations above collapse. There is no retention period to justify, no stored copy for a deletion request to chase, and no corpus to breach. You are still using a processor, and you should still say so, but the surface you are accountable for is a request in flight rather than a database of documents.

The questions worth asking a vendor

Most conversion vendors publish a privacy policy that says the reassuring thing. These are the questions that separate policy from architecture, and they are the ones a security reviewer will eventually ask you:

1. How long are uploads kept, and is that enforced or promised? "Deleted after 1 hour" implemented as a cleanup cron is a different risk from a design where there is nothing to clean up. Ask which it is.
2. Are files written to disk at all? This is the question that actually distinguishes vendors, and it is answerable in one sentence. Anything written to disk can survive a crash, land in a snapshot, or persist in a backup nobody remembered.
3. Are filenames and metadata logged separately from contents? A frequently missed gap. Filenames carry names, case numbers, patient and client references, so a vendor that deletes contents but retains filenames in request logs is still processing personal data - just in a place their retention policy does not mention.
4. Which sub-processors and which regions? Ask about the whole chain, not just the vendor. A converter running on someone else's cloud in another jurisdiction is two disclosures, not one.
5. Is the file content used for anything other than the conversion? Training, quality sampling, analytics. Get it in writing rather than inferring it from a policy page.
6. Is a data processing agreement available on the plan I am buying? Often it is offered only on the top tier, which is worth knowing before you build rather than after procurement asks.
7. What is the breach notification path and timeline? You have obligations with clocks on them. A processor that cannot tell you quickly makes them impossible to meet.

Ask the second question first. Most of the others follow from it, because a vendor that never writes files to disk has considerably less to explain.

Where we stand on each of these

Since the list is only useful if it is answerable, here are our own answers - including the one that is a limitation rather than a selling point:

• Retention: none. Files are converted in memory and released as soon as the response is sent. There is no storage layer to expire, no job records and no file ids, which is also why there is no "fetch my previous result" endpoint - there is nothing to fetch it from.
• Disk: files are not written to persistent storage during conversion.
• Filenames: not logged. Operational logs record formats, sizes and timings so we can see whether the service is healthy, and deliberately not what anything was called.
• Content use: conversion only. Not used for training, not sampled, not shared.
• DPA: a signed DPA is available on Enterprise plans. On the self-serve plans the terms are what is published - if a signed agreement is a hard requirement for your procurement process, that is an Enterprise conversation, and better had before you integrate than after.

The privacy policy is the authoritative version of all of that, and the security page covers how it is enforced. The API docs state the same handling rules for programmatic use.

Two things this does not solve

Being straight about the limits, because a vendor page that claims to solve compliance is a page you should not trust:

First, no retention is not the same as no processing. A processor is still involved and should still appear in your documentation and your sub-processor disclosures. What changes is the scope of what you are accountable for, not whether you have to describe it.

Second, the transfer still happens. Files cross the network to be converted. That is encrypted in transit, but it is still a transfer, and if your data classification forbids certain material leaving your own infrastructure at all, then the correct answer is a self-hosted or private deployment rather than any hosted API - ours included.

The short version

Conversion is boring right up until someone audits it. The single question that decides how much work it creates for you later is whether the vendor keeps the file, because retention is what converts a transient operation into a stored copy of personal data with a location, a lifetime, a deletion obligation and a breach surface attached.

Ask that question during evaluation, when the answer is cheap, rather than during a security review when it is not.

If you are wiring this into a product, adding conversion without storing user files covers the integration itself, and bulk conversion covers doing it at volume.