--- title: "Data processing agreement" description: "The Article 28 agreement template, with the annexes describing the processing, the security measures and the sub-processors." canonical: https://keepitlocal.app/dpa last-updated: 2026-09-13 --- # Data processing agreement The Article 28 agreement template, with the annexes describing the processing, the security measures and the sub-processors. Template. Version 0.1 (draft). Last updated 7 September 2026. This is our standard data processing agreement under Article 28 of the UK and EU General Data Protection Regulation. It is published so that you can read it before you ask for it. A signable copy is available from hello@keepitlocal.app, and we will countersign it. It applies where we process personal data on your behalf. For the personal data we hold as a controller in our own right, for example your own account record, the [privacy notice](/privacy) applies instead. ## 1. Parties and roles - **Controller**: you, the customer named in the order or the account holder. - **Processor**: KeepItLocal, [registered company name and address to be filled in]. You determine the purposes and means of the processing described in Annex I. We process only on your documented instructions, of which your use of the service and these terms are the initial and standing set. Note the shape of this service before reading further: document content is processed inside your browser and is never transmitted to us. There is therefore no repository of your document content for us to process, disclose, lose or return. What we process on your behalf is the account and workspace data listed in Annex I. ## 2. Our obligations We will: - process personal data only on your documented instructions, including on transfers, unless we are required to do otherwise by law, in which case we will tell you first unless the law forbids it - tell you if, in our opinion, an instruction infringes data protection law - make sure every person authorised to process the data is bound by confidentiality - implement the technical and organisational measures in Annex II, and keep them under review - respect the conditions in clause 3 for engaging a sub-processor - assist you, by appropriate technical and organisational measures and so far as is possible, in responding to data subject requests - assist you with your obligations under Articles 32 to 36, taking into account what we know and what we can see - on the end of the service, delete or return the personal data as you choose, and delete existing copies except where law requires us to keep them - make available the information needed to demonstrate compliance with Article 28, and allow and contribute to audits under clause 8 ## 3. Sub-processors You give general authorisation for the sub-processors listed on the [sub-processors page](/subprocessors), which is Annex III to this agreement. We will update that page and give at least 30 days' notice before a new sub-processor starts processing. If you reasonably object within that period, we will work with you to find an alternative, and if we cannot, you may terminate the affected part of the service and receive a refund of the unused prepaid period. Every sub-processor is engaged under a written contract imposing obligations equivalent to these. We remain fully liable to you for their performance. ## 4. Security We implement the measures in Annex II. Both parties acknowledge that Annex II reflects the state of the service at the version and date above, and that measures may change, provided that the level of protection is not reduced. ## 5. Personal data breach We will notify you without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting personal data processed on your behalf. The notification will describe the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Where we cannot give all of that at once, we will give it in stages without further undue delay. Our internal procedure is published as our incident response runbook. ## 6. Data subject requests If we receive a request from one of your data subjects that relates to data we process on your behalf, we will not respond to it ourselves except to acknowledge it and to direct the person to you, unless you have instructed us otherwise. We will pass it to you without undue delay and help you answer it. ## 7. International transfers The service is hosted in the European Union. [Provider to be confirmed.] Where a sub-processor processes data outside the EEA or the UK, the transfer is made under the European Commission's standard contractual clauses (module three, processor to processor, or module two where the sub-processor acts for us as controller), together with the UK international data transfer addendum where UK data is involved. The sub-processors page names the mechanism for each one. ## 8. Audits We will provide, on request and no more than once a year, the information needed to demonstrate compliance with Article 28, including our current security documentation. Where that is not enough for your regulator or your own obligations, we will accept an audit by you or an independent auditor you appoint, on reasonable notice, during business hours, subject to confidentiality, and not in a way that risks other customers' data. Each party bears its own costs; you bear ours if the audit is more frequent than annual and finds no material issue. ## 9. Deletion and return You can delete your account and its workspaces from the product at any time, which is the primary deletion mechanism. On termination, and at your choice, we will delete or return the personal data we process on your behalf within 30 days, except for issued export certificates (see the privacy notice) and anything law requires us to keep, which stays subject to these terms for as long as we hold it. ## 10. Liability and precedence Liability under this agreement is subject to the limitations in the [terms of service](/terms). If this agreement conflicts with those terms on the processing of personal data, this agreement prevails. If it conflicts with the standard contractual clauses, the clauses prevail. --- ## Annex I: description of the processing **Subject matter.** Provision of the KeepItLocal Redact web service: account and workspace management, browser-side document redaction, and the issuing and verification of export certificates. **Duration.** For as long as your account or subscription is in place, plus the retention periods set out in the retention schedule. **Nature and purpose.** Hosting an account, authenticating users, managing workspace membership, recording an audit trail of security-relevant actions, metering exports, signing and verifying certificates, serving shared report links, and sending transactional email. **Categories of data subject.** Your personnel and contractors who hold accounts or are invited to a workspace; recipients of a shared report link. **Categories of personal data.** - account email and name (and, for Google sign-in, the profile photo URL) - session metadata (session token hash, creation and expiry time, user agent, network address) - rate-limit keys, which can contain a network address, a user id or an email address - audit rows (action, actor id, workspace id, target, timestamp, network address, user agent, scrubbed metadata) - certificate hashes and counts (two SHA-256 checksums, redaction and page counts, engine version, issuing account and workspace ids) - shared report metadata (file name, checksums, counts, per detector tallies, optional password hash, expiry, view log) - early access requests (email address, organisation), where the person submitted the landing form - billing data held by Paddle as merchant of record; we hold the subscription reference and plan tier only **Special category data.** None is requested or required. Document content, which may contain any category of data, is processed in the browser and is never transmitted to us. **Frequency.** Continuous, for as long as the service is used. --- ## Annex II: technical and organisational measures Status is stated honestly: "in place" means implemented in the service today, "in progress" means it is being built and is not yet something to rely on. | Measure | How it is implemented | Status | | --- | --- | --- | | Data minimisation by architecture | Document content is processed in the browser. The server receives two SHA-256 checksums and a small set of counts per export, enforced by a content security policy with `connect-src 'self'` | In place | | Encryption in transit | TLS for all traffic; HSTS with a two-year max-age, `includeSubDomains` and `preload` in production; the application refuses to boot in production unless its public origin is https | In place | | Encryption at rest, application level | AES-256-GCM for stored two-factor secrets; HMAC-SHA256 for backup codes; passwords hashed with Argon2id; session and verification tokens stored as SHA-256 digests, never in the clear | In place | | Encryption at rest, storage level | Managed Postgres with provider-level disk encryption in an EU region | In progress, see the hosting item below | | Authentication | Argon2id passwords, optional TOTP second factor for customers (RFC 6238 with a replay guard and single-use backup codes), optional Google sign-in with PKCE and state, and a required second factor for operators that the console cannot switch off | In place | | Session policy | Opaque 32-byte tokens, hashed at rest; httpOnly, secure, sameSite cookies with the `__Host-` prefix in production; idle timeout 1 day and absolute cap 14 days for customers, 8 hours and 24 hours for operators, enforced server side on every request; users can list and revoke their own sessions | In place | | Access control and segregation | Every protected page and every server action calls an authorisation guard, proven by a test that walks the source tree and fails the build if one does not; role-based access control within a workspace; every query scoped by workspace id; a separate administration identity, session and cookie from customer accounts | In place | | Audit trail | A record of security-relevant actions including failures (sign-in, failed sign-in, session revocation, password change, two-factor changes, membership and role changes, plan changes, authorisation denials, rate-limit blocks, administrative actions), with metadata passed through an allowlist scrubber before it is written, and a customer's email address reduced to its domain for failure events, never recorded in full; an operator's own address is recorded so that console actions stay attributable | In place | | Tamper evidence on the audit trail | Each audit row carries a SHA-256 over its stable fields and the previous row's hash, appended under a lock and verified from the console, so a row that is deleted, reordered or rewritten breaks the chain. The fields a deletion clears (actor, workspace, network address, user agent, metadata) are outside the hash on purpose, so that erasing an account is not indistinguishable from tampering | In place; revoking update and delete on the table from the application role waits on the hosting decision | | Rate limiting and abuse control | Atomic fixed-window limiters on sign-in, sign-up, password reset, two-factor, invitations, early access, engine tickets and export permits, failing closed on the authentication paths | In place | | Application hardening | Nonce-based content security policy with `strict-dynamic`, `object-src 'none'`, `frame-ancestors 'none'`, `base-uri` and `form-action` pinned to self, nosniff, a strict referrer policy and a permissions policy denying camera, microphone and geolocation | In place | | Integrity of exports | Export certificates signed with Ed25519 over canonicalised JSON and re-verified on every read, so an altered record reports itself as invalid rather than certifying something nobody signed | In place | | Input validation | Every route and every server action validates and bounds its input before any database access, in nearly every case with a schema | In place | | Retention and disposal | A retention period per data category, applied by a purge that records every run | In place; the scheduler that calls it is provisioned with the hosting decision | | Deletion on request | Self-service account deletion with password re-authentication, or a typed confirmation checked on the server where the account has no password, running in a serializable transaction, removing sole-owned workspaces first and reaching the rows that carry a user identifier without a relation | In place | | Portability | Self-service export of everything tied to an account, downloaded as a zip from Settings | In place | | Backup and restore | Managed Postgres with point-in-time recovery, a stated recovery point and recovery time objective, and a recorded restore drill | Documented, not yet demonstrated: the provider is not chosen | | Vulnerability management | Dependency audit and secret scanning in continuous integration | In place | | Personnel | Confidentiality obligations for everyone with access; access limited to those who need it; a quarterly review of who holds administrative access, with the result recorded | Process control, quarterly review in progress | | Incident response | A documented runbook with severity levels, first actions, evidence preservation, notification clocks and templates | In place, see the incident response runbook | --- ## Annex III: sub-processors The current list, with the purpose, the data received and the region for each, is published at [/subprocessors](/subprocessors) and forms part of this agreement. --- ## Open items before this template is signed - The company name, registered address and signature block are placeholders. - The hosting provider and therefore the storage-level encryption and backup statements are not settled. - Counsel should confirm the breach notification window in clause 5, the audit terms in clause 8, and which module of the standard contractual clauses applies to each sub-processor.