Data Processing Agreement

1. Definitions

"UK GDPR" means Regulation (EU) 2016/679 as it forms part of the law of England and Wales, Scotland and Northern Ireland by virtue of section 3 of the European Union (Withdrawal) Act 2018. "DPA 2018" means the Data Protection Act 2018. "Controller", "processor", "personal data", "processing", "data subject", "personal data breach" and "supervisory authority" have the meanings given in UK GDPR Article 4.

2. Roles

For account-holder data and for transcripts/recordings generated within an individual account, plab2osce.ai acts as the controller. Where plab2osce.ai engages a sub-processor (Annex III), that sub-processor acts as a processor on plab2osce.ai's documented written instructions per Article 28(3) UK GDPR.

3. Subject matter, duration, nature, and purpose (Article 28(3))

See Annex I.

4. Categories of data subjects and personal data

See Annex I sections (B) and (C).

5. Processor's obligations

Each processor agrees to:

• (a) process personal data only on the controller's documented instructions, including with regard to international transfers, unless required to do so by Union or Member State law;
• (b) ensure persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation;
• (c) implement appropriate technical and organisational measures (Annex II);
• (d) not engage another sub-processor without the controller's prior specific or general written authorisation (general authorisation is given for the parties listed in Annex III, with at least 14 days' notice before changes);
• (e) assist the controller with data subject rights requests (Articles 15-22) by appropriate technical and organisational measures;
• (f) assist the controller in ensuring compliance with Articles 32 to 36 (security, breach notification, DPIA, prior consultation);
• (g) at the controller's choice, delete or return all personal data after the end of the provision of services and delete existing copies unless storage is required by law;
• (h) make available to the controller all information necessary to demonstrate compliance, and allow for and contribute to audits, including inspections.

6. Security of processing (Article 32)

See Annex II — technical and organisational measures.

7. Personal data breach (Articles 33 and 34)

The processor will notify the controller without undue delay (and in any event within 48 hours) after becoming aware of a personal data breach. The notification will include, where available: nature of the breach; categories and approximate number of data subjects and records concerned; likely consequences; measures taken or proposed.

8. International transfers

Where personal data is transferred outside the UK, the parties rely on:

• The UK International Data Transfer Addendum to the EU Standard Contractual Clauses ("UK Addendum"), or
• An adequacy decision (where applicable), or
• The UK-US Data Bridge (where applicable to a US data importer that has self-certified).

For OpenAI (United States): we rely on the Standard Contractual Clauses (Module 2: controller-to-processor) plus the UK Addendum. Audio is transmitted over TLS, processed for transcription/synthesis, and not retained by OpenAI for model training under their API data policy.

9. Audits

The controller may, at its own cost and on at least 30 days' notice, request a copy of the processor's most recent SOC 2 Type II / ISO 27001 / equivalent attestation. On-site audit will be arranged only where reasonably required and where confidentiality and security are preserved.

10. Liability

Liability under this DPA is subject to the limitations set out in the Terms of Service.

11. Governing law

This DPA is governed by the laws of England and Wales.

Annex I — Description of processing

(A) Subject matter and duration

Provision of the PLAB 2 OSCE Trainer Service. Duration: for the term of the candidate's account, plus the retention windows set out in the Privacy Policy.

(B) Categories of data subjects

• Account holders (individual medical graduates / final-year medical students preparing PLAB 2 / UKMLA-CPSA).
• Waitlist subscribers (pre-account interest list).
• Inviters / invitees in the referral programme.

(C) Categories of personal data

• Identifiers: email, name (optional), country code, Stripe customer ID.
• Authentication credentials: Argon2id password hash, JWT session cookie, CSRF token cookie.
• Voice recordings (R2): webm/opus candidate audio (auto-deleted after 30 days).
• Transcripts: ASR output of candidate audio + AI patient text replies.
• Examiner output: IPS / DG / CM scores and rationales.
• Operational metadata: exam date (optional), planned exam date, lifecycle email timestamps.
• Technical: IP address (14 days), user-agent, request id (audit log).

No Article 9 special-category data is collected. The clinical content of role-play sessions is fictional and is not the candidate's own medical record.

(D) Frequency and nature of processing

Continuous (during sessions); batch (cron-based audio purge, lifecycle email scans, audit-log retention).

(E) Purpose

Run OSCE practice sessions; produce examiner feedback; manage subscriptions; enforce free-tier quotas; communicate transactional and lifecycle messages; investigate abuse and security incidents.

(F) Retention

See the Privacy Policy retention table.

Annex II — Technical and organisational measures (TOMs)

1. Pseudonymisation and encryption

• TLS 1.2+ on all network paths (api ↔ FE, api ↔ DB, api ↔ R2, api ↔ OpenAI/Anthropic).
• Audio at rest: encrypted by R2 with provider-managed keys.
• Audio in transit out of our walled garden: signed URLs with 10-minute expiry.
• Passwords stored as Argon2id hashes (memory cost > 64 MiB).
• JWT signing key length >= 32 bytes; CSRF double-submit pattern.

2. Confidentiality, integrity, availability and resilience (Art. 32(1)(b))

• Single-tenant Postgres with row-level user isolation enforced at the application layer.
• Daily database backups with 30-day rolling retention.
• Append-only audit log (Article 30 records of processing).
• Health checks; structured request-id correlated logs; Sentry error monitoring.

3. Restoring availability (Art. 32(1)(c))

• RPO target: 24 hours (daily backup cadence).
• RTO target: 4 hours for full re-deploy from infra-as-code + restored DB.

4. Regular testing (Art. 32(1)(d))

• CI: unit tests + contract tests (Zod schemas) + Playwright E2E on every commit.
• Manual annual restore-from-backup drill.
• Dependency scanning on every Bun lockfile change.

5. Access control

• Production DB credentials in vault; not in source control.
• Admin actions on /api/admin require an authenticated session with admin role.
• All admin actions are written to the audit log with actor, action, resource, IP and request id.

6. Sub-processor management

• Each sub-processor is contractually bound by its standard DPA + UK Addendum.
• 14-day notice before adding or replacing a sub-processor.

7. Personal data breach handling

• Incident playbook: detect → contain → assess severity → notify controller within 48h → notify ICO within 72h if reportable.
• Internal post-mortem with root cause + remediation tracked.

Annex III — Authorised sub-processors

Material changes to this list will be notified at least 14 days in advance via the registered email address.

Questions or to request a counter-signed copy of this DPA: hi@plab2osce.ai