Data Processing Agreement (template)

Who needs this — and who is the processor?

Orimora is self-hosted software. The maintainers of Orimora do not operate your instance and never receive your data, so they are not your processor. That has a concrete consequence for your paperwork:

If you run Orimora for your own organisation only, you are the controller. You generally don’t sign a DPA with yourself — but you still owe your users a privacy notice and must document your sub-processors.
If you run Orimora on behalf of customers (e.g. you host it for them), you are the processor and your customer is the controller. The template below is the agreement you offer them.

In other words: this DPA is between you (the operator) and your customer, with the external services your deployment uses listed as sub-processors.

How to use this template

Fill every [PLACEHOLDER].
Attach Annex II from the live Sub-processor list — keep it in sync with what you actually configure.
Attach Annex III (your technical & organisational measures). The defaults below reflect Orimora’s built-in controls; add your own infrastructure measures.
Version it in Git alongside your deployment config so changes are auditable.

Data Processing Agreement

This Data Processing Agreement (“DPA”) forms part of the agreement between [CONTROLLER LEGAL NAME] (“Controller”) and [PROCESSOR / OPERATOR LEGAL NAME] (“Processor”) for the provision of a self-hosted Orimora knowledge-base service (the “Service”). It governs the processing of personal data under Regulation (EU) 2016/679 (“GDPR”), Article 28.

1. Subject matter and duration

The Processor processes personal data on behalf of the Controller solely to provide and operate the Service. Processing lasts for the term of the underlying agreement and any wind-down period agreed in §9.

2. Nature and purpose of processing

Hosting, storage, retrieval, indexing, backup and transmission of knowledge-base content and account data, so the Controller’s authorised users can collaborate on documents.

3. Types of personal data

Account data: name, email address, locale, authentication factors (passkeys, TOTP), session metadata, IP address.
Content data: any personal data the Controller’s users place in documents, comments, attachments, tags.
Log/audit data: actor identity, action, timestamp, correlation ID, user-agent, outcome.

4. Categories of data subjects

The Controller’s employees, contractors, members, and any individuals referenced in the content they create.

5. Obligations of the Processor

The Processor shall:

(a) process personal data only on the Controller’s documented instructions (including this DPA), unless required by law (and then notify the Controller unless legally prohibited);
(b) ensure persons authorised to process the data are bound by confidentiality;
(c) implement the technical and organisational measures in Annex III;
(d) respect the conditions in §6 for engaging sub-processors;
(e) assist the Controller, by appropriate measures, in responding to data-subject requests (the Service provides self-service data export and account deletion, plus an admin audit log);
(f) assist the Controller with security, breach notification, DPIAs and prior consultation (Art. 32–36);
(g) at the Controller’s choice, delete or return all personal data at the end of the engagement (§9);
(h) make available information necessary to demonstrate compliance and allow for and contribute to audits (§8).

6. Sub-processors

The Controller provides general written authorisation for the Processor to engage the sub-processors listed in Annex II (the live Sub-processor list). The Processor shall:

impose data-protection obligations on each sub-processor no less protective than this DPA;
remain fully liable for its sub-processors’ performance;
inform the Controller of intended changes (additions/replacements) in reasonable time, giving the Controller the opportunity to object.

7. International transfers

The Processor shall not transfer personal data outside the EEA except under a valid transfer mechanism (e.g. adequacy decision or Standard Contractual Clauses). Where a sub-processor in Annex II is outside the EEA, the applicable mechanism is noted there.

8. Audits

The Processor shall, on reasonable notice and no more than once per year (unless required by a supervisory authority or after an incident), make available the information necessary to demonstrate compliance with Art. 28 and allow for audits by the Controller or a mandated auditor, subject to confidentiality.

9. Return or deletion

On termination, the Processor shall, at the Controller’s choice, return or irreversibly delete all personal data (including copies) within [N] days, unless retention is required by law. Encrypted backups are purged on their normal rotation; the latest rotation interval is [BACKUP_RETENTION].

Limitation — externally exported audit data. Where the Controller enables the optional SIEM/audit export (HTTP, syslog or file sink), the exported audit events leave the Service’s storage and become records held in the Controller’s own infrastructure. Those external copies are append-only and outside the Processor’s reach: account deletion and data-subject erasure inside the Service do not propagate to them. Erasure or retention of audit data already exported to the Controller’s SIEM is the Controller’s responsibility, to be handled under the Controller’s own retention and erasure policy.

10. Breach notification

The Processor shall notify the Controller without undue delay and at the latest within [N e.g. 48] hours after becoming aware of a personal-data breach, with the information required under Art. 33(3) to the extent available.

Annex I — Parties and processing details

Field	Value
Controller	`[CONTROLLER LEGAL NAME, ADDRESS]`
Processor	`[OPERATOR LEGAL NAME, ADDRESS]`
Controller contact / DPO	`[NAME, EMAIL]`
Processor contact / DPO	`[NAME, EMAIL]`
Subject matter	See §1
Duration	Term of the underlying agreement
Nature & purpose	See §2
Types of personal data	See §3
Categories of subjects	See §4

Annex II — Sub-processors

See the live Sub-processor list, which reflects the external services your deployment is configured to use. Reproduce the relevant rows here at signing time and keep them versioned.

Annex III — Technical and organisational measures

Built into Orimora (verify against your version):

Encryption in transit: TLS for all browser and API traffic (operator-terminated).
Encryption at rest: AES-256-GCM for stored secrets (IdP client secrets, SAML keys, TOTP secrets, API/LLM/publishing credentials); age-encrypted off-site backups.
Authentication: passwordless (magic-link / SSO), optional passkeys and TOTP, team-enforceable MFA, single-session-per-user with idle + absolute timeout.
Access control: capability-based RBAC, per-collection restrictions, step-up re-verification for sensitive actions.
Auditability: append-only audit log with actor, action, correlation ID, outcome and configurable retention.
Token handling: API/SCIM/OAuth tokens and backup codes stored only as HMAC-SHA256 hashes; rate-limiting fail-closed on auth paths.
Resilience: automated encrypted backups with restore verification and a documented disaster-recovery runbook.

Operator-supplied measures (you fill in): physical/host security, network segmentation, personnel vetting, patch cadence, monitoring/alerting, your TLS termination and key custody.