GDPR Article 28 and visa appointment data: a due-diligence guide for EOR platforms

When a relocation platform, EOR, or corporate travel service automates visa appointments, it doesn't just handle a booking transaction. It becomes a data controller — and likely a data processor — for some of the most sensitive personal data that exists: passport numbers, dates of birth, nationality, travel history, employer sponsorship details, and in some corridors, biometric references.

Most enterprise legal teams understand GDPR in the context of CRM data or marketing emails. Visa appointment data sits in a different risk tier. It touches Article 9 special categories (nationality, potentially health data if medical visas are involved), it crosses international borders by definition, and it flows through third-party portals — VFS Global, TLS Contact, individual embassy systems — that are not under your control. The compliance surface is wider than a standard SaaS integration, and the consequences of getting it wrong are proportionally larger.

Article 28 of the GDPR requires that where a controller uses a processor — any third party processing personal data on the controller's behalf — the processing must be governed by a contract or other legal act. That contract must contain specific minimum provisions. For visa appointment automation, every vendor in the chain must have a compliant DPA in place before any applicant data flows to them.

When evaluating a visa automation vendor, the sub-processor question is where most legal reviews stall. The vendor's own security is relatively easy to assess — encryption specs, audit logs, access controls. The sub-processor chain is harder: proxy providers often operate in jurisdictions outside the EEA, CAPTCHA services may process visual content that includes personal data, and cloud providers must have Standard Contractual Clauses in place for international transfers.

Ask for the full sub-processor list, the contractual mechanism for each (SCC, adequacy decision, or binding corporate rules), and the notification period for adding new sub-processors. A vendor who cannot produce this list is not compliant with Article 28(2) — full stop.

For enterprise customers performing due diligence:

• We act as a processor under a standard DPA. Controllers remain responsible for their lawful basis for processing.
• Our sub-processor list covers cloud infrastructure, proxy providers, and email delivery. It is published and kept current; we give 30 days' notice before adding new sub-processors.
• Applicant credentials are encrypted per-applicant using AES-256-GCM with a KMS-managed master key. No Opaige employee can read a credential in plaintext — see our credential vaulting guide for the technical detail.
• On account termination, applicant data is deleted within 30 days. Confirmation of deletion is provided by email.
• We support DSAR assistance — data subjects can request export or deletion of their data via your operator console.

To request our DPA template or arrange a security review, email security@opaige.com.