Data processing agreement

This agreement applies whenever you use the hosted Condux service to process personal data, and forms part of our terms of service. It takes effect when you create an account. You do not need to sign or request it, though we are happy to execute a countersigned copy for your records if your process requires one: write to privacy@condux.ai.

You are the controller. Triple Down AB, operating as Condux, is the processor. Where you are yourself processing on behalf of someone else, you are their processor and we are their subprocessor, and this agreement works the same way.

We process personal data only on your documented instructions. Your instructions are: this agreement, the terms of service, the settings you choose in the product, and anything else you tell us in writing.

We will tell you if we believe an instruction breaks data protection law, and we may pause that instruction while we discuss it. If the law requires us to process data for some other reason, we will tell you first unless the law forbids us from doing so.

We do not use your data for our own purposes. We do not sell it, and we do not use it to train any model.

Everyone we allow near personal data is bound by a duty of confidentiality, and access is limited to the people who need it to run the service or to answer a support request you raised.

Our staff can view a customer account only in a read-only support mode, which cannot change anything and which writes a record of who looked, at what and when.

We keep appropriate technical and organisational measures under Article 32. They are set out in Annex II below, and described more fully on our trust page. We may change a measure so long as the level of protection does not fall.

If we become aware of a personal data breach affecting your data, we will notify you without undue delay and in any event within 48 hours of becoming aware of it, so that you can meet your own 72 hour obligation to your supervisory authority.

The notification will describe what happened, the categories and approximate number of records involved so far as we know them, the likely consequences, what we have done and what we advise you to do. We will keep you updated as we learn more, and we will not wait until the picture is complete before telling you.

You give us general authorisation to use the subprocessors listed on our trust page, which is the current list and forms part of this agreement. Each is bound by written terms no less protective than these, and we stay responsible to you for what they do.

Before adding or replacing a subprocessor we will give you at least 30 days notice by email to account owners. If you reasonably object on data protection grounds within that period, we will work with you to find a solution, and if we cannot, you may terminate the affected service and receive a refund of any prepaid unused fees.

Our subprocessors engage their own subcontractors, one level further down, and those we do not control. Our agreements with them give us between 14 and 30 days to object to such a change, so we cannot promise you 30 days notice of one. What we will do is tell you as soon as we learn of a change we judge material to your data, and exercise our own objection right where we think it warranted.

The AI model provider is the one you can control. A scrubbed extract of your source code reaches a model provider only when a fix is requested. You can prevent this in three ways, all supported in the product: never request a fix, supply your own model key so the provider is yours rather than ours, or run the fix agent on your own infrastructure so nothing leaves your network at all.

• Data subject requests. If a data subject contacts us about data we hold for you, we will not respond substantively but will pass it to you promptly. The product lets you find, export and delete data yourself; where it cannot, we will help.
• Impact assessments. We will give you the information you reasonably need for a data protection impact assessment or a prior consultation with a supervisory authority.
• Security engagement. We will cooperate with you on questions about the measures in Annex II.

Error data expires automatically on the retention schedule for your plan, currently 30 days on the Free plan and 90 days on paid plans. Deleting a project or an organisation deletes the data belonging to it.

When our agreement ends, you may export your data for 30 days. After that we delete it, and we delete existing copies unless the law requires us to keep them. Backups age out on their own cycle and are not selectively edited, which is normal practice and worth stating plainly rather than promising an instant erasure we could not actually perform.

We will make available the information needed to show we comply with Article 28, and will contribute to audits conducted by you or an auditor you appoint.

In practice, start with three things that cost you nothing: this agreement, the trust page, and the source code itself, which is published and describes exactly what the system does. If those leave a question open, ask us and we will answer it. For an on-site audit we ask for reasonable notice, no more than once a year unless an incident or a regulator prompts it, and that you bear the cost.

The service runs on infrastructure in Nuremberg, Germany. Where personal data is transferred outside the EEA to a subprocessor, that transfer is covered by the European Commission's standard contractual clauses, which are incorporated into this agreement by reference, with Annex I and Annex II below serving as their annexes.

The transfers that occur today are to Stripe for payment processing and, where you request a fix, to the AI model provider. Both are United States companies.

Liability under this agreement is subject to the limitations in the terms of service. If this agreement and the terms of service conflict on the handling of personal data, this agreement wins.

Subject matter

Provision of the hosted Condux error monitoring service, including the optional AI fix engine.

Duration

For as long as the customer's account is open, plus the retention periods above.

Nature and purpose

Receiving, scrubbing, storing, grouping, displaying and alerting on application error events, and where requested, analysing source code to propose a fix.

Categories of data subject

The customer's own staff who hold accounts, and end users of the customer's applications whose activity produced an error.

Categories of personal data

For accounts: email address, and authentication and billing metadata. For error events: whatever the customer's application includes, typically a pseudonymous user identifier, technical context and free text that may incidentally contain personal data. Email addresses, credential-shaped values and end user IP addresses are removed on arrival.

Special category data

Not requested and not expected. The customer must not knowingly send it, and should strip it in the SDK if their application could produce it.

Frequency

Continuous, for as long as the customer's applications are sending events.

• Encryption in transit over TLS for every connection, from the SDK to ingest and from the browser to the application.
• Personal data minimisation at the point of collection: end user IP addresses discarded, email addresses and credential-shaped values redacted, and end user identifiers replaced with a one-way hash before storage.
• A second scrub before any data is sent to a model, so credentials that survived the first pass do not reach a third party.
• Passwords hashed with Argon2id. Session tokens and machine credentials stored only as hashes.
• Customer-supplied secrets, such as a model key, encrypted at rest with authenticated encryption.
• Tenant isolation enforced on every request, with membership checked server-side rather than in the client.
• Role-based access control, with administrative actions written to an audit trail that records the acting person even during a support session.
• Support access to a customer account is read-only, scoped to one organisation, and audited.
• Retention enforced automatically by the database against each stored record rather than by a scheduled job.
• Credential isolation in the fix engine: the model never receives a source control token, and the only action available to it is opening a draft pull request.
• Automated dependency vulnerability scanning, with a documented remediation path.
• Encrypted, monitored backups with a documented and exercised restore procedure.
• A documented incident response procedure, including the notification duties in clause 5.
• Least privilege administrative access, protected by multi-factor authentication, reviewed periodically.
• Source-available code, so a customer or their auditor can verify the measures above rather than relying on this list.