# Data Processing Agreement (template) **Codelux AI — GDPR Article 28 data processing agreement** Template version 1 — 28 September 2026. Aligned with the Privacy Policy published as Legal v9. > This is a template. Fields in `[square brackets]` are completed when the agreement is > signed. It is not legal advice: each party should have it reviewed by its own counsel. > Ask for a countersigned copy at **hello@codelux.ai** (subject: "DPA"). --- ## Parties **Controller ("Customer")** `[Company name]`, `[registered address]`, `[VAT / company number]`, represented by `[name, role]`, contact for data protection matters: `[email]`. **Processor ("Codelux")** The sole proprietor trading as **Codelux** (codelux.ai), established in Italy. Registered name, address and VAT number are given in the signature block and are in the Privacy Policy, section 11 "Service Details". Contact: **hello@codelux.ai**. The Customer buys a Team or Enterprise subscription (the "Main Agreement", i.e. the Terms of Service accepted at purchase, plus any Enterprise order form). This DPA forms part of the Main Agreement and prevails over it on the processing of personal data. --- ## 1. Scope and roles 1.1 Codelux processes personal data **on behalf of the Customer** when the Customer's authorised users (owner, organisation admins, team admins and members) use the Team or Enterprise plan: to run the Customer's teams, deliver end-to-end encrypted team events between the users' machines, coordinate file locks and presence, and (from version 3.7) provision users through SSO and SCIM. For this processing the Customer is the controller and Codelux is the processor. 1.2 Codelux remains an **independent controller** for the processing it carries out for its own purposes, described in the Privacy Policy: billing and tax records (10-year retention under Italian law), fraud and abuse prevention (including licence enforcement through the one-way hardware hash), security monitoring of its own website, and the anonymous page-flow analytics of its public website. That processing is outside this DPA. 1.3 **What Codelux does not process.** The Codelux app runs on the users' own machines. The source code, the code index, and the memories, notes, timeline and file-lock history kept in each project's local databases are processed only on those machines and never reach Codelux, except, for Team projects, as ciphertext (clause 1.4). Codelux does not send any data to an AI provider: the AI agent each user runs, and its provider, are chosen by the Customer and process data under the Customer's own contracts. 1.4 **End-to-end encrypted team content.** Shared memories, notes, journal, facts, code maps, timeline events and chat reach Codelux only as ciphertext sealed on the author's machine with AES-256-GCM under a team key that is generated on the team owner's machine and never transmitted to Codelux. Codelux stores and relays this ciphertext but **cannot read it**, and cannot tell which kind of record an event is. The Customer remains responsible for what its users write into it (see clause 5.3). --- ## 2. Details of the processing (Annex I) | Item | Description | |---|---| | Subject matter | Hosting of team metadata, relay and storage of end-to-end encrypted team events, account and device management for the Customer's users, and (from 3.7) SSO/SCIM identity management. | | Duration | The term of the Main Agreement, plus the deletion periods in clause 9. | | Nature of processing | Collection, storage, transmission, organisation, restriction and erasure; automated only; no profiling. | | Purpose | Providing the Team / Enterprise service as described in the Main Agreement. | | Data subjects | The Customer's authorised users (owner, organisation admins, team admins, members) and people the Customer invites by email. Any person mentioned inside encrypted team content (not readable by Codelux). | | Categories of personal data | See the table below. | | Special categories (Art. 9) | None intended. Codelux cannot see encrypted content; the Customer must not use team content for special-category data unless it has its own legal basis and safeguards. | | Frequency | Continuous while the service is used. | **Categories of personal data processed on the Customer's behalf** | Category | Data | Retention (see also clause 9) | |---|---|---| | Account identity | Email address, display name, role in each team, membership status and timestamps of invitation, acceptance and removal. | While the account and team exist. | | Authentication | Password as a bcrypt hash; one-time email codes (6 digits, 10–15 minutes); from 3.7, linked sign-in identities (provider, subject, email) and SSO / SCIM attributes supplied by the Customer's identity provider. | Codes deleted after use or expiry; identities until unlinked or the account is deleted. | | Device and licence | One-way SHA-256 hash of the machine identifier, SHA-256 of the app binary, installation identifier, per-device public key (X25519), IP address and country code of requests. | Session / heartbeat / device logs 30 days; security and account events 12 months. | | Project list | Project names chosen by users and the local folder path of each project on each machine (a path can contain the operating-system user name; never the files in it). | Until the project is removed or the team is closed. | | Team metadata | Team name and identifier, shared project identifiers and names, member-to-machine folder mapping, team key **version number** (never the key). | For as long as the team exists; a member's per-machine paths and public keys are deleted when the member leaves or is removed. | | Invitations | Invitation log: invited address, sender, delivery result, IP address, time. | 12 months. | | Encrypted team events | Ciphertext plus delivery metadata: team, project, authoring member, time received, size, key version, sequence number. | For as long as the team exists; deleted within seconds when the team is closed. | | Locks and presence | Relative file path being edited, member, agent name, expiry — processed in clear to prevent collisions, never file contents. | While the session is open, at most 24 hours. | | Organisation audit log (from 3.7) | Actor, action, target, detail and IP address of SSO / SCIM / organisation-admin changes. | `[12 months]` | --- ## 3. Processor obligations (Art. 28(3)) Codelux shall: a) process personal data only on documented instructions from the Customer — the Main Agreement, this DPA and the settings the Customer's administrators choose in the service — including with regard to transfers to third countries, unless required by EU or Member State law, in which case it informs the Customer before processing unless that law forbids it; b) ensure that every person authorised to process the personal data is bound by confidentiality. At the date of this template, the only person with administrative access to the production systems is the proprietor; c) implement the technical and organisational measures in Annex II (Art. 32); d) respect the conditions for engaging sub-processors in clause 4; e) assist the Customer, taking into account the nature of the processing, with appropriate technical and organisational measures for the fulfilment of data-subject requests (Art. 12–22). Most requests can be handled by the Customer directly: removing a member, deleting a team, exporting the timeline and the team audit package from the app; f) assist the Customer with its obligations under Art. 32–36 (security, breach notification, impact assessments, prior consultation), taking into account the nature of processing and the information available to Codelux; g) at the end of the service, delete the personal data as set out in clause 9; h) make available all information necessary to demonstrate compliance with Art. 28 and allow for audits as set out in clause 8; and inform the Customer immediately if, in its opinion, an instruction infringes the GDPR or other data protection law. --- ## 4. Sub-processors 4.1 The Customer gives a general authorisation for Codelux to engage the sub-processors listed below. | Sub-processor | Service | Location of processing | Transfer safeguard | |---|---|---|---| | Kamatera, Inc. | Virtual private server hosting the website, the account database and the realtime service | Frankfurt, Germany (EU) | Processing within the EU; data processing agreement with Kamatera | | Cloudflare, Inc. | DNS, CDN, TLS termination and abuse protection for codelux.ai (every web request passes through its edge) | Global edge network; USA | Cloudflare DPA, EU Standard Contractual Clauses, EU-US Data Privacy Framework | | Dynadot Inc. | Mailbox hosting and transactional email (sign-in codes, invitations, receipts, support) | USA | EU Standard Contractual Clauses | | Stripe, Inc. | Payment processing for the Customer's subscription | USA | EU Standard Contractual Clauses | Notes: - Stripe processes the billing contact's data mainly as part of Codelux's own billing (clause 1.2); it is listed for completeness. - The realtime service runs on the same Kamatera server in Frankfurt; there is no separate realtime provider. - **Not sub-processors:** sign-in providers a user chooses (Google, GitHub, Slack, from 3.7) act as independent controllers of their own accounts; the Customer's own identity provider (Okta, Entra ID, Google Workspace, …) is the Customer's processor; AI providers are engaged by the Customer, not by Codelux; third-party connectors (Jira, Linear, Asana, Azure Boards, GitHub, GitLab, Slack notifications) are executed by the Customer's own company hub (`codelux-hub`) with the Customer's own tokens, not through Codelux. 4.2 Codelux informs the Customer of any intended addition or replacement of a sub-processor at least `[30]` days in advance, by email to the contact above. The Customer may object on reasonable data-protection grounds within that period; if the parties cannot agree, the Customer may terminate the affected service and receive a pro-rata refund of prepaid fees. 4.3 Codelux imposes on each sub-processor data protection obligations equivalent in substance to this DPA and remains liable to the Customer for their performance. --- ## 5. Customer obligations 5.1 The Customer has a lawful basis for the processing it instructs and has informed its users (including, where relevant, as workers — per-member reports and exports are the Customer's responsibility under its employment and works-council rules). 5.2 **The team key.** The team key is held only by the Customer's users. Codelux has no copy, no escrow and no recovery: if every copy is lost, the encrypted events stored by Codelux are permanently unreadable. The Customer is responsible for keeping the key safe and for rotating it when a member leaves (the app offers rotation; from 3.7, SCIM deprovisioning requests it). 5.3 The Customer is responsible for the content its users and their AI agents write into memories, notes and chat, and for not recording secrets or special-category data there without its own safeguards. 5.4 Data on the users' machines (local databases, the team key, exported audit packages) is under the Customer's control and outside Codelux's reach; securing those machines (disk encryption, access control, backups) is the Customer's responsibility. --- ## 6. International transfers Personal data is hosted in the EU (Frankfurt, Germany). Transfers to the sub-processors in the USA listed in clause 4 rely on the EU Standard Contractual Clauses (Commission Decision 2021/914) and, where the recipient is certified, the EU-US Data Privacy Framework. Codelux will not transfer personal data to any other third country without the Customer's prior authorisation under clause 4.2. --- ## 7. Personal data breaches 7.1 Codelux notifies the Customer **without undue delay and in any case within `[48]` hours** after becoming aware of a personal data breach affecting the Customer's data, at the contact email above. 7.2 The notification includes, as far as then known: the nature of the breach, categories and approximate numbers of data subjects and records, likely consequences, measures taken or proposed, and a contact point. Information not available at once is provided in phases. 7.3 Because team content is end-to-end encrypted with a key Codelux does not hold, a breach of Codelux's systems exposes ciphertext and metadata only, not team content. This does not remove the duty to notify. --- ## 8. Audits and information 8.1 Codelux makes available on request: this DPA, the security questionnaire (`security-questionnaire.md`), the deployment guide and a summary of the latest security reviews and tests. 8.2 **Certifications.** Codelux holds **no SOC 2 or ISO 27001 certification yet**. Where the Customer reasonably needs more than 8.1, it may audit Codelux once a year, with at least 30 days' notice, during business hours, at its own cost, by itself or by an independent auditor bound by confidentiality, limited to the systems that process the Customer's data and without access to other customers' data. --- ## 9. Deletion and return 9.1 **Team closed by the owner:** every encrypted event, delivery cursor, lock and presence record, key-request log, per-machine folder path and pending invitation of that team is erased from Codelux's servers immediately; the realtime service erases the encrypted events within seconds. A history entry (team name, identifier, closing date, key version) stays in the owner's dashboard until the owner deletes it, which removes every remaining row about that team. 9.2 **Member removed:** that member's per-machine folder paths and public keys are deleted at once. Events the member authored remain part of the team's encrypted history. 9.3 **Account deleted:** the account is disabled; name, password and two-factor settings are erased and every session revoked; the email address and the one-way machine hash are kept for abuse prevention (Codelux as controller, clause 1.2), billing records for the fiscal retention period. 9.4 **End of the Main Agreement:** unless the Customer closes its teams first, Codelux deletes the Customer's team data within `[30]` days of the end of the subscription, after giving the Customer the chance to export. Exports of team content are produced by the Customer's own app (the timeline export and the team audit ZIP), because Codelux cannot decrypt it; a copy of the metadata in clause 2 is available in JSON on request. 9.5 Copies already on the users' machines are not reached by any of the above and remain under the Customer's control. --- ## 10. Liability, term, law 10.1 Liability follows the Main Agreement, subject to Art. 82 GDPR. 10.2 This DPA lasts as long as Codelux processes personal data on the Customer's behalf. 10.3 Italian law governs this DPA; the courts named in the Main Agreement have jurisdiction. --- ## Annex II — Technical and organisational measures **Architecture** - Local-first: code, index, memories, notes, timeline and locks are stored on the users' machines. The local API and dashboard listen on loopback only (127.0.0.1 / ::1). - Team content end-to-end encrypted: AES-256-GCM, 256-bit team key generated on the owner's machine; the additional authenticated data binds each event to team, project, key version and author, so the server cannot move or relabel an event without breaking it. Team keys are delivered machine to machine in envelopes sealed with X25519 + HKDF-SHA256 + AES-256-GCM against each device's registered public key; the server relays but cannot open them. Key rotation adds a new version; older versions stay on members' machines. **In transit** - HTTPS for every call to codelux.ai; a release build refuses to run if configured with a non-HTTPS licence server. The website sends HSTS (two years, includeSubDomains). - Realtime connections over TLS only; a release build refuses a non-`tls://` realtime URL. The realtime credential is an Ed25519-signed token valid for 15 minutes. - Licence-server responses are signed with Ed25519 (key embedded in the binary), encrypted with a per-account AES-256 key and bound to a per-request nonce. **At rest** - Passwords: bcrypt. Recoverable secrets on the server (such as an SSO client secret, from 3.7) are encrypted with AES-256-GCM, with the key outside the database. SCIM tokens are stored as hashes. - Machine-bound credentials on the users' machines (device token, identity, team keys, device key pair) are sealed with AES-256-GCM under a key derived from the machine identifier (PBKDF2-SHA256, 50,000 iterations), in a state directory restricted to SYSTEM/Administrators/the installing user (Windows) or mode 0700 (Linux/macOS). The local project databases are **not** encrypted by the app: full-disk encryption on the users' machines is recommended. **Access control** - Email one-time code on every sign-in that issues credentials; password policy (minimum 10 characters with letters and digits); rate limits on every public authentication endpoint; constant-time comparisons against account enumeration. - Roles: Admin, Manager and Member (a person may hold several); organisation admins, SSO (OIDC and SAML) with optional "require SSO for this domain", SCIM 2.0 user provisioning and deprovisioning. - Production server administration by SSH public key only (password login disabled). **Logging and audit** - Server: security and account events (registration, sign-in, 2FA changes, plan changes) kept 12 months; session/heartbeat/device logs 30 days. - App: every write is a timeline event (who, which agent, when, what); timeline export (JSON/CSV) and a team audit ZIP for owners and admins, itself recorded as an event. **Resilience and testing** - Security reviews and internal penetration tests in September 2026 (see the security questionnaire, section H, for results and known limits). No independent third-party penetration test yet.