Data Processing Agreement (DPA)

Last changed: 31 October 2026. This English version is a courtesy translation; only the German version is legally binding.

This Data Processing Agreement (DPA) pursuant to Art. 28 GDPR applies between the Customer as Controller and Marco Kerwitz, kerwitz.dev, Birkenweg 21, 31226 Peine, Germany (hereinafter "Processor") for the use of the SaaS service "kanman".

1. Subject Matter and Duration of Processing

1.1 Subject Matter

The Processor provides the Controller with "kanman", an AI teammate that operates on the repositories and issue trackers connected by the Controller, as a SaaS solution. In the course of this service provision, the Processor processes personal data on behalf of the Controller.

1.2 Duration

The duration of processing corresponds to the term of the main agreement for the use of kanman. Upon termination of the main agreement, data will be deleted or returned in accordance with section 6.6.

2. Nature and Purpose of Processing

Processing serves to provide the kanman service, in particular:

• Taking requirements, writing stories and keeping them in step with the Controller's tracker
• Running coding agents on the Controller's source code in an isolated environment and opening pull or merge requests
• Checking results (for example with tests and reviews) and storing run artifacts (logs, reports, screenshots)
• Sending prompts and the code and tracker context a step needs to the model provider, where the Controller uses model access through kanman
• Conversations with kanman in the application and in connected channels (for example Slack, Microsoft Teams, email)
• Recording decisions and actions in an audit log and providing exports
• Authentication and access management of users
• Emails and push notifications to the Controller's users
• Provision of API, webhook and chat integrations
• Technical support and troubleshooting

3. Types of Personal Data

The following categories of data, which may contain personal data, are processed:

• Account data: name, email address and role of the Controller's users
• Source code and repository metadata: code, branches, commits, pull or merge requests, including author names and email addresses in commit history and code comments
• Tracker content: issues, stories, comments, assignees
• Messages: conversations with kanman and messages from connected channels
• CI logs: build and test output of the Controller's pipelines
• Run artifacts: test reports, screenshots, browser traces, run logs
• Audit log entries: actions, decisions, approvals, costs, timestamps and the users involved
• Usage data: login data, activity logs, IP addresses

4. Categories of Data Subjects

• Employees and agents of the Controller
• Other users to whom the Controller grants access to kanman
• Persons named in the Controller's source code, commit history, tracker content, messages or logs (for example contributors and reporters)

5. Obligations of the Controller

The Controller is responsible for the lawfulness of data processing and ensures that:

• an appropriate legal basis for processing exists;
• data subjects have been properly informed;
• instructions to the Processor are lawful;
• only repositories, trackers and channels are connected that the Controller is entitled to process;
• where the Controller uses its own model provider contract (BYOK) or a self-hosted runner, the Controller's own agreements and measures for these are in place.

The Controller's settings in the application (connected repositories, trackers and channels, model provider, BYOK, cloud or self-hosted runner, retention periods, policies) are documented instructions within the meaning of section 6.1.

6. Obligations of the Processor

6.1 Instructions

The Processor processes personal data only on documented instructions from the Controller, including with regard to transfers to third countries, unless required to do so by Union or Member State law. In such a case, the Processor informs the Controller of that legal requirement before processing, unless that law prohibits such information. If the Processor considers that an instruction infringes data protection law, it informs the Controller without undue delay. The Processor does not use the Controller's data to train AI models.

6.2 Confidentiality

The Processor ensures that persons authorized to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. At present, only the owner, Marco Kerwitz, processes the data.

6.3 Security of Processing

The Processor implements the measures required under Art. 32 GDPR. The technical and organizational measures (TOMs) are described in Annex 1. The Processor may develop them further as long as the level of protection does not decrease.

6.4 Sub-processors

The Controller hereby grants general authorization for the engagement of sub-processors. The sub-processors currently engaged are listed on the sub-processor page (Annex 2). The Processor imposes on each sub-processor by contract the same data protection obligations as set out in this DPA, in particular sufficient guarantees for appropriate technical and organizational measures. The Processor remains liable to the Controller for the performance of its sub-processors' obligations.

The Processor informs the owners of the Controller's workspaces by email at least 14 days before any intended addition or replacement of a sub-processor and updates the list with the date. The Controller can object within this period in text form on reasonable data protection grounds. If no agreement is reached, the Controller can terminate the affected services before the change without further cost. If a sub-processor has to be replaced at short notice, the Processor informs without undue delay; the right to object and to terminate then runs from the notice.

Where the Controller uses its own contract with a model provider (BYOK), its own AI gateway or a self-hosted runner, the provider concerned is engaged by the Controller directly and is not a sub-processor of the Processor. The same applies to services the Controller connects (for example GitHub, GitLab, Jira, Slack).

6.5 Assistance to the Controller

The Processor assists the Controller:

• in responding to requests from data subjects (Art. 15 to 22 GDPR); requests received directly by the Processor are forwarded to the Controller;
• in complying with the obligations under Art. 32 to 36 GDPR (security, data protection impact assessment, prior consultation);
• in case of personal data breaches: the Processor notifies the Controller of a breach without undue delay after becoming aware of it, with the information under Art. 33(3) GDPR as far as available.

6.6 Retention, Deletion and Return

During the term, audit log entries are kept for the period configured for the workspace, by default 365 days. Runs, run artifacts, decisions and activity are kept as long as the team exists. Details are in the documentation at docs.kanman.ai/en/security/retention/. Source code checked out for a run is discarded together with the run's machine. Until the end of the contract, the Controller can export its data, including the audit log. Deleted teams and workspaces are erased for good 30 days after deletion, unless Union or Member State law requires storage. Data contained in database backups is deleted as the backups expire in their regular cycle. Upon request of the Controller, data is returned in a common format before deletion.

6.7 Demonstration of Compliance and Audits

The Processor makes available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Art. 28 GDPR and allows for and contributes to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller. Audits are announced with reasonable notice and carried out so that operations are not disrupted disproportionately.

7. Data Transfers to Third Countries

Personal data is only transferred to third countries if the requirements of Art. 44 to 49 GDPR are met. For transfers to the USA, EU Standard Contractual Clauses and, where the recipient is certified, the EU-US Data Privacy Framework are used. Which mechanism applies to which sub-processor is shown in Annex 2. Application data is stored in Stockholm, Sweden, and the cloud runner operates in Frankfurt am Main, Germany. With a self-hosted runner, code execution takes place in the Controller's own network.

8. Liability

Liability towards data subjects is governed by Art. 82 GDPR. Between the parties, the liability provisions of the Terms of Service apply.

9. Final Provisions

Amendments and supplements to this DPA require text form. In case of conflicts between this DPA and the main agreement, this DPA prevails on data protection matters. Should individual provisions be invalid, the validity of the remaining provisions remains unaffected. German law applies.

Annex 1: Technical and Organizational Measures (TOMs)

Physical Access Control

kanman operates no servers of its own. The infrastructure runs in data centers of the sub-processors listed in Annex 2, with their physical access controls. For self-hosted runners, physical security is the Controller's responsibility.

System Access Control

• Sign-in with email and password (at least 8 characters) checked against known leaked passwords, or with a sign-in link
• Passwords are stored only as a hash (bcrypt)
• Short-lived access tokens with automatic renewal
• Limit on sign-ups per IP address and blocking of known disposable email domains
• Only the owner has access to the production systems (database, hosting, email, payments), through personal accounts with the respective providers

Data Access Control

• Roles within a workspace (owner, admins, members, team leads)
• Tenant isolation in the database through row-level security: enabled on every table; tables used only by the server are not reachable by users
• Repository, path and merge permissions limited by the Controller's policy
• An audit log that can only be appended to and cannot be edited or deleted by hand

Run Isolation

• Each cloud run executes on its own machine, which is removed after the run together with the checked-out code
• Each run gets its own token that only works for this run and ends with it
• The coding agent receives neither code host credentials nor model keys in its environment; these are reached through a proxy outside the agent
• Only the host, not the agent, pushes changes, after scanning the diff for credentials

Secrets Handling

• Model provider keys are stored encrypted with AES-256-GCM and erased when a workspace is deleted
• Secrets are made available only to the run that needs them
• Text from the host, the agent and models passes a redaction step before it is stored, which removes credentials and the run's known secret values

Transmission Control

• TLS encryption for all connections; the application enforces HTTPS (HSTS)
• Encrypted database connections

Storage Encryption

• Encryption of stored data at rest by the hosting providers

Input Control

• Audit log of actions, decisions and approvals, with export
• Activity log per team

Availability Control

• Daily automatic database backups
• Automatic availability checks and alerts to the owner
• Documented procedures for restore, rollback and emergency stop

Separation Control

• Logical separation of customer data through workspace IDs and row-level security
• One machine per run

Review of the Measures

• Automatic checks on every code change, among them a scan for credentials in the code and tests of the database's security rules
• Regular review of the database provider's security advisories

Annex 2: Sub-processors

The list of sub-processors with purpose, data categories, location and transfer mechanism is at kanman.ai/en/subprocessors. It forms part of this DPA.

Contact

For questions about this DPA:

Email: [email protected]