Data Processing Addendum — Summary

Data processing · Summary — the executed DPA in your engagement agreement is the document that binds

The agreement, in plain English

This page summarises the Data Processing Addendum that will govern personal data processed in the Citadel platform. The executed DPA in your engagement agreement is the document that binds.

A DPA exists for a specific reason. Article 28 of the UK GDPR requires that whenever one organisation processes personal data on behalf of another, a written contract sets out what is processed, why, for how long, and under what safeguards. This page explains, in ordinary language, what our DPA covers for customers of the Citadel governance platform. It should be read alongside our privacy policy and terms of service.

Roles: you are the controller, we are the processor

When your organisation uses Citadel, you decide what data goes into the platform and what it is used for. That makes you the controller under UK GDPR. EAIC LTD acts as your processor: we handle personal data in Citadel only on your documented instructions, and only to provide, secure and support the platform — never for purposes of our own.

Your documented instructions are the engagement agreement, the DPA itself, and the configuration choices your team makes inside the platform. If an instruction would, in our view, breach data protection law, the DPA obliges us to tell you before acting on it rather than proceed quietly.

One distinction worth being clear about: this processor role applies to Citadel. For personal data collected through the eaic.uk website — an enquiry you send us, for example — EAIC is the controller, as set out in our privacy policy. The two roles sit side by side and the obligations differ accordingly.

What Citadel actually processes

Citadel is a governance platform. Most of what it holds is information about AI systems, controls and evidence — not about people. The personal data involved is deliberately limited, and falls into three categories: account details for your own staff (name, work email address, role); usage and audit logs recording who did what in the platform, which exist precisely because governance requires an audit trail; and any personal data that happens to appear in governance records your organisation chooses to upload.

The data subjects are therefore your personnel and, where your own documentation references them, individuals mentioned in that material. The duration of processing is the term of your engagement. The DPA records all of this — subject matter, nature and purpose, categories of data and data subjects, and duration — as Article 28(3) requires, so that neither side has to rely on assumption.

The Article 28 commitments

The substance of the DPA is a set of obligations UK GDPR places on any processor, written into contract. In summary, EAIC commits to:

• process personal data only on your documented instructions;
• ensure everyone with access is bound by confidentiality obligations;
• apply security measures appropriate to the risk, under Article 32;
• engage sub-processors only under the conditions described below;
• assist you in responding to data subject rights requests;
• assist you with security, breach notification and data protection impact assessments;
• delete or return personal data when the engagement ends; and
• make available the information needed to demonstrate compliance, including supporting audits.

None of these is unusual, and that is the point. A processor contract should be predictable. What matters is that each obligation is written down, specific, and capable of being evidenced — the same standard we ask clients to apply to their own AI governance.

Sub-processors and international transfers

Like almost every software provider, EAIC relies on a small number of infrastructure providers — hosting and email among them — to deliver the platform. These are sub-processors. The DPA works on general written authorisation: we maintain a list of sub-processors, available in your engagement documentation and on request, and we give you prior notice before adding or replacing one, with the opportunity to object. Every sub-processor is bound by data protection obligations equivalent to those we owe you, and EAIC remains fully liable to you for their performance.

Where any processing takes place outside the United Kingdom, it relies on recognised transfer safeguards — the UK International Data Transfer Addendum or standard contractual clauses with the UK addendum — consistent with the approach described in our privacy policy. The DPA identifies which transfers apply to your engagement so the position is documented, not implied.

Security and breach notification

The DPA commits EAIC to technical and organisational measures appropriate to the risk, as Article 32 requires. In practice these include encryption of data in transit, role-based access controls on a least-privilege basis, audit logging of platform activity, and separation between customer environments. The measures are described in the engagement documentation rather than buried in general assurances, so your security and compliance teams can review what is actually in place.

If a personal data breach affects your data in Citadel, we notify you without undue delay after becoming aware of it, with enough detail — nature of the breach, categories and approximate numbers affected, likely consequences, and the measures taken — for you to make your own assessment. That matters because the 72-hour clock for reporting to the ICO runs against you as controller; our job is to make sure you never lose time to your processor’s silence.

Exit, deletion and audit

When the engagement ends, the data leaves with you. At your choice, we return your personal data or delete it, and we delete remaining copies within a defined period, confirming in writing once done. The only exception is data we are legally required to retain, and the DPA says so explicitly rather than leaving it to interpretation. No processor should hold customer data as leverage, and this one will not.

Finally, audit. The DPA gives you the right to the information necessary to demonstrate our compliance with Article 28, and to conduct audits or inspections, on reasonable notice, either directly or through an appointed auditor. In most cases documentation and existing attestations will answer the question; where they do not, the inspection right stands. Governance you cannot verify is governance you are taking on trust — a principle we apply to ourselves as readily as to the AI systems our clients run.