Data Processing Agreement

Our customers agree to these processor terms so they can lawfully store personal data in Intracia CMS. It sits alongside our Privacy Policy, Terms of Service and Acceptable Use Policy.

This describes what we do today, and we'll tell you before it changes materially. If something here doesn't work for your organisation, tell us. We read these ourselves, and we can discuss changes.

Between:

• Customer ("Controller") — the organisation using the Service; and
• Intracia Ltd, Guernsey ("Processor", "we").

Together the "Parties". This DPA forms part of the agreement under which we provide the Service (the "Agreement"), and it covers our processing of personal data on the Controller's behalf.

Up to 4 laws may apply, and where one does, the matching terms below apply with it:

• the EU GDPR and the UK GDPR — the General Data Protection Regulation in each of those regimes;
• the Guernsey DPL — the Data Protection (Bailiwick of Guernsey) Law 2017; and
• the CCPA — the California Consumer Privacy Act, as amended by the California Privacy Rights Act.

1. Roles

The Controller decides why and how the personal data in its content and configuration is processed ("Customer Personal Data"). Intracia processes that data only as a processor — a "service provider" under the CCPA — and only on the Controller's documented instructions.

One thing this DPA doesn't cover: personal data about the Controller's own account holders and users. Intracia processes that as a controller, and the Privacy Policy governs it.

2. Instructions

We process Customer Personal Data in 3 cases only:

• to provide, maintain and secure the Service under the Agreement;
• as the Controller's own use and configuration of the Service directs; and
• where the law requires it. We'll tell the Controller first, unless the law forbids us to.

If we think an instruction breaks data-protection law, we'll say so.

3. CCPA / service-provider terms

The CCPA calls us a "service provider" rather than a processor. Under it, we won't:

• sell or share Customer Personal Data;
• keep, use or disclose it for any purpose other than performing the Service, or outside our direct business relationship with the Controller; or
• combine it with data from other sources, except where the CCPA allows.

We certify that we understand these restrictions and will comply with them.

4. Confidentiality

Everyone we authorise to process Customer Personal Data is under a duty of confidentiality, and reaches it only where the job in front of them needs it.

5. Security

We keep the safeguards set out in Annex 2. They include encryption in transit and at rest for secrets, tenant isolation through Row Level Security, least-privilege access, signed webhooks, rate limiting, and audit logging. Together these are what the GDPR calls "technical and organisational measures". We may change them, so long as the protection doesn't materially drop.

6. Sub-processors

The Controller gives general authorisation for us to engage the sub-processors listed in Annex 3 to provide the Service. A sub-processor is a supplier we bring in who handles Customer Personal Data on our behalf. We hold each of them to data-protection terms at least as strict as this DPA, and we remain liable for what they do.

We'll give the Controller at least 7 days' advance notice of any new or replacement sub-processor, by email. The Controller may object on reasonable data-protection grounds; if we can't resolve the objection, the Controller may terminate the affected part of the Service.

The published sub-processor list (Privacy Policy, section 9) is the authoritative register — Annex 3 refers to it rather than duplicating it, so they can't drift apart. That 7-day figure is stated in the public policy too; change one and you must change the other.

7 days is the notice period during early access. We intend to lengthen it to 30 days at general availability, and this clause will be updated when we do.

7. Assistance to the Controller

So far as the nature of the processing allows, we'll help the Controller to:

• Answer requests from data subjects — the people the data is about. We forward any request that comes to us directly, and we provide the tools and exports needed to find, correct, delete or export Customer Personal Data.
• Keep the data secure, and report a breach in time — the duties in Articles 32 to 34 of the GDPR.
• Carry out a data protection impact assessment, and consult a regulator where one is needed — Articles 35 and 36. An impact assessment is the written risk assessment the GDPR requires before processing that's likely to be high risk.

8. Personal-data breaches

We'll notify the Controller without undue delay after becoming aware of a breach affecting Customer Personal Data, with the information the Controller reasonably needs to meet its own notification duties. We don't notify supervisory authorities or data subjects on the Controller's behalf unless separately agreed.

9. International transfers

Intracia is established in Guernsey, which both the EU and the UK recognise as offering an adequate level of protection. That is the highest status a country outside the EEA can hold, and the only one that removes the transfer restriction rather than papering over it. Sending Customer Personal Data from the EEA or the UK to us therefore needs no further safeguard, and no Standard Contractual Clauses.

Providing the Service then means moving it on to sub-processors outside the EEA, the UK and Guernsey — the database in the United States above all. We are the exporter on those transfers, not the Controller. We make each one under the EU Standard Contractual Clauses and the UK International Data Transfer Addendum we have entered into with that provider, or under its Data Privacy Framework certification where it holds one. Annex 3 names every provider and links its terms.

We apply technical measures on top of whichever safeguard applies.

10. Deletion or return

When the Service ends we'll delete or return Customer Personal Data within 30 days, whichever the Controller chooses, and delete any copies we still hold. The one exception is anything the law requires us to keep. Backups clear on their own cycle: we take them daily and keep them for 7 days.

11. Audits

We'll give the Controller what it needs to check that we're keeping to this DPA, and we allow audits. This document and Annex 2 answer most of it, and we'll answer a written question directly. The Controller can arrange an on-site audit on reasonable notice and at its own cost, subject to confidentiality and without compromising other customers.

12. Liability and precedence

Liability is subject to the limitations in the Agreement. If this DPA conflicts with the Agreement on data protection, this DPA prevails.

Annex 1 — Details of processing

• Subject-matter: provision of Intracia.
• Duration: the term of the Agreement, plus deletion or return under Clause 10.
• Nature and purpose: hosting, storing, editing, versioning, syncing (Git), publishing, and serving Controller content and media, plus optional AI-assisted authoring; and handling the support correspondence that arises from the Service, which may itself contain Customer Personal Data the Controller chooses to send us.
• Types of personal data: any personal data the Controller chooses to include in its content, media, metadata, and configuration — potentially names, contact details, images, and other identifiers of the Controller's staff, authors, or the subjects/readers of its sites.
• Categories of data subjects: as determined by the Controller (for example its staff, authors, customers, website audience).
• Special categories: not intended; the Controller must not submit special-category data unless separately agreed and safeguarded.

Annex 2 — Technical and organisational measures

• Encryption of secrets/credentials at rest; TLS in transit.
• Tenant isolation via Postgres Row Level Security keyed on site_id.
• Role-based access control (admin/editor), authenticated and authorised API routes.
• Server-only elevated credentials; no service keys or DB connection strings exposed to browsers.
• Inbound webhooks signed and verified, so we can tell a genuine one from a forgery; rate limiting on API, AI, preview, and outbound paths.
• Audit trails: activity logs, sign-in/security logs, push/pull job records.
• Least-privilege sub-processor access and documented retention/deletion.

Annex 3 — Approved sub-processors

The authoritative register, with purposes, data categories and regions, is published in the Privacy Policy, section 9. It's public, so the Controller doesn't have to request it, and this Annex points at it rather than duplicating it so that they can't drift apart.

Engaged by us

These process Personal Data on our instruction in every deployment of the Service. Each is engaged under data-protection terms no less protective than this DPA:

Microsoft is in this table for a narrower reason than the rest, and the difference matters. Every other sub-processor above touches the Service: the Controller's content passes through it as a matter of course. Microsoft doesn't. Nothing in Intracia reads from or writes to Microsoft 365, and no Customer Personal Data is routed there by the Service.

It's listed because a Controller who emails us about a fault may include Customer Personal Data in that email: a draft, an export, a screenshot, a name in a stack trace. That correspondence then sits in our mailbox. Where it does, Microsoft is processing Customer Personal Data on our behalf, and Clause 6 applies to it the same as to anything else.

No payment processor is engaged: the Service takes no payments. One will be added here, with the notice required by Clause 6, before it handles anything.

Connected by the Controller — not our sub-processors

Where the Controller connects their own repository, storage bucket or deployment target, the Service reads from and writes to it on the Controller's instruction and under the Controller's own account. Uploaded media is written to the storage source the Controller configures — Cloudflare R2, Amazon S3, Azure Blob Storage, or an S3-compatible endpoint.

Those providers are therefore the Controller's processors, not our sub-processors. We don't contract with them, can't impose terms on them, and aren't liable for them. The Controller is responsible for its own agreement with each, including:

The distinction matters for liability and for the Controller's own record of processing: a bucket the Controller owns is within the Controller's control, and this DPA doesn't extend to it.

Some of these names appear elsewhere in a different role, so here is the untangling. GitHub and Microsoft are also sign-in providers — an account holder may authenticate with GitHub, Microsoft, LinkedIn, Facebook or Google. In that role they are independent controllers of the sign-in itself rather than sub-processors of ours: they tell us who you're, they don't process Customer Personal Data on our instruction. Authentication concerns account data, not the content this DPA governs. The Privacy Policy describes it in section 5.2, and section 9 tabulates each provider and what it hands us.

Both also appear in the first table above, for reasons that have nothing to do with sign-in. GitHub is there because the Git integration genuinely is a sub-processing arrangement. Microsoft is there because our mailboxes are, as set out under that table. So each name carries up to 3 separate roles, and which one applies depends on what the data is rather than on whose logo is on it.

Where we host the Controller's repository or bucket

For Controllers whose sites we built and whose infrastructure we run as part of that engagement, the storage bucket may sit in our Cloudflare account and the repository in our GitHub organisation. Where that's the case — and it's set out in the Controller's agreement with us — the position reverses:

• Cloudflare and GitHub are our sub-processors for that content, as in the first table above, and we're liable for their performance in respect of it.
• The content is Personal Data we process on the Controller's instruction, with the full weight of this DPA behind it, including deletion at the end of the engagement.
• On request, and at the end of the engagement, we transfer it out: the repository to an organisation the Controller nominates, and the objects to a bucket in the Controller's own account. The Controller isn't required to give a reason, and this doesn't depend on the engagement ending amicably.

A Controller in this position should record it in their own record of processing. It's the one case where content they might assume sits in their own infrastructure doesn't.

Annex 4 — Transfer mechanism

The Controller doesn't need to sign Standard Contractual Clauses with us. Sending data to us is covered by Guernsey's adequacy, and the onward transfers are covered by clauses we hold with each sub-processor — section 9 sets out both.

If a compliance review needs the detail, write to privacy@intracia.com and we'll tell you which clauses cover which provider. These published terms bind us whether or not anything separate has been signed.