Data Processing Addendum

This Data Processing Addendum (“DPA”) is entered into between Coreframe Labs Ltd (“Processor”, “we”), a company registered in England & Wales, and the business identified on the Coreframe Relay account it applies to (“Controller”, “you”). It applies automatically to every customer processing personal data through Coreframe Relay (the “Service”) and is incorporated into, and forms part of, the Terms of Service. It governs Processor’s processing of personal data contained in the webhook payloads Controller routes through the Service on Controller’s behalf (“Customer Data”). It does not cover Coreframe’s processing of your own Relay account data (your name, email, team) — that is described in the Privacy Notice, where Coreframe is the controller.

If you want a signed, countersigned copy of this DPA for your own procurement records, email info@coreframe-labs.dev and we will provide one; a separate signature is not required for this DPA to apply to your use of the Service.

1. Subject matter, duration and nature of processing

Subject matter: the receipt, queuing, retry, logging and — for permanently failed deliveries only — temporary storage of webhook payloads submitted to a Route Controller configures within the Service.

Duration: for as long as Controller has an active Route configured to receive the relevant traffic, and thereafter only for as long as any already-stored Customer Data remains undeleted (see Section 8, Retention and deletion).

Nature and purpose: Processor operates infrastructure that (a) accepts an inbound HTTP request at a Controller-configured ingest URL, (b) queues it for delivery to a Controller-configured destination, (c) retries delivery on failure according to Controller-configured retry settings, (d) records delivery metadata (see Section 3) so Controller can monitor delivery health, and (e) for deliveries that permanently fail, retains the payload so Controller can inspect and manually replay it. Processor does not process Customer Data for any purpose of its own — see Section 2.

2. Processor obligations

Processor shall:

• process Customer Data only on Controller’s documented instructions — which are, for the avoidance of doubt, the Route configuration Controller sets within the Service (destination URL, retry policy, any destination authentication headers) — unless required to do otherwise by UK law, in which case Processor will inform Controller before processing, unless that law prohibits it;
• ensure persons authorised to process Customer Data are subject to confidentiality obligations;
• implement appropriate technical and organisational security measures (Section 4);
• engage sub-processors only as permitted under Section 5, and flow down equivalent data protection obligations to each;
• assist Controller, taking into account the nature of the processing, in responding to requests from data subjects exercising their UK GDPR rights (Section 6);
• assist Controller with its own security, breach-notification and data protection impact assessment obligations, to the extent Processor holds information Controller needs and Controller could not reasonably obtain itself (Section 7);
• at Controller’s choice, delete or return Customer Data at the end of the relationship, subject to Section 8; and
• make available the information reasonably necessary to demonstrate compliance with this DPA and allow for audits as described in Section 9.

3. Categories of data and data subjects

Controller determines what Customer Data exists by what it chooses to route through the Service — Processor does not select, filter or interpret payload content. Typically this is data Controller’s own upstream systems (e.g. Stripe, Shopify, the WhatsApp Business API) send about Controller’s own customers or end-users: names, email addresses, phone numbers, order and payment metadata (not raw card numbers, which never transit Processor’s infrastructure via these integrations), shipping addresses, or message content. Data subjects are Controller’s customers, end-users or other individuals Controller’s upstream systems reference — not Processor’s own personnel or contacts.

As described in the Privacy Notice Section 3, Processor’s delivery log stores metadata about a delivery attempt (request ID, sender IP, status, attempt count, response code, latency, payload size in bytes) rather than payload content for successfully delivered webhooks. Payload content is retained only for deliveries that permanently fail, in the dead-letter queue, so Controller can review and manually retry them.

4. Security measures

Measures actually in place today, stated at the level of specificity we can stand behind rather than a generic checklist:

• Encryption of destination credentials at rest. Any authentication header value Controller configures for a destination is encrypted with AES-256-GCM before it is written to the database, keyed per header value with a random initialisation vector, and is decrypted only at the moment of forwarding a request. No API, including ones Processor controls, ever returns a stored header value — only its name.
• Tenant isolation, stated honestly. Every relevant handler is written to filter Route, delivery-log and dead-letter-queue queries by the requesting team’s ID, and that application-level scoping is what actually separates one Controller’s Customer Data from another’s in production today. PostgreSQL Row-Level Security policies have also been created and enabled on all six of those tables in the production database, as a second, database-layer barrier designed to enforce the same restriction independently of application code — but as of this DPA’s effective date, the production application has not yet been switched to the restricted database role those policies are designed to enforce against, so that second barrier is built and tested but not yet the thing actively stopping a cross-tenant query in production. Completing that database-role switch is a named, outstanding operational action; Controller may request its current status by contacting us (Section 12). The application-level scoping, and the Row-Level Security policies’ correctness once the restricted role is in use, are both verified by an automated cross-tenant isolation test suite exercised as part of Processor’s release process.
• Encryption in transit. All traffic to and from the Service, including inbound webhook delivery and dashboard access, is served over TLS.
• Access control. Production infrastructure (hosting, database, DNS, queue) is administered solely by Processor’s director; there is no separate operations team with standing production access.
• Credential handling. Infrastructure credentials are held as environment secrets, not committed to source control, and rotated when there is reason to believe one may have been exposed.

Stated limit, not hidden: Processor is a single-person company. There is no dedicated security team, no 24/7 on-call rotation, and no formal ISO 27001 or SOC 2 certification. If that level of assurance is a requirement for your organisation, say so before relying on this DPA — we would rather you know that now than discover it during your own audit.

5. Sub-processors

Processor currently uses the following sub-processors:

General authorisation and the right to object. Controller gives Processor general authorisation to engage the sub-processors above, and any future sub-processor, subject to this clause: Processor will notify Controller — by email to the address on Controller’s account, or an equivalent in-product notice — of any intended addition or replacement of a sub-processor that will process Customer Data, at least 14 days before the change takes effect. Controller may object on reasonable data-protection grounds within that window by emailing info@coreframe-labs.dev. If Processor cannot address the objection with a change that resolves it, either party may terminate the affected part of the Service without penalty. Processor remains liable for each sub-processor’s performance of its data protection obligations to the same extent Processor would be liable for performing those obligations itself.

6. Assistance with data subject requests

If Processor receives a request from an individual concerning Customer Data (for example, someone identifying themselves as one of Controller’s customers), Processor will, without undue delay, either forward the request to Controller or assist Controller in responding, and will not respond to the individual directly except to confirm the request has been forwarded, unless Controller instructs otherwise or Processor is legally required to respond. Controller remains responsible for determining how to respond to the individual, since Controller is the controller of that data.

7. Personal data breach notification

Processor will notify Controller without undue delay and in any event within 72 hours of becoming aware of a confirmed personal data breach affecting Customer Data, by email to the address on Controller’s account — the fastest channel available given Processor is a single-person operation without a dedicated incident-response function. The notification will describe, to the extent then known: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed to address it. Processor will update Controller as material new information becomes available, since a first notification inside 72 hours will not always be complete.

8. Retention and deletion

As set out plainly in the Privacy Notice: Processor does not currently operate an automated process that deletes Customer Data on a schedule. Customer Data is retained until Controller deletes it (via the dashboard’s dead-letter-queue management features), Controller’s account is deleted, or Controller requests deletion directly.

On termination of Controller’s use of the Service, Processor will, within 30 days of Controller’s written request, delete all Customer Data held in delivery-log and dead-letter-queue storage, or — if Controller requests it in writing before that 30-day window closes — export it to Controller in a structured format first and then delete it, except to the extent retention is required by UK law.

9. Audit rights

Sized to what a one-person company can actually deliver, not an enterprise programme Processor does not have: no more than once in any 12-month period, Controller may request a written summary of the security measures described in Section 4, together with reasonable supporting evidence (for example, the result of the cross-tenant isolation test suite referenced there). Processor will provide a response to a reasonable written questionnaire within a reasonable time. Processor does not currently offer an on-site audit, a third-party penetration-test report, or a formal certification (ISO 27001, SOC 2) — if your organisation requires one of those as a condition of processing, tell us before relying on this DPA rather than after.

10. International transfers

Where a sub-processor in Section 5 is located outside the UK, the transfer safeguard applied is the one described in the Privacy Notice, Section 6 (International transfers) — in summary, UK adequacy regulations for Japan (Resend) as the primary basis with the UK International Data Transfer Addendum incorporated as a fallback, and the UK International Data Transfer Addendum (or the UK extension to the EU-US Data Privacy Framework, where applicable) for United States sub-processors (Vercel).

11. Liability and governing law

This DPA is governed by the laws of England & Wales, on the same terms as the Terms of Service into which it is incorporated. Nothing in this DPA expands either party’s liability beyond what the Terms of Service set out.

12. Contact

Data protection queries relating to this DPA: info@coreframe-labs.dev.