Skip to content

Data Processing Agreement (DPA)

Last updated: October 2026

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".

For Business Customers

kanman processes source code, tracker content and logs on your behalf, which can contain personal data. This DPA forms part of every customer contract. Contact us at support@kanman.ai for a signed version.

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:

  • Turning requirements into stories with acceptance criteria and writing them to the Controller's tracker
  • Running coding agents on the Controller's source code in an isolated sandbox and opening pull requests
  • Verifying results against acceptance criteria and storing the evidence (test reports, screenshots, traces)
  • Sending prompts and the code and tracker context needed for a run to the AI model provider chosen by the Controller
  • Recording decisions and actions in an audit log and providing exports
  • User authentication and access management
  • 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 requests, including author names and email addresses in commit history and code comments
  • Tracker content: issues, stories, comments, assignees
  • CI logs: build and test output of the Controller's pipelines
  • Run artifacts and evidence: acceptance 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

Data subjects are:

  • 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 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 and trackers 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;
  • compliance with data protection regulations is regularly verified.

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

6. Obligations of the Processor

6.1 Instruction Binding

The Processor shall process personal data only on documented instructions from the Controller, unless required to do so by Union or Member State law. In such a case, the Processor shall inform the Controller of that legal requirement before processing, unless that law prohibits such information. The Processor does not use the Controller's data to train AI models.

6.2 Confidentiality

The Processor shall ensure that persons authorized to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.

6.3 Security of Processing

The Processor shall implement all measures required under Art. 32 GDPR. The technical and organizational measures (TOMs) are described in Annex 1.

6.4 Sub-processors

The Controller hereby grants general authorization for the engagement of sub-processors. The Processor shall inform the Controller of any intended changes concerning the addition or replacement of sub-processors, thereby giving the Controller the opportunity to object to such changes. Current sub-processors are listed in Annex 2. Where the Controller uses its own contract with a model provider (BYOK), that provider is engaged by the Controller directly and is not a sub-processor of the Processor.

6.5 Assistance to the Controller

The Processor shall assist the Controller:

  • in fulfilling the obligation to respond to requests from data subjects (Art. 15-22 GDPR);
  • in ensuring compliance with obligations under Art. 32-36 GDPR (security, data protection impact assessment, prior consultation);
  • in case of personal data breaches pursuant to Art. 33-34 GDPR.

6.6 Retention, Deletion and Return

During the term, audit log entries are kept for the retention period configured for the workspace, by default 365 days. Evidence artifacts and run logs are kept for the retention period configured for the workspace, by default as stated in the documentation at docs.kanman.ai/en/security/retention/. Source code checked out for a run is discarded when the run's sandbox is removed. Upon termination of the main agreement, the Controller can export its data, including the audit log, until the end of the contract period. The Processor shall then delete all personal data within 30 days, unless retention is required under Union or Member State law. Upon request of the Controller, data shall be returned in a common format before deletion.

6.7 Demonstration of Compliance and Audits

The Processor shall make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Art. 28 GDPR and allow for and contribute to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller.

7. Data Transfers to Third Countries

Transfer of personal data to third countries shall only take place if the special requirements of Art. 44-49 GDPR are met. For transfers to the USA, EU Standard Contractual Clauses (SCCs) and, where applicable, certifications under the EU-US Data Privacy Framework are used. Application data is hosted in the EU 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 is governed by Art. 82 GDPR. Each party shall be liable to data subjects for the entire damage resulting from processing that violates the GDPR. The party that has paid compensation may claim back from the other party the part of the compensation corresponding to their part of responsibility for the damage.

9. Final Provisions

Amendments and supplements to this DPA require text form. Should individual provisions be invalid, the validity of the remaining provisions shall remain unaffected. German law applies.


Annex 1: Technical and Organizational Measures (TOMs)

Physical Access Control

Server infrastructure is operated by certified data centers of the sub-processors listed in Annex 2 that have physical access controls, surveillance, and security personnel. For self-hosted runners, physical security is the Controller's responsibility.

System Access Control

  • Password policies for all user accounts
  • Encrypted storage of passwords (bcrypt)
  • Session management with automatic timeout
  • Administrator access only for authorized personnel

Data Access Control

  • Role-based access control within workspaces
  • Permission separation between workspaces
  • Repository, path and merge permissions limited by the Controller's policy
  • Access logging and an append-only audit log

Sandbox Isolation

  • Each run executes in its own isolated sandbox
  • The sandbox is removed after the run, together with the checked-out code
  • Acceptance checks run on a clean checkout

Secrets Handling

  • API keys, tokens and model provider keys are stored encrypted
  • Secrets are made available only to the run that needs them
  • Secrets are not written to logs or evidence artifacts

Transmission Control

  • TLS encryption for all data transfers
  • Encrypted database connections
  • No unencrypted data transfer

Storage Encryption

  • Encryption of stored data at rest

Input Control

  • Logging of data changes
  • Audit log of actions, decisions and approvals

Availability Control

  • Regular automatic backups
  • Monitoring and alerting
  • Disaster recovery procedures

Separation Control

  • Logical separation of customer data through workspace IDs and row-level access rules
  • Strict isolation between customers

Annex 2: List of Sub-processors

Platform

Sub-processor Location Purpose Safeguards
Supabase Inc. USA (EU hosting in Stockholm, Sweden) Database, authentication, file storage SCCs, DPA
Fly.io, Inc. USA (processing in Frankfurt am Main, Germany) Cloud runner: sandbox in which coding agents run (not used with a self-hosted runner) SCCs, DPA
Cloudflare Inc. USA CDN, DDoS protection, DNS DPF, SCCs, DPA
Stripe Payments Europe Ltd. Ireland Payment processing DPA
Resend, Inc. USA Transactional email (reports, notifications) SCCs, DPA

Model Providers per Executor

Only the provider of the model the Controller selects receives data, and only if the Controller uses model access through the Processor. With BYOK, the provider is engaged by the Controller directly and is not a sub-processor.

Executor Model provider Purpose Safeguards
Claude Code Anthropic (USA), or Anthropic models via Amazon Bedrock (Amazon Web Services) Model inference for intake, coding and review DPF where certified, SCCs, DPA, no training on customer data
Codex OpenAI (USA), or OpenAI models via Microsoft Azure OpenAI Service Model inference for intake, coding and review DPF where certified, SCCs, DPA, no training on customer data

Changes to this list will be communicated to the Controller at least 14 days before taking effect.


Contact

For questions about this DPA or to request a signed version:

Email: support@kanman.ai