doc.cheap
Sign in Create account

Data Processing Policy — doc.cheap

Effective date: 2026-09-20 · Version: 1.0 · published at https://doc.cheap/data-processing.

This is the processor-side statement for API customers. It is part of the Terms of Service (clause 5) and applies to every account, so no signature and no negotiated agreement are needed. A customer whose own compliance process requires a counter-signed document can ask at admin@doc.cheap for the equivalent data processing agreement, which contains the same obligations clause by clause; the internal master is not published.

1. The obligations below are statutory, and survive everything else

The Terms of Service disclaim warranties, support and — as far as the law allows — liability. None of that reaches this policy. The duties of a processor under GDPR (EU) 2016/679 Art. 28 exist by force of law, not by agreement; a data subject's right to compensation under Art. 82 cannot be contracted away by either of us; and Art. 82(2) makes a processor liable where it has not complied with the duties this act directs at processors, or has acted outside or contrary to the controller's lawful instructions. Where a clause of the Terms and a clause here conflict, this policy wins on data protection.

2. Roles

  • You, the customer, are the controller of the personal data in the documents you submit. You decide why a document is processed, on what basis, and for how long its result is kept.
  • We are the processor, and we act only on your instructions.
  • For your own account — the login, the ledger, the API keys — we are the controller, and the Privacy Policy governs that.
  • We are Document Cheap Inc., Midvangur 7, 701 Egilsstaðir, Iceland, established in the EEA (the GDPR applies in Iceland through the EEA Agreement, EEA Joint Committee Decision No 154/2018), so we appoint no Art. 27 representative; our lead supervisory authority is Persónuvernd, the Icelandic Data Protection Authority.

3. Your instructions are the API call

The documented instructions of Art. 28(3)(a) are, exhaustively:

  1. each API request and the options it carries, in particular options.retain_hours;
  2. the account's history-retention setting, which applies when a request names no window of its own;
  3. anything further the two of us record in writing.

We process for no other purpose. We do not train models on your data, and we do not use it to improve recognition. If a law of the EU or of a Member State compels us to process otherwise, we tell you before doing so unless that law forbids the notice; and if we think an instruction infringes the GDPR we tell you immediately (Art. 28(3), closing subparagraph).

4. Retention and deletion

  • The uploaded image is never written to durable storage, at any setting.
  • The result is written only when the retention window resolved for the call is above zero. An explicit retain_hours in the request wins; otherwise the account setting applies.
  • retain_hours: 0 stores nothing at all — no row, nothing to read back, nothing to delete. It is the instruction to keep nothing.
  • The account setting offers 24 hours, 7 days, 30 days or one year, and defaults to one year (8760 hours). Zero is deliberately not an account state. Setting it to the shortest period your purpose needs is your responsibility as controller (Art. 5(1)(e)).
  • Expiry is enforced by physical deletion in bounded batches, not by hiding expired rows on read. Shortening the window back-dates the rows already held.
  • The non-readable micro thumbnail and the display label a retained scan may carry are held on that row and destroyed with it.
  • On the end of the service we delete the personal data and existing copies; on your written request made before then we return them first, in the API's own JSON shape (Art. 28(3)(g)). Encrypted database backups already taken expire on their own fourteen-day cycle and are not selectively edited — this is stated rather than promised away.

5. Security (Art. 28(3)(c), Art. 32)

The measures are the baseline in our internal server-hardening standard, with its threat model, and the encrypted-backup arrangement in our internal backup policy. In summary: one hardened host, key-only SSH, nothing published to the internet except through the edge tunnel, the recognition engine on an internal network only the API can address, every third-party image pinned by digest, secrets in a root-only file, nightly dumps sealed to a key whose private half never touches the server, an independent watchdog, and an allow-list scrubber on everything that leaves the process in an error report. The server's disks are not encrypted at rest, and that is disclosed rather than glossed. Everyone with access to the data is bound to confidentiality (Art. 28(3)(b)).

6. Sub-processors (Art. 28(2), (4))

We engage the hosting provider that supplies the server (Czech Republic), the edge and CDN provider that carries all traffic and terminates TLS, and the mail provider that sends transactional e-mail (Switzerland, covered by a European Commission adequacy decision). The error tracker runs on our own server and is not a third party. This is general written authorisation: we will tell account holders before adding or replacing a sub-processor, and you may object and terminate. Each is bound by the same obligations, and we remain fully liable for their performance (Art. 28(4)). The current list, with each provider's terms, is available from admin@doc.cheap on request.

7. Transfers

Processing happens in the European Union. Mail is handled in Switzerland under an adequacy decision, which is not a restricted transfer. The one transfer capable of leaving the EEA is the edge and CDN provider's global network, which operates under its own data processing addendum and the EU standard contractual clauses; where that provider decrypts HTTPS traffic cannot be pinned to the EEA on the plan in use, and that is disclosed rather than assumed away. We make no other transfer, and none without your prior instruction.

8. Assistance and breaches

  • Data-subject rights. We hold no identifier by which a document holder can be found: you locate the scan by its id or your own reference and delete it. We assist with information and, where technically possible, with deletion or export, within 5 working days of a written request (Art. 28(3)(e)).
  • Arts. 32-36. We assist with security, breach notification, impact assessment and prior consultation, taking into account the nature of the processing and what we know (Art. 28(3)(f)). Our completed impact assessment is available on request.
  • Breach. We notify you without undue delay after becoming aware of a personal data breach (Art. 33(2)). The procedure, the content of the notice and the timetable are our internal breach-notification runbook. As controller, the 72-hour notification to your own supervisory authority under Art. 33(1), and any communication to the affected people under Art. 34, remain yours.

9. Audit (Art. 28(3)(h))

We make available the information needed to demonstrate compliance with Art. 28, and allow and contribute to audits by you or an auditor you mandate. In the ordinary case an audit is documentary: the impact assessment, the processing record, the security baseline and the current audit record are offered first. An on-site or technical audit is available where those do not answer the question — once in twelve months on 30 days' notice, and more often after a breach affecting your data, during business hours, at your cost, and never in a way that exposes another customer's data.

10. What you must ensure

You are the controller, so these are yours and we cannot cure their absence:

  1. A lawful basis under Art. 6 for every document you submit.
  2. A condition under Art. 9(2) — in practice explicit consent under Art. 9(2)(a), or substantial public interest on a Union or Member State law basis under Art. 9(2)(g), an anti-money-laundering identification duty being the usual one. This is not boilerplate: an identity document carries nationality and place of birth, and the extracted field set can carry data revealing racial or ethnic origin, so Art. 9(1) engages on content alone even though nothing biometric happens here.
  3. Information to the data subject under Arts. 13-14, naming us as a processor and stating the retention you have chosen.
  4. A retention window that matches your purpose — set the account's history-retention setting, or send retain_hours per call, and send retain_hours: 0 where nothing should be kept.
  5. Submitting only documents you are entitled to process, and not using a recognition result as the sole basis of a decision about a person.