Data processing agreement

• 1. Parties and status
• 2. Scope, and what you get
• 3. Documented instructions
• 4. Confidentiality
• 5. Security
• 6. Sub-processors
• 7. Transfers and data location
• 8. Data subject rights
• 9. Breach and assistance
• 10. Deletion and return
• 11. Audit
• 12. Liability
• 13. Governing law
• 14. Term and changes
• 15. Continuity
• 16. Contacts
• Schedule 1: standard contractual clauses
• Annex 1: details of the processing
• Annex 2: security measures
• Annex 3: sub-processors

1. Parties and status

1.1 This agreement is made between you, the customer (the Customer), and the company below (VarnaOps).

1.2 The roles are split, and the split is the point of this agreement. For the contents of the file you upload for analysis, and for the results derived from it, you are the controller and we are your processor. For your account data, access-request decisions, run records, billing and operational logs, we are a controller in our own right, and that processing is described in the privacy notice rather than here.

1.3 Each party is responsible for its own compliance with applicable data protection law. Nothing here makes us a joint controller with you for the uploaded file.

2. What this agreement covers, and what you get under it

2.1 This agreement applies to our processing of personal data contained in the files you upload, and in the results derived from them. It forms part of the terms of use and is accepted with them. Where they conflict on the processing of that data, this agreement prevails.

2.2 Annex 1 sets out the subject matter, duration, nature, purpose, categories of personal data and categories of data subject. Annex 2 sets out the technical and organisational measures. Annex 3 sets out the sub-processors. Schedule 1 governs the standard contractual clauses.

2.3 Your rights under this agreement, collected in one place. Article 28(3) opens by requiring the contract to state the controller's rights, and you should not have to assemble them from eight clauses. At any time you may:

• give and withdraw instructions (clause 3);
• receive notice of a change of sub-processor (clause 6.3);
• submit any run with the no-model option (clause 6.5);
• require assistance with a data subject's request (clause 8);
• receive breach notification (clause 9.2);
• delete any upload, any run or your whole account yourself (clause 10.1);
• choose deletion or return on termination (clause 10.3);
• obtain the deletion attestation (clause 10.5);
• request the information in clause 11.1;
• ask for a remote audit once in any twelve month period (clause 11.2);
• request the standard contractual clauses (Schedule 1);
• and terminate on unreachability (clause 15.3).

Your own obligations are in the terms of use and in Annex 1 under "Customer warranties".

3. Documented instructions

3.1 We process the uploaded file only on your documented instructions, including as to transfers to a third country.

3.2 Your documented instructions are: this agreement, the terms of use, and the run configuration you submit for each run. The run configuration is the reference atlas selected, the analyses selected, the roles you assign to the columns of your own file, and any free-text question you type for the interpretation section. It is recorded with the run and is available to you.

3.3 Processing required by law. A law may require us to process the uploaded file otherwise than on your instructions. That may be a law of the Union, of a Member State, or of a third country to which we are subject. Where it happens, we inform you of that legal requirement before processing. The one exception is a law that prohibits the notification on important grounds of public interest. Clause 7.4 governs requests from public authorities.

3.4 We immediately inform you if, in our opinion, an instruction infringes applicable data protection law. We may suspend the processing concerned until the instruction is withdrawn or confirmed, and will state the ground for the suspension in writing at the time. Suspension is limited to the processing concerned and lasts no longer than is reasonably necessary.

3.5 Purpose limitation. We do not use the uploaded file, or anything derived from it, to train or improve our own models. Nor do we use it for any purpose other than providing the service to you under this agreement. Reference atlases are built from public data only. We do record operational metrics about each run, such as the number of cells, the analyses selected, and the time and resources the run consumed. We use those metrics for capacity planning and pricing. They contain no expression value and no metadata value from your file.

3.6 Diagnosing a failed run. If a run of yours fails, we may open your uploaded file inside our cloud account to find out why, and only for that. The access is recorded in the audit trail described in Annex 2, and we tell you that it happened. The file is not copied outside the United States or onto any machine outside that account for the purpose.

4. Confidentiality

4.1 We ensure that every person authorised to process the uploaded file is subject to an obligation of confidentiality.

4.2 As at the date of this agreement VarnaOps is a single-member company and the only person with access is its sole member. That person's obligation of confidentiality for the uploaded file is owed under this agreement. It is personal to him as well as binding on VarnaOps, and it survives the termination of this agreement and of his role. We will impose an equivalent written confidentiality obligation on any employee, contractor or other person to whom we later grant access, including any person named under clause 15.

5. Security

5.1 We implement the technical and organisational measures set out in Annex 2. Those measures are the measures actually in place on the date stated in that Annex, not a statement of intent.

5.2 We may change a measure provided the change does not reduce the overall level of security. We notify you before making any change that materially reduces the overall level of security described in Annex 2. Annex 2 is dated, is updated when the measures change, and the current version is available to you on request at any time.

6. Sub-processors

6.1 You give us general authorisation to engage the sub-processors listed in Annex 3, on the terms stated there. The hosting sub-processor processes the uploaded file on every run. The model provider is engaged only where you select a feature that calls it. A run submitted with the no-model option makes no call to any model provider at all. Clause 6.5 governs that option.

6.2 We impose on each sub-processor data protection obligations that are, in substance, those of this agreement, and we remain fully liable to you for our sub-processors' performance. On written request, and subject to the sub-processor's own confidentiality terms, we make available the data protection terms agreed with each sub-processor.

6.3 Change notice. The sub-processors are listed in Annex 3. When we add or replace one, we update that list and notify you by email at the address on your account. If you do not accept the change, your remedy is to stop using the service and delete your data, which you can do yourself at any time under clause 10.1.

6.4 The current list is published in the sub-processor section of the privacy notice. It is derived from a machine-readable record. That record holds, for each recipient, the claim made about it, who verified it and when.

6.5 Running with no model provider. You may submit any run with the no-model option. A run submitted with that option makes no call to any language-model provider. The refusal is enforced at the single point in the code that every model call passes through. Any analysis that cannot run without a model is refused before the run starts, rather than silently omitted from the report. The run's manifest and the report both record whether any model call was made. One limit: the pre-run column-role proposal is a separately priced button pressed before any run exists, so the option does not reach it. Not pressing it sends nothing.

6.6 Retention at the model provider. Since 9 September 2026 the model provider is the hosting sub-processor itself, and its published default is zero retention: it does not store what is sent to a model or what comes back. That default is its own published position, not a negotiated commitment to you. It also applies per model. The provider does require retention for as long as 30 days for automated abuse detection on a published list of named models. Where it does, it holds the content itself and does not disclose it to the model's developer. The model we call is not on that list. Clause 6.5 states the way to avoid the transfer entirely.

6.6.1 No training, and the one thing that does leave. The provider's service terms permit it to use content to improve its services only for a named list of services that does not include the model service, and state that the permission "does not apply to ... any AI Service that is not listed". The developer of the model receives no content at all and so cannot train on it. The provider may share with that developer information about your use of the model; its terms state that this information "does not include Your Content".

6.7 The position this replaces. Until 9 September 2026 the model provider was a separate company, Anthropic, PBC, reached over its own API. It retained inputs and outputs for 30 days, flagged content for up to 2 years, and safety classification scores for up to 7 years. It offered no ad hoc deletion, so an erasure request could not be propagated to it. This is recorded because the change is a change of sub-processor under clause 6.3, and because anything sent on that path before that date was subject to those periods.

7. International transfers and data location

7.1 The uploaded file, the results and the operational logs are stored and processed in Amazon Web Services, region us-east-1 (Northern Virginia, United States), in our own AWS account. There is no region choice and no EU-hosted option today. We do not store or process the uploaded file or the results outside the United States. We may move the processing to another AWS region within the United States, and will notify you as soon as practicable when we do.

7.2 Every sub-processor in Annex 3 is reached in the United States. The transfer mechanism for each is stated in Annex 3. Each one rests on a written transfer impact assessment on file: Amazon Web Services on 4 August 2026, Stripe, LLC on 29 August 2026. The Anthropic assessment of 4 August 2026 is retained as a record of the path used until 9 September 2026 and no longer covers a live transfer; the model call now runs inside the Amazon Web Services transfer already assessed. Each assessment follows the six-step EDPB method and concludes proceed at low residual risk. Copies are available to you on request.

7.3 Your own transfer to us. We are established in the Union. Our position is that an EU customer transferring the file to us is not making a Chapter V transfer at the moment of receipt. The transfer occurs when we place the data in us-east-1, where the onward safeguards in clause 7.2 apply. That position is our own reading and is not offered as advice, and you are not asked to adopt it. On request, and without requiring you to agree with it, we will execute the module two controller-to-processor standard contractual clauses under Schedule 1. Annexes 1, 2 and 3 of this agreement then serve as SCC Annexes I, II and III.

7.4 Requests from public authorities. If we receive a legally binding request from a public authority for the uploaded file or the results, we will:

• notify you without undue delay, unless we are prohibited from doing so;
• seek a waiver of any such prohibition;
• challenge the request where there are reasonable grounds to consider it unlawful;
• disclose no more than the minimum the request requires;
• and keep a record of every such request.

If we are prohibited from notifying you we will use reasonable efforts to inform you of the number and type of requests received over a period.

8. Assistance with data subject rights

8.1 Taking into account the nature of the processing, we assist you by appropriate technical and organisational measures. That assistance is with your own duty to respond to requests from data subjects under Chapter III of the GDPR, including access, rectification, erasure, restriction, portability and objection. Assistance is provided without undue delay and is free of charge for routine requests. Where your requests are repeated or unusually burdensome, we may charge our reasonable costs, notified to you in advance.

8.2 We do not hold the key that links the uploaded file to an identifiable person; you do. In practice our assistance is: identifying which runs and which stored objects relate to a file you name, and correcting, exporting or deleting them. The self-service controls in clause 10 are the primary route and are available to you at any time without contacting us. This is not a statement that the uploaded file is anonymous. Annex 1 records our shared understanding that it is pseudonymised personal data. The report prints the values of your own sample or donor column, and the run record retains the file name you uploaded.

8.3 If a data subject contacts us directly about data in an uploaded file, we will not respond substantively and will refer the request to you without undue delay.

9. Assistance with security, breach, impact assessment and consultation

9.1 We assist you in ensuring compliance with the obligations in Articles 32 to 36 GDPR, taking into account the nature of the processing and the information available to us. The flow description that supports your own impact assessment is published at data handling. It holds the flow map, the retention table, what each sub-processor receives, what the language model receives on each of the three paths, what the report contains and what is logged.

9.2 Breach notification. We notify you without undue delay after becoming aware of a personal data breach affecting the uploaded file, and in any event within 72 hours of becoming aware. The notification will describe the nature of the breach, the categories and approximate number of data subjects and records concerned so far as known, the likely consequences and the measures taken or proposed. Where not all of that is known within the period, we send an interim notification of what is known within the period and complete it in phases without further undue delay.

9.2A Handling of a breach. We notify the contact named under clause 16, preserve the evidence and records relating to the breach, and cooperate with your own investigation. We do not notify a supervisory authority or any data subject about a breach affecting the uploaded file on your behalf, and do not do so in your name, unless you instruct us to.

9.3 We maintain an incident log and record, for each incident, whether it constituted a personal data breach.

10. Deletion and return

10.1 Self-service deletion, available at any time during the term. You can delete a single uploaded file, a single run and all its results, or your entire account. Deletion removes every version of every object concerned, and every delete marker, so no record survives that a named object once existed. Any per-object failure is reported as a failure rather than as partial success.

10.2 Automatic expiry. Uploaded files are deleted 7 days after upload. Results, including copies of your expression data derived from the upload, are deleted 30 days after the run. Request and job logs are deleted after 30 days. Security audit records are retained for 400 days in a separate audit store. Those records show which principal read or wrote which stored object, and when. We keep them as a security measure, and so that an incident found at the end of a year can still be investigated. They hold no expression value and no content from your file, only the identity of the object and of whoever touched it. The run record has no automatic expiry today. It holds the run id, its status and timings, your email address, the reference selected, and the file name you uploaded, and it is removed when you delete the run or the account. We are a controller for that record under clause 1.2, and it is worth knowing that a file name of your own choosing can itself carry a study accession or a specimen label.

10.3 On termination, at your choice, we delete or return the uploaded files and results and delete existing copies, unless retention is required by law.

• (a) Return. For 30 days after termination we retain the results then held so that you can retrieve them. Return is by download, in the formats the service produces: the annotated dataset as .h5ad, the predictions as CSV, the report as a single self-contained HTML file, and the per-analysis outputs in the result bundle. We assist with retrieval on request and at no charge. The 30 day automatic expiry in clause 10.2 continues to apply during that window and is not suspended. It is a lifecycle rule on the storage itself. It runs for every customer at once, and it cannot be turned off for one. If you need results older than 30 days, download them before the run ages out rather than at termination.
• (b) Your uploaded file itself will normally already be gone, because clause 10.2 deletes uploads 7 days after upload. If you need your own upload back, keep your own copy. This is stated here rather than left to be discovered at termination.
• (c) Deletion. At the end of the window, or immediately if you choose deletion, we delete the uploaded files and the results. Only the residues in clause 10.4 survive, and we issue the attestation described in clause 10.5.

10.4 What deletion does not reach, and for how long. These residues are unavoidable. We disclose them rather than promise against them:

• the credit balance and credit ledger, retained indefinitely for accounting;
• database point-in-time recovery, 35 days;
• log lines already written, up to 30 days;
• the run record, which has no automatic expiry and is removed by your own deletion of the run or the account;
• anything sent to the model on the paths in clause 6.1 before 9 September 2026. Until that date the model provider was a separate company. It retained inputs and outputs for 30 days, content its own systems flagged for up to 2 years, and safety classification scores for up to 7 years. It offered no ad hoc deletion, so an erasure request could not be propagated to it and could only age out. After that date this residue does not arise: the model runs inside the hosting sub-processor at its zero-retention default (clause 6.6), so there is no separate copy to reach;
• the payment processor's own record of a purchase, on its own schedule.

On the credit ledger, because "retained indefinitely" invites the obvious question. The credit ledger row survives an erasure request, and it survives it lawfully rather than by oversight. It records what was bought, what was spent and on what commercial terms, including the discount multiplier applied to a purchase. Art. 17(3)(b) disapplies the right to erasure where processing is necessary for compliance with a legal obligation. Accounting and tax law is such an obligation. The row is a commercial record of a transaction, not a record of your research data: it contains no expression value, no metadata value and no file name. We are the controller of it under clause 1.2, so it sits outside this agreement and is described in the privacy notice.

10.5 Deletion attestation. Closing an account produces a durable written destruction record, suitable if you must confirm destruction to a data access committee. Before the record is issued we re-list every storage prefix concerned and refuse to issue anything if any object survives. The record states how many stored objects and which storage prefix patterns were deleted, when, that the prefixes were verified empty afterwards, and what deletion does not reach (clause 10.4). It deliberately does not record run ids, object keys or file names, so that the attestation cannot itself become a permanent index of what a named person uploaded. It is held in a separate audit store outside the storage the deletion empties, and a copy is returned in the response to the deletion request.

11. Audit and information

11.1 We make available to you the information necessary to demonstrate compliance with Article 28 GDPR. On written request, and no more than once in any twelve month period unless a breach has occurred, we will provide:

• this agreement's annexes, current as at the date of the request;
• the transfer impact assessments named in clause 7.2;
• a written response to a reasonable security questionnaire;
• an extract from the audit trail described in Annex 2 covering access to your own objects over a stated period, where technically available, and at our reasonable cost for periods longer than 30 days;
• the data protection terms agreed with each sub-processor, under clause 6.2.

11.2 Audit. Where the information in clause 11.1 is insufficient to demonstrate compliance, we will cooperate with an audit conducted remotely. You may conduct it yourself, or mandate an independent auditor who is bound by confidentiality and is not a competitor of ours. The audit runs at most once in any twelve month period, on 30 days' prior notice, and at your cost. We contribute by making available the material in clause 11.1, by answering the auditor's questions and by providing evidence from our own systems.

11.3 How that works for a company with no premises. VarnaOps is a single-member company with no premises of its own and no infrastructure of its own. The infrastructure is operated by the hosting sub-processor named in Annex 3. You may obtain that sub-processor's own audit reports and certifications from it directly. There is therefore no site to visit, and an audit under clause 11.2 is conducted against the configuration, the records and the audit trail rather than against a location.

12. Liability

12.1 The disclaimer in the terms does not reach this agreement. The "as is" disclaimer and any other exclusion or limitation in the terms of use do not apply to our obligations under this agreement or to our liability for breach of them.

12.2 The cap, and there is only one. Except as clause 12.3 provides, there is one cap on each party's total liability arising out of or in connection with this agreement. It is the greater of the fees paid by you in the twelve months preceding the event and USD 1,000. The cap covers liability for breach of the data protection obligations in this agreement, and for breach of confidentiality under clause 4.

12.3 What cannot be limited. Nothing in this agreement limits either party's liability for death or personal injury caused by negligence, for fraud, or for anything else that cannot lawfully be limited.

12.4 Article 82 is preserved. Nothing in this agreement affects a data subject's rights under Art. 82 GDPR, or either party's liability to a data subject, or either party's right of recourse against the other under Art. 82(5).

13. Governing law and jurisdiction

13.1 This agreement, and any non-contractual obligation arising out of it, is governed by the law of the State of Wyoming, United States. The parties submit to the exclusive jurisdiction of the courts of the State of Wyoming. This clause governs this agreement only.

13.2 Nothing in clause 13.1 deprives a data subject of any right. Nothing in it deprives you of any mandatory consumer or data protection protection available under the law of your own habitual residence or establishment. And nothing in it displaces the supervisory authority competent under the GDPR.

14. Term, precedence and changes

14.1 This agreement takes effect when you accept the terms of use. It also takes effect if you use the service, where use constitutes acceptance under those terms. It continues for as long as we process personal data on your behalf.

14.2 Annexes 2 and 3 may be updated as described in clauses 5.2 and 6.3. Any other change requires the agreement of both parties, and no amendment to the terms of use varies this agreement.

14.3 Form of acceptance. This agreement is accepted as part of the terms of use, without signature. We will, on request, execute a counter-signed copy of it, identical in substance, if your own procedures require one.

15. Continuity

15.1 The position today, stated rather than implied. VarnaOps is a single-member company. One person holds the administrative credential to the account in which the uploaded file, the results and the logs are held. There is no second person, no break-glass procedure and no continuity arrangement of the kind clause 15.4 describes, and Annex 2 lists all three among the measures not in place.

15.2 We will notify you without undue delay of any event that makes us, or is likely to make us, unable to operate the service for more than 30 days.

15.3 If we are unreachable for more than 30 days, you may terminate this agreement immediately by notice, and the deletion obligations in clause 10 apply. We will tell you which of those obligations we have been unable to perform, and why.

15.4 Continuity arrangement: none today. There is no arrangement naming another person able to reach the account for the limited purposes of deletion under clause 10, notification under clause 9 and return under clause 10.3. We will put such an arrangement in place as the business grows, bound by an obligation of confidentiality equivalent to clause 4.2, and will update this agreement when it exists. Until then, clause 15.1 states the position, Annex 2 lists its absence, and clause 15.3 gives you a termination right if we become unreachable.

16. Contacts

16.1 Notices under clauses 6.3, 9.2, 9.2A, 15.2 and 15.3 are given to the contacts each party names, and each party keeps its contact current. Our contact for data protection and for breach notification is support@varnaops.com, which is the address the privacy notice publishes and is read by a person.

Schedule 1: standard contractual clauses

On your request under clause 7.3, the parties execute the standard contractual clauses for the transfer of personal data to third countries. Those are the clauses set out in Commission Implementing Decision (EU) 2021/914, module two (controller to processor). Where UK data protection law applies, the parties also execute the UK International Data Transfer Addendum issued by the Information Commissioner in February 2022. Annex 1 of this agreement serves as Annex I (parties, description of transfer, competent authority), Annex 2 as Annex II (technical and organisational measures) and Annex 3 as Annex III (sub-processors). The docking clause applies.

Annex 1: details of the processing

Ordered so that this Annex can be re-used as Annex I of the module two standard contractual clauses under Schedule 1.

Pseudonymised data is personal data. The parties record their shared understanding that a de-identified single-cell submission is pseudonymised rather than anonymous, because you hold the re-identification key and because genotype is reconstructible from single-cell RNA data. The de-identification requirement in the terms reduces risk; it does not take the data outside data protection law.

What is sent to the model provider, and when. Three cases, each one your own choice: (a) an optional, separately priced column-role proposal sends each column's name, data type, cardinality, populated fraction and three real example values from that column; (b) label matching sends your distinct cell-type label strings only; (c) the interpretation section sends computed results, gene symbols, cell-type names, the condition column name and its values, the donor column name, and your own typed question. No expression value and no per-cell row is ever sent. Outside case (a) no donor or sample identifier is sent. None of the three happens on a run submitted with the no-model option (clause 6.5); the one step that option does not reach is case (a), which is a separately priced button pressed before any run exists.

Annex 2: technical and organisational measures

Measures in place as at 1 September 2026. Each line is a measured state, not an intention.

Annex 3: sub-processors

Current as at 9 September 2026.

Sub-processors of the personal data in the uploaded file, which is what this agreement covers:

Not a sub-processor under this agreement:

The model provider's position, as published by Amazon Web Services: model providers have no access to Amazon Bedrock's logs or to customer prompts and completions, the service's default is zero data retention, and content retained for abuse detection on the models where that is required stays inside Amazon Web Services and is not shared with the model's developer. Clause 6.6 states the same, clause 6.5 states the way to avoid the transfer entirely, and clause 10.4 records the residue that arose on the path used until 9 September 2026.