Data Processing Agreement

DRAFT for counsel review. Not legal advice.

Version: 2026-10-03.1

Between the customer organization ("controller") and [Company legal name] ("processor"). Part of the Terms of Service. Meets GDPR Art. 28, UK GDPR Art. 28, and the Israel Protection of Privacy Law 5741-1981 as amended by Amendment 13 (in force August 2025) with the Privacy Protection (Data Security) Regulations 2017.

1. Roles

• Case data (everything collected, derived or written for a case): the customer is the controller, we are the processor.
• Account, billing, vetting and security log data: we are the controller (privacy.md part A).

2. Subject matter, nature and purpose

3. Personal data and data subjects

• Subjects: people the controller names (directors, owners, officers, counterparties, candidates), and people found next to them in sources (associates, namesakes, relatives where material).
• Data: names and aliases, identifiers the controller supplies (email, phone, username, company and registration numbers), professional history, company roles and shareholdings, court and regulatory records, sanctions, PEP and watchlist status, adverse media, public social media content, domain and infrastructure records, breach exposure metadata (source, date, data classes; whether a password was present, never the password), photos for reuse checks, the analyst's notes.
• Special categories and criminal data: not targeted. Court and regulatory records may appear where public and material to the purpose; the controller needs its own basis for them (GDPR Art. 10, UK DPA 2018 Sch. 1). The report filter removes health, religion, sexual life, political opinion, union membership and ethnicity.

4. Instructions

We process case data only on the controller's documented instructions: the case gate, the modules chosen at launch, and these terms. If an instruction breaks the law or the AUP we say so and may refuse it.

5. Confidentiality

Everyone at the processor with access to case data is bound by confidentiality. Access is limited to the operator role, used for support, vetting, subject requests and incident response, and each use is logged.

6. Security

Annex 2. We review it at least yearly and after any incident.

7. Sub-processors

The controller authorizes the sub-processors in subprocessors.md. We give 30 days notice of a new one by email and in that file; the controller may object on reasonable data protection grounds, and if we cannot resolve the objection the controller may end the affected service with a pro rata refund. We impose terms on each sub-processor at least as protective as this agreement and stay liable for them.

8. Assistance

• Subject requests: we pass any request about case data to the controller within 5 business days and help it answer (subject_requests.md). We do not answer for the controller unless asked.
• DPIAs and prior consultation: we provide the information in dpia_template.md and ropa.md.
• Breaches: we notify the controller without undue delay and within 48 hours of becoming aware of a personal data breach affecting its data, with what we know then, and update as we learn more.

9. Deletion and return

• The controller can export reports at any time and purge a case at any time (the operator runs ot retention purge, which deletes the case's rows and files and its storage bucket objects).
• When a case passes its retention date it appears in ot retention list and is purged after the controller is reminded, unless the controller sets a later date with a reason.
• At the end of the Terms we delete all case data within 30 days after the export window.
• Backups: encrypted database backups and point-in-time recovery are kept for [35] days and cannot be edited. Data deleted from the live system stays in backups until they expire, and is not used in that time. If a backup is restored, every purge recorded in the audit log (retention.purge) after the backup date is applied again before the system goes back into service.
• Audit log entries are kept for the life of the organization plus [6] years; they hold case codes, actions and counts, not collected content.

10. Audits

We make available the information needed to show compliance: this pack, the threat model, test results and answers to a reasonable questionnaire once a year. On-site audits with 30 days notice, at the controller's cost, under confidentiality, no more than once a year unless a regulator requires it or after a breach.

11. Transfers

Hosting is in the EU (Germany). Some sub-processors are in the US (subprocessors.md). Transfers rely on an adequacy decision (the EU-US Data Privacy Framework where the recipient is certified), or the EU Standard Contractual Clauses (module 3, processor to processor) with the UK Addendum. Israel holds an EU adequacy decision; transfers out of Israel follow the Privacy Protection (Transfer of Data to Databases Abroad) Regulations 2001.

12. Liability and order of precedence

Liability follows the Terms. If this agreement and the Terms conflict on personal data, this agreement wins.

Annex 1. Processing details

Section 2 and section 3 above.

Annex 2. Security measures

• Hosting in EU regions; database, storage and worker each in a separate provider account with least privilege.
• Tenancy in the database: row level security on every tenant table; the web app runs every statement as the signed-in user and holds no credential that bypasses it. Storage paths are prefixed per organization and download links are signed per request for 60 seconds.
• Authentication: email confirmation, minimum password length, leaked password check, MFA required for owners and admins, bot check on signup and login.
• Encryption in transit (TLS) everywhere and at rest at each provider; backups encrypted with age.
• Worker: non-root container, read-only filesystem, egress filter to the public internet only.
• Audit: hash-chained, append-only audit log per organization; operator actions (approve, suspend, purge) are recorded with the operator's name.
• Collection rules: public and lawfully accessible sources only, no logged-in scraping under false identity, no use of leaked credentials, no plaintext passwords stored.
• Secrets outside the database, in each provider's secret store or a mode 600 file on the VM.
• Restore drill and key rotation procedures in deploy/README.md.