Data processing annex

Version 1.0 · in force from 3 November 2026 · Article 28(3) GDPR · forms part of the terms of service

Read the scope first — this annex is narrower than it looks. It covers one thing: the evaluation attributes your deployment sends us to evaluate on your behalf. For those, and only those, we act as your processor.

Everything else we do, we do as controller. Your account, your team and its roster, your subscription, our records of what you accepted, your deployment's sign-in configuration, our metering and our security logging are all processing we decided on, for our own purposes, and we are the controller of each. They are described in our privacy notice and this annex does not apply to them. Nothing in it should be read as putting them under your instructions.

1. Who this is between

Processor: Velnomix Kft., 2310 Szigetszentmiklós, Arany János utca 5/A, Hungary · company registration number 13-09-222866 · support@dether.net
Controller: The customer identified in the subscription, in respect of the attributes described in section 3.

This annex forms part of the terms of service. Where the two conflict on the processing of evaluation attributes, this annex governs; on everything else, the terms do.

Why the line is drawn here. For the evaluation attributes, your deployment decides what to send and when; the data is yours, about your systems; and we hold it only to answer one call, storing none of it and doing only what the request asks. For everything else in the service we decided that the processing exists and how it works — what an account holds, what a team roster is for and who sees it, what we meter and why — and that is what makes us the controller of it. This is our assessment of where each limb falls, and we state it so that it can be checked rather than assumed.

2. Subject matter, duration, nature and purpose

Subject matter: Evaluating the configuration attributes your deployment sends us, against the policy for the class and version it names, and returning the findings.
Nature of the processing: Receipt, validation, in-memory evaluation and return. No storage, no organisation into records, no combination with anything else, no disclosure to anyone.
Purpose: To perform the evaluation you asked for, so that your deployment can present the result inside your own threat model. We use the attributes for nothing else — not for training, not for product development, not for analytics, not for statistics.
Duration: The processing lasts one call. Each evaluation begins when the request arrives and ends when the response is returned, and nothing is stored at any point. The processes that evaluate are kept warm and reused, so a request's attributes stay in the memory of the process that evaluated it until it evaluates the same class again or the process ends — section 8 says what that does and does not mean. This annex itself lasts as long as your subscription does, and there is no processing under it once evaluations stop.

3. Categories of personal data

The attributes are your data about your own systems. A class's schema declares the attributes that describe a technology — whether an image is pinned by digest, whether a database requires transport encryption, how a queue is authenticated. Most of what is sent is a true or false answer, a number, or a value chosen from a list. None of it is designed to be about a person.

Personal data can reach us in one way, and that is the category:

Free-text values in string attributes — where a person's name, a personal email address, a user account name or a host name identifying an individual has been typed into an attribute that accepts a string.

Nothing inspects the content of a string attribute, on your side or ours, so neither of us can say whether a given request contained personal data. That is a reason to keep the channel as narrow as it is, not a reason to assume it is never used.

What is structurally excluded. The request has no field for the element's name, for the model it belongs to, for your notes or dispositions, or for anything else in your threat model. Those never leave your machine. Attributes the class's schema does not declare are dropped before evaluation. We hold no special categories of personal data under Article 9 and no criminal-offence data under Article 10, and none of the declared attributes ask for either.

4. Categories of data subjects

Only people named inside a string attribute by whoever configured the element — in practice, your own personnel or a client's, where a name has been used to describe a system. There is no other category. We receive no data about your customers as such, no end users of your systems, and no visitors to them.

5. Our instructions

We process the attributes only on your documented instructions. The instruction is the evaluation request your deployment makes: it names the class, the pinned version and the attributes, and asks for that evaluation and no other processing. The terms of service and this annex are the rest of the instruction.

We will tell you immediately if an instruction appears to us to infringe data protection law, and we will not transfer the attributes to a country outside the European Economic Area except through the content delivery described in section 8.

Where the law requires us to process otherwise than as you instruct. If Union or Member State law to which we are subject requires us to process the attributes beyond your instructions, we will inform you of that legal requirement before we process — unless that law forbids us to tell you on important grounds of public interest.

6. Your obligations and rights as controller

You decide what reaches us, and you answer for it. You warrant that you have a lawful basis for the attributes your deployment sends us and for our processing of them on your behalf, and that your instructions comply with data protection law. You are responsible for the lawfulness of those instructions and of the data they carry, including anything typed into a string attribute.

You may give and vary the instructions under which we process, within what the service does and on the terms of this annex and the terms of service. Where an instruction would require us to change the service, we will tell you so rather than act on it.

Telling your own data subjects is yours. Informing the people whose data may be carried in an attribute, and answering them when they exercise their rights, is your obligation as controller. Section 10 says what we do to assist you with it.

7. Confidentiality

The people who could reach any part of this service are bound to confidentiality. An attribute is never written to storage, and no interface exists through which one could be retrieved: no administrative view, no support tool and no stored copy.

8. Technical and organisational measures

The measures for this limb are mostly structural rather than procedural — the data is never stored, so most of what would otherwise need controlling does not exist.

Stripped to the declared schema. Attributes the class's schema does not declare are dropped before evaluation, on your side and again on ours. We do not trust the first pass to do it.
Bounded. A request body above a fixed size is refused, and values must match the type the schema declares.
Evaluated in memory. The evaluation runs in memory and returns a result. The attributes are never written to storage of any kind. Evaluation processes are kept warm and reused, so a request's attributes stay in the memory of the process that evaluated it until it evaluates the same class again or the process ends; nothing reads them in the meantime, nothing writes them anywhere, and no interface exists through which one could be retrieved. We state it in those terms rather than claiming a clearing step we have not built.
Never logged. We keep one metering line per request — at most two, where a request reaches us without naming your team — carrying the environment, the surface, the outcome, your team identifier and one count. Which count depends on the surface called: for an evaluation, how many undeclared attributes were dropped; for a query against our knowledge graph — the reference data your deployment searches, whose requests carry keys and no attributes — how many keys the query named. No line carries both. It never carries the attributes, the class, the keys themselves, your account identifier, your token or your IP address. Rejections carry a reason code and never echo the value rejected.
Encrypted in transit, and authenticated: every evaluation request is bound to an authenticated deployment belonging to an entitled team.
Evaluated in the European Union. The evaluation runs in the Frankfurt region (eu-central-1) of Amazon Web Services.

A request reaches that region through a content delivery network whose locations are in Europe and North America. The attributes are in transit there and nothing of the request is stored at it: caching is switched off on that path and no access log is kept.

Our security measures generally — including how the service is operated, how access to it is restricted and how changes to it are made — are described separately and are available to you on request. Because the measures for this limb are what the list above says, we would rather publish them here than have you rely on a general description of a service that, for these attributes, stores nothing.

9. Sub-processors

You give us a general written authorisation to engage sub-processors for this processing. Today there is one: Amazon Web Services, which provides the computing and network infrastructure the evaluation runs on.

The transfer mechanism, named. The evaluation runs in the European Union, and the only processing outside it is the transit through the content delivery network described in section 8. For all processing by Amazon Web Services, including that transit, the transfer mechanism is the standard contractual clauses incorporated in the Amazon Web Services data processing addendum, which forms part of our agreement with it. Amazon Web Services publishes its own list of the parties it engages in turn.

Where the current list is published. The sub-processors in force for this processing are the ones our privacy notice names for the evaluation — today, Amazon Web Services alone. The notice also names parties we engage for our own processing as controller, such as Proton, which hosts our support mailbox. They are our processors, not sub-processors under this annex, and they take no part in the evaluation.

We will inform you of any intended addition or replacement of a sub-processor for this processing before it takes effect, and you may object to it on reasonable data-protection grounds. If we cannot accommodate the objection, you may terminate the subscription. We impose on every sub-processor, by contract, data-protection obligations equivalent to those in this annex, and we remain fully liable to you for its performance of them.

10. Assisting you with data-subject requests

We will assist you, by appropriate technical and organisational measures and so far as it is possible, in responding to requests to exercise a data subject's rights under Chapter III of the GDPR. We will not respond to such a request ourselves, but will refer the person to you and tell you we have done so.

In practice there is nothing here for us to search. An evaluation attribute is never written to storage, so there is no record of one to produce, rectify, restrict, port or erase, and nothing to search through. A request about data a person believes is held in your threat model can only be answered from your own deployment, which we cannot reach and have no channel into. Saying so is more useful to you than an offer of assistance we have no data to render.

11. Assisting you under Articles 32 to 36

Taking into account the nature of the processing and the information available to us, we will assist you in meeting your obligations under Articles 32 to 36 — security of processing, notification of a personal data breach to the supervisory authority and to data subjects, data protection impact assessments, and prior consultation. What we can contribute is a description of this processing and of the measures in section 8, which is what those obligations need from a processor holding no stored data.

12. Personal data breach

We will notify you without undue delay after becoming aware of a personal data breach affecting the attributes we process for you — Article 33(2). The notification will describe what happened, what we know of its nature and likely consequences, and the measures we have taken or propose to take. Where we cannot give all of it at once, we will give what we have and the rest as it becomes available. Notifying your supervisory authority, and the data subjects where Article 34 requires it, remains yours as controller.

Notice reaches you at the account owner's address, or at any address you give us in writing for this purpose.

13. Audit and information

We will make available to you the information necessary to demonstrate compliance with Article 28, and will allow for and contribute to audits, including inspections, conducted by you or by an auditor you mandate. We ask for reasonable prior notice, for the audit to take place during business hours and not to disrupt the service, and for the auditor to be bound to confidentiality. We may answer an audit in the first instance with documentation, where the documentation actually answers what was asked.

An audit under this annex covers the processing described in it. It does not extend to our own processing as controller, to other customers' data, or to material that would breach a duty of confidentiality we owe to someone else.

14. Deletion or return at the end

At the end of the processing we delete or return the personal data, at your choice, and delete existing copies unless the law requires us to keep them.

Here that is satisfied by the time you ask. Nothing is stored: the attributes are never written to storage of any kind and never logged. There is no copy to return and none to delete, and no exception for backups — a backup can only hold what was stored, and nothing was. What section 8 describes — a warm process still holding the last request it evaluated — is not a stored copy: nothing can reach it or retrieve it, and it goes when that process evaluates again or ends, without anyone doing anything. There is accordingly nothing here for a deletion or a return to act on. The findings your deployment received are on your machine, under your control, and are yours to keep or delete as you decide.

For completeness: a request to us can never reach your own deployment. Your models, your graph and your logs stay on your machine, we have no access to it and no channel into it, and we could not act on them if you asked.