Document Capture and the GDPR: The Decisions to Make Before You Ship

Most teams treat the scan step as a user-interface detail: a camera view, a crop box, a clean image. Legally it is something else. It is the moment a document becomes personal data inside your system — with everything that follows from that, from a lawful basis to deletion.

This is not about avoiding document processing. It is about the handful of decisions that are cheap now and expensive later. If you already host in the EU, this is the practical counterpart to that choice.

The scan step is a processing operation

The moment a photo of an invoice, a delivery note or an ID card reaches your servers, you are processing personal data, and Article 6 requires a lawful basis for it. In practice that is usually contract performance (the customer asked you to handle the document) or legitimate interest, and less often consent — consent is the easiest to obtain and the hardest to live with, because it can be withdrawn.

Three duties come with it, and all three are about restraint:

• Purpose limitation — process the document for the reason you told the user, not for whatever the data might also be good for.
• Data minimisation — if you only need four fields from the invoice, you need those four fields, not a copy of the document forever.
• Storage limitation — decide how long you keep the image, before the first upload, not after the first request.

Deletion is the part vendors get vague about

"Stored securely" says nothing. The useful questions have short answers:

• When exactly is the image deleted? "After processing" is a commitment you can hold someone to. "Stored for 30 days for debugging" is a different product, and it may be fine, as long as you know.
• Is there a copy in a log, a queue, a backup? Deletion that leaves the payload in an error log is not deletion.
• Can you show it? A documented retention rule and a data processing agreement you can attach to your own records are worth more than a marketing sentence.

On our side: uploads are not stored, and the image is deleted after processing. That is a design decision, not a setting, and it is the reason we can answer the question above in one line.

The paperwork that actually matters

If you use an API or a hosted service for the scan step, that vendor is your processor, and Article 28 requires a contract for it. What belongs in it:

• Roles — who is controller, who is processor, and whether sub-processors exist.
• Subject matter and duration — what is processed, for how long.
• Technical and organisational measures — encryption in transit, access control, deletion. Article 32 asks for measures appropriate to the risk, so "appropriate" needs to be filled in.
• Assistance duties — help with data subject requests and with your own accountability.
• Transfers — if anything leaves the EU, on what basis.

A processor agreement you cannot find is worse than none, because you are still responsible for having one. Ours is published at scankit.io/dpa, alongside the privacy policy, so it can be attached to your own records without a sales conversation.

Hosting location, in one paragraph

Where the data is processed matters more than where the company is registered. If the servers are in the EU, the transfer question mostly disappears; if they are not, you need an adequacy decision or standard contractual clauses. We host in the EU and process images in the EU, which is why that is the first thing on this list rather than a footnote.

Special categories deserve a different decision

Some documents carry more than contact details: health records, ID documents, union membership, biometric data. Article 9 applies, and the bar for a lawful basis is higher. Three practical rules:

• Do not send them if you do not have to. A step that extracts an address can often work from a form instead of a photo of an ID card.
• Shorten the path. If you must, process them in the same jurisdiction, delete faster, and restrict access to the people who need it.
• Say what happens. Users are noticeably more willing to photograph a document when the retention rule is one sentence they can read.

A checklist you can run in an afternoon

1. Write down the purpose of the scan step and the lawful basis — one sentence each.
2. Write down the retention rule for the raw image, and check that it is actually implemented, not just intended.
3. Get the processor agreement and file it with your records.
4. Note the hosting and processing locations.
5. Confirm encryption in transit, and at rest if you also store the result.
6. Check what your error logs keep. Payloads do not belong there.
7. Decide whether Article 9 documents can enter the flow, and if so, how they are handled differently.
8. Give the user a visible way to ask about their document.
9. Write the deletion rule into your own notes, so the next person inherits the decision and not the guesswork.
10. Re-read it once a year. The rule takes minutes; reconstructing it later costs days.

None of this requires a lawyer for every line. It requires deciding the four or five things above before the first real document arrives, and writing them down where your team can find them.