Data Processing Agreements

A Data Processing Agreement — DPA — is the contract that governs what a third party can do with personal data we hand them. Under Article 28 of GDPR, a DPA is mandatory whenever a processor handles personal data on our behalf. No DPA, no data — this is a hard line, enforced at procurement.

For Castline specifically, our processors include a small number of large vendors and the agreements are well-trodden, but the principle applies to any new tool the team brings in. A SaaS that touches user emails needs a DPA. A monitoring tool that ingests user IDs needs a DPA. A consultant who logs into our admin panel does not — they sign an NDA and operate under our access controls, not a separate DPA.

Who we need DPAs with

Active production processors (Castline as of 2026):

• OpenAI — Assistants API for AI Diary generation. DPA in place; covers transient processing of user-provided diary content as input to model calls. We use the enterprise tier, which guarantees no training on our data.
• Google Cloud — Cloud Vision for image moderation. DPA in place; covers processing of user-uploaded images for content classification.
• Pusher — WebSocket fan-out for real-time Castline events. DPA in place; covers transient routing of message metadata.
• AWS (via Laravel Cloud) — application hosting and S3-compatible object storage. DPA in place via the Laravel Cloud master agreement.
• Sentry — error tracking and performance monitoring. DPA in place; we scrub PII from error contexts before sending.
• PostHog — product analytics. DPA in place; we use self-hosted EU instance and forward only pseudonymised event identifiers.
• Microsoft — Microsoft 365 for internal collaboration. DPA in place under the Microsoft Online Services DPA.
• monday.com — requirements and project management. DPA in place; Castline customer data does not enter monday.

Out of scope: Vendors that do not touch personal data (e.g. our CDN serving public static assets) do not need a DPA. Vendors used by individual employees on company devices without integration into Castline (e.g. a local password manager) operate under our acceptable-use policy.

What a DPA must contain

Per Article 28(3), a DPA must specify: the subject matter and duration of processing, the nature and purpose, the type of personal data and categories of data subjects, the obligations and rights of the controller, and a list of sub-processors.

We additionally insist on:

• Sub-processor notification. 30 days' advance notice of any new sub-processor, with the right to object.
• Audit rights. At minimum, the right to receive the latest SOC 2 Type II or ISO 27001 report on request.
• Breach notification. Notice to us within 24 hours of detection — tighter than GDPR's 72-hour clock so we have time to meet our own obligation.
• Deletion on termination. Either return or deletion of personal data at our option, with written confirmation.

International transfers

For processors outside the EEA, the DPA additionally incorporates the EU Standard Contractual Clauses (Module 2: controller-to-processor) plus a Transfer Impact Assessment on file. For US processors specifically, we also rely on the EU-US Data Privacy Framework certification where the processor holds one.

Lifecycle

Every active DPA is reviewed annually by Legal, with renewal triggered automatically 30 days before expiry. Sub-processor lists are reviewed quarterly. A processor that adds an undisclosed sub-processor is in material breach — Legal exercises termination rights without escalation.

Owned by

Head of Legal & Compliance, with Head of Procurement consulted on new vendor onboarding.