Data Processing Agreement
GDPR Article 28 — Last updated: May 2026
This Data Processing Agreement (“DPA”) governs the provision of DocuFlag where the customer is acting as a data controller on behalf of one or more visa applicants — typically on the Enterprise plan. Individual self-help users of DocuFlag process only their own personal data and are not in a controller–processor relationship; for them, our Privacy Policy is the governing document.
Where it applies, this DPA forms part of the agreement between the customer (“Controller”) and DocuFlag (“Processor”) for the provision of the DocuFlag service. It is entered into pursuant to Article 28 of the General Data Protection Regulation (EU) 2016/679 (“GDPR”).
1. Definitions
- “Controller” means the customer who uses DocuFlag on the contracted Enterprise plan to process visa applicants’ personal data on those applicants’ behalf — typically a visa agency or other organisation handling applications at volume. (Individual self-help users on the Free plan, processing only their own data, are NOT a Controller for the purposes of this DPA — they are themselves the Data Subject and their relationship with us is governed by the Privacy Policy.)
- “Processor” means DocuFlag (operated by DocuFlag).
- “Data Subjects” means the visa applicants whose personal data is processed through the service.
- “Personal Data” means any information relating to an identified or identifiable natural person processed under this DPA.
- “Sub-processor” means any third party engaged by the Processor to process Personal Data on behalf of the Controller.
- “Data Breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data.
2. Scope of processing
| Subject matter | AI-assisted document compliance checking for Schengen visa applications |
| Duration | For the term of the Controller's DocuFlag subscription |
| Nature of processing | Automated analysis of documents against published consulate requirements via EU-hosted infrastructure and AI |
| Purpose | To assist the Controller in verifying that visa applicants’ documents meet published consulate requirements |
| Categories of data subjects | Visa applicants whose documents are submitted by the Controller |
| Types of personal data |
|
Special category data (Article 9). The Processor does not perform facial recognition, biometric matching, or identity verification — the analysis extracts structured text fields (passport number, names, dates, machine-readable-zone characters) from documents for comparison against published consulate requirements. Under the ICO’s March 2024 biometric-recognition guidance, the Processor’s vision-model field extraction does not constitute biometric data processing under Article 9(1) because the processing purpose is content extraction, not unique identification of a natural person. The Processor’s DPIA at /dpia (section 1.5) documents this analysis in full. Where documents incidentally contain other Article 9 special-category data (e.g. a marriage certificate showing religious ceremony, a faith-based employment letter, a medical certificate), the Controller is responsible for obtaining explicit consent under Article 9(2)(a) from the Data Subject before the document is uploaded for processing.
3. Controller's instructions
The Processor shall process Personal Data only on documented instructions from the Controller, unless required to do so by EU or Member State law. The Controller's instructions are as set out in this DPA and the Terms of Service. The Processor shall immediately inform the Controller if, in its opinion, an instruction infringes the GDPR or other data protection provisions.
4. Confidentiality
The Processor shall ensure that all persons authorised to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. Access to Personal Data is limited to personnel who require it to provide the service.
5. Security measures (Article 32)
The Processor implements the following technical and organisational measures to ensure a level of security appropriate to the risk:
- Documents are processed in-memory on EU-hosted infrastructure and are never written to disk, logged, or cached
- All data in transit is encrypted via TLS 1.2 or higher
- Analysis sessions are authenticated via short-lived tokens (5-minute expiry)
- Role-based access control per organisation
- Audit logging of all analysis events (non-PII metadata only)
- Database encryption at rest
- Encrypted-at-rest cloud storage is active by default (the Controller may disable cloud sync from Settings at any time, which wipes the cloud copy and schedules cryptographic erasure of the organisation’s KEK). The encryption regime applied to cloud blobs is:
- Cloud sync ON: per-application AES-256-GCM data encryption key (DEK), wrapped via Google Cloud KMS under a per-organisation key encryption key (KEK) hosted in
europe-west1. The KEK material lives only inside Google Cloud KMS and is never exposed to DocuFlag engineers or to the application servers; the runtime service account holds onlycloudkms.cryptoKeyEncrypterDecrypter(Encrypt/Decrypt operations against the KEK, with no ability to export, list, or destroy key material). Every Encrypt/Decrypt call is logged in Google Cloud Audit Logs and in DocuFlag's own audit trail. DocuFlag CAN decrypt cloud backups under an authorised user session; this is the trade for password-reset to work. - Cloud sync OFF: no server-side blob is created. Documents still transit the Processor’s EU analysis server in-memory for AI processing — processed in-memory only, never written to disk — but only the Controller’s browser cache holds the persistent copy. No KMS key is provisioned for the organisation in this state.
- Cloud sync ON: per-application AES-256-GCM data encryption key (DEK), wrapped via Google Cloud KMS under a per-organisation key encryption key (KEK) hosted in
A full risk assessment is available in our Data Protection Impact Assessment.
6. Sub-processors
The Controller grants general written authorisation for the Processor to engage the following sub-processors:
| Sub-processor | Purpose | Location | Data retention |
|---|---|---|---|
| Google Vertex AI (EU endpoint) | AI-powered document analysis | EU | Zero (not stored) |
| OVHcloud (compute / VPS hosting) | Hosts the DocuFlag web application and EU-hosted analysis relay (no document content written to disk by these services) | EU | Not stored (in-memory) |
| OVHcloud (object storage, self-managed) | Stores the encrypted case bundles for every active organisation. Storage layer holds ciphertext only and cannot decrypt — the wrapping keys live in Google Cloud KMS, never in the storage layer | EU | 180-day TTL reset on every access (touch-based expiry) |
| Google Cloud KMS (europe-west1) | Hosts the per-organisation key encryption keys (KEKs) used by encrypted cloud-sync storage. Holds key material in Google Cloud KMS' software-protected key store (FIPS 140-2 Level 1); exposes only Encrypt/Decrypt operations to the DocuFlag application identity. Not used when cloud sync is off (no server-side blob to wrap) | EU | Key material retained for the org’s lifetime. On account deletion (Article 17), the per-org KEK is scheduled for destruction in Cloud KMS at the 30-day hard-delete tick, with a further 24-hour Cloud-KMS-side delay. After that, key material is irreversibly destroyed and any wrapped data keys become mathematically un-decryptable (cryptographic erasure) |
| Stripe | Payment processing for credit-pack purchases | US/EU (UK + EU+US under SCCs / DPF) | Per Stripe policy |
| Cloudflare | CDN, TLS termination, DDoS protection. Sees only TLS-decrypted request metadata and bodies in transit; nothing is persisted at the edge by the DocuFlag configuration | Global (EU edge presence) | In-memory only (no edge cache for authenticated routes) |
| Backblaze B2 (off-site backup) | Encrypted off-site copies of the PostgreSQL database for disaster recovery. Backups are age-encrypted before upload using a key DocuFlag controls; B2 holds ciphertext only | EU | 30 daily + 12 monthly rotations; ciphertext only |
| Email transactional provider (SMTP) | Delivers magic-link sign-in emails and security notifications (passkey enrolment, account-deletion confirmations). Sees only email address + message body | EU | Per provider policy; messages not retained beyond delivery confirmation |
The Processor shall notify the Controller at least 30 days before engaging any new sub-processor. The Controller may object to a new sub-processor in writing within that period. If the objection cannot be reasonably resolved, the Controller may terminate the agreement. The Processor ensures that all sub-processors are bound by data protection obligations equivalent to those in this DPA.
Sub-processor change notifications. To receive advance notice of sub-processor changes, send an email to [email protected] with the subject line “Subscribe to sub-processor notifications”. We maintain a notification list and will email the address you supply at least 30 days before any new sub-processor begins processing data on our behalf. Existing sub-processor changes (e.g. region migrations, capability additions) follow the same 30-day notice.
7. Data subject rights (Articles 15–22)
The Processor shall assist the Controller in responding to requests from Data Subjects exercising their rights under the GDPR, including rights of access, rectification, erasure, restriction, portability, and objection. DocuFlag provides case deletion and data export functionality for this purpose. Any requests received directly by the Processor from Data Subjects will be promptly redirected to the Controller.
8. Data breach notification (Articles 33–34)
The Processor shall notify the Controller without undue delay and in any event within 72 hours after becoming aware of a Personal Data Breach. The notification shall include:
- The nature of the breach, including where possible the categories and approximate number of Data Subjects affected
- The likely consequences of the breach
- The measures taken or proposed to address the breach and mitigate its effects
The Processor shall cooperate with the Controller and take reasonable steps to assist in the investigation, mitigation, and remediation of the breach.
9. Data protection impact assessment (Articles 35–36)
The Processor has conducted a Data Protection Impact Assessment, available at /dpia. The Processor shall assist the Controller with their own DPIA obligations if required, and with any prior consultation with supervisory authorities under Article 36.
10. Data deletion and return
Live deletion. Upon termination of the service, or upon a Controller’s erasure request under Article 17, the Processor soft-deletes the associated account and personal data immediately. A scheduled cron hard-deletes the records 30 days later. The 30-day window is the grace period to recover from accidental or unauthorised deletion. The Controller may export their data before deletion via the built-in export functionality (Settings → GDPR → Export my data; returns a structured ZIP archive).
Cryptographic erasure (cloud-sync backup). When a cloud-sync account is hard-deleted at the 30-day mark, the per-organisation Cloud KMS KEK that wrapped the Controller’s backup data keys is scheduled for destruction in Cloud KMS. Cloud KMS waits a further 24 hours before destroying the key material; once destroyed, any ciphertext that depends on the KEK is mathematically un-decryptable, including any backup ciphertext that survives in disaster-recovery snapshots. This is the strongest erasure guarantee available short of physical-media destruction. The Processor uses an admin service account scoped to the keyring resource for the destruction call; the runtime service account does not have key-destruction permission.
Cloud-backup TTL. Encrypted blobs stored on self-managed EU object storage are subject to a 180-day TTL with automatic expiry. The Controller may also delete cloud data at any time from the application. Soft-deleted blobs are hard-purged from object storage 7 days later by an automated cron.
Audit-log retention. Routine audit-log entries (sign-ins, uploads, downloads) are retained for 1 year. Security-relevant entries (GDPR rights exercises, KMS operations, sensitive auth events) are retained for up to 6 years aligned with the limitation period for contract claims under the Limitation Act 1980 s.5 — the Processor may need these records to defend a contractual, billing, or compliance dispute. An automated daily retention sweep enforces both windows.
Disaster-recovery backups. Encrypted off-site PostgreSQL backups (30 daily + 12 monthly rotations). After erasure on the live system, data persists in encrypted backups until those backups age out (worst case: 12 months). During that window the Processor will not restore the data to live processing without re-applying the pending erasure (ICO “beyond use” doctrine).
Analysis-flow processing. During analysis, documents are processed in-memory only and are never written to disk by the Processor or by the AI sub-processor; they are discarded immediately after analysis completes.
11. Audit rights
The Processor shall make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Article 28. The Controller (or their appointed third-party auditor) may conduct an audit of the Processor's compliance with this DPA once per year with at least 30 days' written notice. The Processor shall cooperate and provide access to relevant information, systems, and personnel.
12. International data transfers
All processing occurs within the European Union. Documents are processed by the Processor's EU-hosted analysis server and forwarded to Google's Vertex AI EU endpoint. No Personal Data is transferred outside the European Economic Area. If a transfer outside the EEA becomes necessary in the future, the Processor shall ensure appropriate safeguards are in place, including Standard Contractual Clauses approved by the European Commission.
13. Liability
Each party shall be liable for damages caused by processing that infringes the GDPR, in accordance with Article 82. The Processor shall be liable only for damage caused by processing where it has not complied with obligations of the GDPR specifically directed to processors, or where it has acted outside of or contrary to the Controller's lawful instructions. Liability under this DPA is subject to the limitations set out in the Terms of Service.
14. Term and termination
This DPA is effective for the duration of the Controller's DocuFlag subscription. Termination of the subscription automatically triggers the data deletion provisions in section 10. The obligations in this DPA that by their nature should survive termination (including confidentiality, liability, and data deletion) shall survive.
15. Governing law
This DPA is governed by the laws of England and Wales, consistent with the Terms of Service. Any disputes shall be subject to the exclusive jurisdiction of the courts of England and Wales.
Contact
For questions about this DPA, contact [email protected].