Data Processing Agreement

What this page is

This is the technical part of the data processing agreement between you, as the controller, and us, as your processor, under Art. 28 GDPR. It describes what we process on your behalf, where it happens, who else is involved, and what protects it.

It is written to be read by the people who actually have to assess it: security review, data protection, procurement. Nothing here is marketing copy. Where something is not built yet, it says so.

This page is not the contract. The contract is a signed document that incorporates this description as its annexes. Ask [email protected] and you get it as a PDF, or as a DOCX if your legal team wants to redline it. We also sign a customer’s own DPA where its terms are compatible with this description.

How this website handles personal data is a separate matter, and we are the controller for that. It is described on the Privacy & GDPR page.

1. Who is who

You decide what personal data goes into Cordango and why. That makes you the controller. We run the platform that stores and processes it on your instructions, which makes us the processor. The providers we use to run the platform are sub-processors, and every one of them is listed further down.

Processor
Tim Cadenbach, trading as Cordango
44894 Bochum, Germany
Privacy contact: [email protected]

We have not appointed a Data Protection Officer, because the thresholds in Art. 37 GDPR and § 38 BDSG are not met at our current size. The privacy contact above is the responsible person and answers directly. If that changes, this page changes with it.

2. Annex I: the processing, described

These are the Art. 28(3) particulars. A customer may narrow them in their own contract; they cannot be widened without one.

Subject matter and duration

Provision of the Cordango platform: hosting, storing and processing the records, files and application definitions you and your users create. Processing lasts for the term of the service agreement, plus the deletion period in section 8.

Nature and purpose

Storing, structuring, retrieving, displaying, combining, exporting and deleting the data you put into your workspace, so that the applications you build on it work. Plus the ancillary processing that keeps a platform running: backups, error diagnosis, security monitoring and capacity planning.

Categories of data subjects

• Your employees and other members of your workspace.
• Your customers, prospects, suppliers and partners, and the individuals who work for them.
• Anyone else whose data you choose to record in an application you build. We do not control this, which is why the list cannot be exhaustive.

Categories of personal data

• Account data: name, work email address, identity-provider subject identifier, role and team membership, workspace permissions.
• Usage and audit data: who changed what and when, sign-in events, IP address, user agent, API and assistant calls.
• Content data: whatever your applications hold. Typically contact details, commercial records, project and support history, and uploaded files. The shape of this is yours to decide.

Special categories of data

Cordango is not designed for Art. 9 data, and the standard agreement does not cover it. Some obvious uses sit close to the line, absence management for example, so if you intend to process health data, works-council data or anything else in Art. 9, tell us before you do. That needs an explicit written amendment, and it may need additional measures on both sides.

Frequency

Continuous, for as long as your workspace is in use.

3. Our obligations

• Instructions only. We process personal data only on your documented instructions. Your use of the platform, and this agreement, are those instructions. If EU or member state law requires us to process something anyway, we tell you first unless that law forbids it.
• We tell you when an instruction looks unlawful. Art. 28(3) second paragraph. We will say so rather than quietly comply.
• Confidentiality. Everyone with access is bound to confidentiality in writing, and that obligation survives the end of their engagement.
• Security. The measures in section 5, reviewed as the platform changes.
• Help with data subject requests. Section 6.
• Help with Art. 32 to 36 duties. Breach handling, data protection impact assessments and prior consultation, to the extent the information sits with us.
• Deletion or return at the end. Section 8.
• Evidence and audits. Section 9.

4. Where it runs

The platform, its database, its file storage and its backups run on infrastructure operated by Hetzner Online GmbH in Germany. That is the whole storage story for customer content. There is no second copy in another region, no analytics warehouse somewhere else, and no offshore support team with a console.

Two things sit outside that boundary today and are named plainly rather than buried: Cloudflare, which fronts the network edge and the public website, and Mintlify, which hosts the public documentation. Both were chosen because they were the fastest way to get a working site and working documentation in front of people, not because the architecture needs them. Both are scheduled to be replaced by EU-operated equivalents. Neither of them stores customer content: Cloudflare sees request metadata in transit, and Mintlify sees only visitors reading public documentation pages. We would rather you knew that from this page than found it in a DNS lookup.

5. Annex II: technical and organisational measures

The Art. 32 measures, as they actually are today. Anything on the roadmap is in section 12 instead, marked as such, because a security annex that describes intentions is worse than useless.

Access control

• Sign-in through OpenID Connect. Where you bring your own identity provider, your policies apply, including multi-factor and conditional access, and revoking an account there revokes access here.
• Roles and fine-grained permissions are enforced by the platform underneath every application, on every read and every write. An application cannot grant itself more than its user has, and a personal view cannot widen access.
• API and assistant access uses scoped access keys bound to one user and one workspace. There is no key that sees everything.
• Administrative access to production is restricted to named individuals, over authenticated channels, on the least-privilege principle.

Separation

• Every workspace is a tenant, and the tenant identifier is carried on every query rather than applied by convention in application code.
• Each workspace is reachable on its own subdomain.
• Development, staging and production are separate environments. Production data is not copied into development.

Encryption and transport

• TLS for everything in transit, with HSTS on the public surfaces.
• Encryption at rest for the database volumes, file storage and backups.
• Secrets and credentials are held outside the source tree and outside the application images.

Integrity and traceability

• A field-level audit trail produced by the runtime rather than modelled per application: who changed what, when, in every application, in one place.
• Sign-in, permission changes and administrative actions are logged.
• Logs are kept separately from the records they describe, so a deletion in an application does not erase the evidence that it happened.

Availability and recovery

• Automated daily backups of the database and file storage, held encrypted, with restores tested.
• Managed patching of the platform and its dependencies.
• Monitoring of the platform and its background job runners, with alerting on failure.

Secure development

• Changes go through version control and review before they reach production. Automated tests gate the build.
• Dependencies are tracked and updated, with security advisories triaged as they arrive.
• The compiler and command-line tooling are open source under Apache-2.0, so the part of the system that turns a description into an application is inspectable rather than a claim you have to take on trust.

What we do not claim

We hold no ISO 27001, SOC 2 or C5 certification today. We have not commissioned an external penetration test yet. There is no 24/7 on-call rotation, and no contractual uptime SLA in the standard agreement. Section 12 says what we are doing about that. If any of those is a hard requirement for you, say so early rather than late.

6. Data subject requests

Requests from data subjects belong to you, as controller. If one reaches us directly, we do not answer it on the merits. We pass it to you without undue delay and tell the person we have done so.

We help you answer it. Access, rectification, erasure, restriction, portability and objection are all things an administrator can do in the product itself, through search, export and delete, and the audit trail supplies the history. Where the product cannot reach something, for example inside a backup, we help by hand at no charge for a reasonable volume of requests.

7. Personal data breaches

If we become aware of a personal data breach affecting your data, we notify you without undue delay and in any case within 24 hours of becoming aware. That is deliberately tighter than the 72 hours you then have towards your supervisory authority, so the clock we start is not the clock you have to meet.

The notification tells you what happened, which categories and roughly how many data subjects and records are affected, what the likely consequences are, and what we have done and are doing. Where we do not know something yet, we say so and follow up rather than delaying the first notification. We do not notify your supervisory authority or your data subjects on your behalf.

8. Deletion and return

At the end of the service agreement you choose deletion or return. Export is available from the product at any time during the term, so this is not a moment you have to negotiate.

• Active data is deleted within 30 days of the end of the agreement, unless you ask for it sooner.
• Backups age out on their normal rotation, currently 30 days, after which the data is gone from those too. We do not surgically edit backups, because doing so is less trustworthy than letting them expire.
• Audit and billing records that we are legally required to keep are retained for the statutory period and nothing else is done with them.

We confirm deletion in writing on request.

9. Audits and evidence

You have the right to verify what this page describes. In practice:

• This page, kept current, is the first answer, and it is versioned so you can see what changed.
• We answer security questionnaires. We would rather do that than have you infer the answers.
• We provide the sub-processors’ own certifications and reports where we hold them.
• An on-site or remote audit is available with reasonable notice, during business hours, without disrupting operations, and under confidentiality. We do not charge for the first audit in a contract year.

10. Annex III: the sub-processor register

You give general written authorisation to the sub-processors below, under Art. 28(2). Each is bound by a written agreement with obligations no weaker than the ones we owe you.

Before we add or replace one, we tell you at least 30 days in advance by email to your workspace administrators and by updating this page. You may object on reasonable data protection grounds within those 30 days. If we cannot resolve the objection, you may terminate the affected part of the service without penalty for the remainder of the term.

Infrastructure and hosting

AI inference

What is not in this register, and why

A sub-processor is a provider that processes your data on your behalf, as part of delivering the product. That is a narrower set than the list of tools we happen to use, and the difference matters when you assess this.

Our own business tooling is not in the register. Microsoft 365 carries our email and calendar, for example. Your records never reach it, no part of the product sends anything to it, and it is not in the path of any request your users make. Correspondence we hold there is our own processing as a controller, which the Privacy & GDPR page covers. The same goes for the tools we use to write code, track work and keep books. If any of them ever came into contact with customer data, it would move into the register above and you would be notified under the 30-day rule, like any other addition.

Current means it is part of the service as designed. Transitional means it is in place because it was the fastest way to build, and it is on the list to be replaced. Optional means nothing reaches it unless a workspace administrator turns it on.

11. AI providers, and how you control them

AI is how one kind of work gets done in Cordango: turning a description into a working application, and answering questions in the product. It is not a separate system with its own rules. The same permission model applies, the same audit trail records it, and the same agreement covers it.

What actually reaches a model

Only three things. Your prompt. The application definition it concerns. And record content that the requesting user is already permitted to see. The assistant inherits the acting user’s permissions; it does not have a privileged view of your workspace, and it cannot be used to read around a permission.

What never reaches a model: your credentials, other tenants’ data, and content from parts of your workspace the requesting user cannot open.

The default: open-weight models on Melious

By default, both generation and the in-product assistant run on open-weight models through Melious. We chose that as the default deliberately. Open weights mean the model is not a single vendor’s black box, the provider running it can be changed without changing the product, and there is a realistic path to running it somewhere you choose.

We select AI providers on the basis that customer content is not used to train models and is not retained beyond what is needed to answer the request. Where a provider’s terms differ from that, this page says so rather than glossing over it.

Opting in to Anthropic or OpenAI

A workspace administrator can turn on Anthropic or OpenAI models for their workspace. Some tasks are simply better on them today, and pretending otherwise would not help you. This is off by default and it is a per-workspace decision, so nobody enables a US provider on your behalf. Both appear in the register above, with their transfer mechanisms.

Bring your own key

You can supply your own API key for a provider. Requests then run under your contract with that provider, on your terms, and their commercial and data protection relationship is with you rather than with us. We hold the key encrypted and use it for nothing else.

Bring your own endpoint

You can also point Cordango at your own model endpoint entirely, as long as it speaks the OpenAI-compatible API. Self-hosted, sovereign cloud, a provider you already have approved, or a model running in your own data centre. In that case no AI sub-processor of ours is involved at all: the data goes from our platform to your endpoint, and that endpoint is yours to govern. This is the option to take if your answer to “which AI vendors are in scope” has to be “none of yours”.

Turning it off

AI features can be disabled for a workspace. The platform does not require them. Applications that already exist keep working, because a generated application is an ordinary Cordango application with a readable definition, not something that needs a model to run.

12. What we are working towards

Stated separately from section 5 on purpose. None of this is in force yet, and none of it should be counted in an assessment today.

• ISO 27001. We are building the platform against its control set so that certification is a matter of evidence rather than rebuilding. The register above, this page’s version history and the audit trail exist partly for that reason.
• Replacing the transitional sub-processors with EU-operated equivalents, which removes the last routine US touchpoints from the picture.
• An external penetration test, with a summary report available under NDA.
• A published sub-processor change feed, so notification does not depend on somebody reading an email.
• Customer-managed encryption keys and a self-hosted deployment option for customers whose requirements cannot be met by any hosted arrangement.

If one of these is what stands between you and using Cordango, tell us. It moves up.

13. Changes to this page

Material changes, and every change to the sub-processor register, are notified to workspace administrators by email before they take effect. The version and date at the top of this page always reflect the current text.

• Version 1.0, 25 August 2026. First publication.

Questions

One email to [email protected] reaches the person who wrote this, not a queue. Ask for the signed agreement, ask for a questionnaire to be filled in, or ask why something on this page says what it says.