Privacy notice
What we collect, why, who else sees it, how long we keep it, and what you can ask us to do about it.
Last updated 1 October 2026. Applies wherever you use VarnaOps. It is written to the disclosure requirements of the EU and UK GDPR, which govern us because we are established in the European Union, and it gives everyone the same rights.
- We hold your sign-up details and email, the file you upload, your results, your run and billing records, and service logs.
- We use them to run your analysis, run your account, take payment, and keep the service working.
- Uploads go after 7 days, results after 30 days, logs after 30 days, and our record of who touched a file after 400 days. Billing records, and the destruction record we produce when you close your account, are kept indefinitely.
- Your browser holds your sign-in and what you typed into the wizard, on your own device; signing out clears it.
- Stored files are reachable only by the service itself and by one administrator, and every access is recorded.
- Amazon Web Services supplies the language model that three steps call, through Amazon Bedrock and inside our own AWS account: it gets metadata and text, never your expression matrix, and keeps none of it.
- You delete a run, or your whole account, yourself from the site, and you can ask to see, correct or export your data by writing to us.
- We set no advertising cookies and run no third-party analytics. Our web host records each page request: the page, the country, the page that linked to it, the browser's own description of itself and the network it came from, with no network address, no cookie and nothing stored on your device. We also keep an anonymous record of run configurations, never data, results or who: which analyses are chosen and how often automatic column detection is used, with nothing in it that points at you, your file or your run.
This summary is for orientation; the full text below is what applies.
Contents
- Who we are
- Where we are established
- How your data is handled today
- What we collect
- Why, and on what legal basis
- Who at VarnaOps can reach it
- Who else sees it
- Where your data goes: the language-model steps
- Where it is processed
- How long we keep it
- Your rights
- Deleting a run or your account
- Complaints
- Automated decisions
- Other deployment models
Who we are, and how to reach us
For your account, billing and run records, the controller of your personal data, meaning the company that decides why and how it is processed, is the company below. For the contents of the file you upload, the roles are reversed: you (or your institution) decide why it is processed and we process it on your instructions, as your processor:
| Legal name | VarnaOps LLC |
| Registered address | 30 North Gould Street Ste N, Sheridan, WY 82801, United States |
| Registration number | 2026-001911287 (Wyoming Secretary of State Filing ID) |
| Contact | support@varnaops.com |
For anything in this notice, including any request about your data, write to support@varnaops.com. That address is read by a person and is the fastest route to us.
Data protection officer
We have not appointed a data protection officer and are not required to. For the contents of the file you upload, you or your institution decide why it is processed and we process it on your instructions, as your processor; for your account, billing and run records we are the controller.
That split is written out in our Data Processing Agreement, which is part of the terms of use and accepted when you sign in.
Where we are established
VarnaOps LLC is registered in Wyoming and operated from the European Union, where the service is run. The GDPR therefore applies to us directly, and we have no separate representative: you deal with us, and you can complain to a supervisory authority as set out below.
How your data is handled today
Your data is processed to produce your result. Three steps call a language model that runs inside our own Amazon Web Services account; what those steps send it, and what never reaches it, is set out under where your data goes below.
| Aspect | How it works today |
|---|---|
| Your data | Each run executes in its own isolated environment, which is destroyed when the run ends. Your results are isolated from every other run: each run writes them with a credential scoped only to that run's own results prefix. Your upload and results are reachable only by the service itself and by one administrator, as set out under who can reach your data. |
| Model training | Your data is never used to train or improve our models. Models are trained only on public reference atlases. |
| Reference atlases | Built solely from public, properly-licensed data (the CZI CELLxGENE Census, CC BY 4.0), never from customer data. |
| In transit & at rest | Uploads and results move over encrypted connections and are stored encrypted in cloud object storage. |
| Your results | Returned to you as a self-contained report; the run records its own provenance. |
| What we need | The pipeline operates on expression matrices and sample metadata, not personal identifiers. |
| Sub-processors | Amazon Web Services hosts the platform and provides the language model three steps call, through Amazon Bedrock. Stripe takes credit purchases and never receives your file. See who else sees your data. |
What we collect
Almost everything here is data you hand us on purpose. We set no advertising cookies and run no third-party analytics. Your browser keeps things for us on your own device, which is not a cookie; see how long we keep it.
| Category | What it is | Where it comes from |
|---|---|---|
| Account | Your email address, and the name and organization you choose to tell us after you have signed in. Only the email address is required. | You, when you sign up and when you sign in. |
| Your query file | The expression matrix and per-cell metadata columns in the file you upload. Processed on your instructions: for this data you are the controller and we are your processor. | You, at upload. |
| Run records | The run id, its status and timing, the file name you uploaded, the reference you chose, your email so we can tell you when it finishes, and whether you have asked us not to send that email. | Generated as the run executes. |
| Results | The annotated output and the HTML report built from it. | Produced by the run. |
| Billing | Your balance and a ledger of purchases and usage. Card details go to the payment processor and never to us. | You, and the payment processor. |
| Terms acceptance | Which version of the terms and the data processing agreement you accepted, when you accepted it, and the network address and browser you accepted from. Kept until you delete your account. | You, when you tick the box at sign-in. |
| Service logs | Operational records of requests and job execution, used to run and debug the platform. | Generated automatically. |
| Website visits | For each page request: the time, the page, the response status, the country and nearest edge location, the page that linked to it (the referrer, when the browser sends one), the browser's own description of itself (the user agent), and the network the request came from (its autonomous system number). No network address, no cookie, nothing stored on your device. | Recorded by our web host as you browse. |
| Analysis choices | For each analysis submitted, an anonymous record of the reference, the analyses chosen, the size band of the data, whether your own labels were used, and which roles you assigned to metadata columns. For each use of automatic column detection, an anonymous record of how it ended and how many roles it was asked about. Configuration only: none of your data, none of your results. No account, no file name, no column names, no run. | Recorded when a run is submitted, and when a column detection finishes. |
Your email and your file are needed to perform the contract; without them we cannot run an analysis. Nothing else on this page is required of you.
Job logs. A run's log records the names of your batch and donor columns and the level names of your condition column. It does not record the values in your batch, donor or sample columns, and never any expression value.
Site visits. Our web host records, for each page request on this site and on the reference site, the time, the page, the response status, the country and edge location of the request, the page that linked to it when the browser sends one, the browser's own description of itself, and the network the request came from. It records no network address and sets no cookie. These records cannot on their own identify a visitor or recognise one who returns, are kept for 30 days, and are used to count visits, to tell crawlers from people, and to see which pages and sites bring readers here.
Why we process it, and on what legal basis
Under the GDPR every purpose needs its own lawful basis. We do not rely on consent for anything on this page. Ours, purpose by purpose:
| Purpose | Legal basis | Why that basis |
|---|---|---|
| Running your analysis and returning your results | Performance of a contract, Art. 6(1)(b) | It is the service you asked for. Without the file there is nothing to process. |
| Column detection, label matching and interpretation | Performance of the contract, Art. 6(1)(b), each switched on by your own choice | Each is part of the analysis you asked for, and none of the three runs unless you switch it on. What each one sends is set out under where your data goes. |
| Creating and running your account, and telling you when a run finishes | Performance of a contract, Art. 6(1)(b) | Same contract. We send one email per run, when it finishes, whether it succeeded or failed. It is the only email we send you about a run, and you can turn it off on your account page; your runs and results stay reachable there either way. |
| Taking payment and keeping the credit ledger | Performance of a contract, Art. 6(1)(b) | You paid us and we have to record what you paid and what you spent. |
| Keeping financial records after you leave | Legal obligation, Art. 6(1)(c) | Accounting and tax law requires a business to keep its records for a period that outlasts any individual account. |
| Telling the operator that an account was created | Legitimate interests, Art. 6(1)(f) | One internal email per account, holding the account address, the time it was created and the sign-in directory and application it was created in, so we know the front door works and can spot an account we did not create. No profiling, and it is not combined with anything else. See when we rely on legitimate interests. |
| Keeping the platform up, secure and debuggable | Legitimate interests, Art. 6(1)(f) | See when we rely on legitimate interests. |
| Capacity planning and pricing | Legitimate interests, Art. 6(1)(f) | We keep operational metrics about each run: the size band your file falls in, the analyses selected, and the time and resources the run consumed. They carry no expression value and no metadata value from your file. Clause 3.5 of the data processing agreement states the same limit. See when we rely on legitimate interests. |
The analysis-choice records are anonymous: nothing in them points at a person, so they are not personal data and are not in the table above. Website visit logs carry no network address, cookie or account link and cannot on their own identify a visitor; we keep them under the same 30-day clock and the same legitimate interest as the request logs, running and securing the site and knowing where its readers come from, and use them for nothing else.
When we rely on legitimate interests, and what they are
Three things we do rest on this basis rather than on your contract with us. For each one: what we want out of it, what we actually process, and why we think it is fair to you.
- Keeping the service running and secure. We want a platform that stays up, resists abuse, and can be debugged when a run fails, and we want to know where the people reading the site come from. For that we keep request and job logs, error traces, the records that let us follow a single run, and the website visit logs described under what we collect. We think that is fair to you because none of them is ever used to build a picture of you, none is combined with anything else, the visit logs are read only as counts and the rest only when something breaks, and all of them expire on a schedule. You can object at any time, at the address above.
- Knowing that an account was created. We want to know the sign-up path works, and to spot an account we did not create. One internal email per account carries the account address, the time it was created, and the sign-in directory and application it belongs to. It is sent once, it is combined with nothing else, and it builds no picture of you. You can object at any time, at the address above.
- Planning capacity and setting prices. We want to know what runs cost us, so that we can buy the right amount of hardware and price the service. What we process is the size band of your file, the analyses you chose, and how long the run took and on what. It carries nothing out of your file, no expression value and no metadata value, so it says nothing about any person. You can object at any time, at the address above.
Who at VarnaOps can reach your data
Access to stored uploads and results is limited to the service itself and to one administrator. Every access is recorded: an audit trail on our cloud account logs administrative actions and the reads and writes of the individual stored objects, so there is a durable record of which file was opened, when, and under which credential. If you have a question about access to your own data, write to us and we will answer from that record. If your run fails we may open your file inside that account to see why; that access is logged and we tell you by email. We never copy your file to any machine outside the account.
Who else sees your data
Everything that touches your files runs inside our own Amazon Web Services account; Stripe, who take payment, never see a file. That holds for every system in the chain: the storage that keeps your upload and your results (Amazon S3), the compute that runs the job (AWS Batch), the language model (Amazon Bedrock), the email we send you (Amazon SES), your sign-in (Amazon Cognito), the run, account and billing records (Amazon DynamoDB), the application logs (Amazon CloudWatch Logs), the trail of who read which stored object (AWS CloudTrail) and the website itself (Amazon CloudFront). Every one of them is an Amazon Web Services service, in one account we control.
We do not sell data and we do not share it for anyone else's marketing. Two companies process some of it on our behalf or alongside us, and each is there for a specific job.
| Recipient | What they get | Why |
|---|---|---|
| Amazon Web Services | Everything the platform stores or runs: your uploaded file, your results, run records, account records, logs. | They host the platform. It runs in our own AWS account. |
| Amazon Web Services (Amazon Bedrock) | Metadata and text only. Exactly what, step by step, is set out under where your data goes. | They supply the language model three steps call. Same company and same account as the row above; listed separately because it is a different service, engaged on different occasions. |
| Stripe | Your name, email and payment details, given to them directly at their checkout, and the account id we put on the checkout link so the money reaches the right account. They tell us only that a purchase succeeded and for which account. | They handle credit purchases as merchant of record, through Stripe Managed Payments, acting for us rather than selling to you themselves. The name on the receipt is Stripe's affiliate, Sold through Link, LLC. |
We disclose data where the law requires it. If the business is sold or reorganised, customer records transfer with it under the same commitments.
Where your data goes: the language-model steps
Three steps in the pipeline use a large language model, supplied by Amazon Web Services through Amazon Bedrock, in the same AWS account that runs everything else here. It reads your metadata so it can propose which of your columns holds what, match your cell-type names to the reference vocabulary, and write the interpretation section of your report.
The expression matrix and the file itself are never sent.
Some of your data does leave, and it is not only column names. Up to three example values from each metadata column are sent with the column name, so whatever those columns actually contain goes with them. Alongside that: cell-type label text, statistics we have already computed, and anything you typed yourself.
Every step that calls the model, and exactly what each one sends:
| Step | When it runs | What is sent |
|---|---|---|
| Column roles | Only when you press the button that asks for it, and it is priced separately. | The name of each column, its data type, how many distinct values it holds, and up to three real example values from it, so the model can propose which column is your sample, donor or cell type. If a column contains identifiers, three of them go too. |
| Label matching | Whenever you use your own cell-type labels. | The distinct cell-type names in your data, as text, together with the reference's own vocabulary. |
| Interpretation | Only if you tick "Interpret results". | The results the run computed, and the question you typed in the focus box if you wrote one. |
Two more paths exist in the engine and no upload here can reach them.
Our command-line tool can be given a spreadsheet whose layout is ambiguous, and it then
sends the first 8 rows by 12 columns of that raw table, expression values included, to
the model to work out which way round it is; a second path can send the start of a file
that failed to load, to explain the failure, and it is switched off everywhere. Neither
is reachable from this website, because the upload form and the server both accept
.h5ad only, and that is what makes the promise above unconditional here.
A run with no model call at all is available by your own choices, with no request to us. Each of the three is switched on by a choice you make: press the detect button, tick "Interpret results", or bring your own cell-type labels. Leave them and no call is made.
You confirm every column-role proposal before it is applied, and the model runs on Amazon Bedrock inside our own AWS account.
What the model provider may and may not do with it
Your data never leaves AWS at any step.
Bedrock's published default is zero data retention, and the two models we call are not on the short published list of models for which AWS keeps inputs and outputs for as long as 30 days to detect abuse. The second model is a stand-in: if the first is unavailable, column detection is re-issued to it with exactly the same content.
It is not used to train anything: AWS's service terms exclude Amazon Bedrock from the services AWS may learn from, and the company that built the model cannot access what you send.
Where your data is processed
In the United States. The platform runs in the AWS
us‑east‑1 region in Northern Virginia, and Stripe is a US
company. Language-model calls are placed in that region and may be processed in the
us-east-2 and us-west-2 regions under AWS's US routing profile, on the AWS network.
This is a transfer out of the European Union for every customer, wherever they are. The safeguard for each recipient is below.
The safeguard we rely on
For Amazon Web Services, including the language-model calls through Amazon Bedrock, the transfer is carried by the EU Standard Contractual Clauses (controller-to-processor), Commission Implementing Decision (EU) 2021/914, incorporated in our AWS agreement. For Stripe, it is Stripe's certification under the EU-US Data Privacy Framework, with the same Standard Contractual Clauses applying if that certification lapses; the affiliate named on your receipt is covered by the clauses as a listed sub-processor.
Where UK data protection law applies, each provider's International Data Transfer Addendum adapts those clauses to the UK GDPR.
We have assessed each of these transfers against the destination's law, following the EDPB's recommendations on supplementary measures; the assessments, and copies of the safeguards, are available on request at support@varnaops.com.
How long we keep it
| What | How long | Then what |
|---|---|---|
| Your uploaded file | 7 days, and a little over | Deleted automatically shortly after the seventh day. Needed only while the run executes. Copies of it derived by the run live in your results, under the next row. |
| Your results and report | 30 days, and a little over | Deleted automatically shortly after the thirtieth day. They include copies of your expression data, so this is the window that governs it and not the 7 day one above. Download what you want to keep; deleting the run removes them at once. |
| Run records | Until you delete the run or your account | Removed on deletion. |
| Account records | Until you delete your account | Removed with the account, subject to the exceptions below. |
| Billing records | Kept indefinitely | Financial records outlive the account, see below. |
| Request logs | 30 days | Expire on schedule. |
| Website visit logs | 30 days | Expire on schedule. The page-request records under what we collect; no network address, cookie or account link. |
| Analysis choice records | Kept indefinitely | Anonymous; nothing in them points at a person, account, file or run. The per-submission and column-detection records under what we collect: run configuration, never your data or results. |
| Job logs | 30 days | Expire on schedule. A run's log records the names of your batch and donor columns and the level names of your condition column, under what we collect. |
| Security audit records | 400 days | Expire on schedule. Which credential read or wrote which stored object, and when, held in a separate audit store, see who at VarnaOps can reach your data. They hold no content from your file. |
| Destruction record | Kept indefinitely | Held in that separate audit store. Produced when you close your account, see deleting a run, or your whole account. |
| Database backups | Up to 35 days | Deleted data remains restorable within the window, see deleting a run, or your whole account. |
| Data sent to the language model | Not kept | See where your data goes. |
| Label-matching cache | With the run's results | The label matcher's answers are cached for the run that asked for them, inside that run's own results, and go when the run goes. |
| Cost-accounting job records | 365 days | What a run cost us to execute: the job's own identifier, its timings and the resources it used. The file name and the account identifier are removed before the record is written, and the record is deleted when you close your account. |
| Things kept in your browser | 7 days, or until you sign out | On your device only, never sent to us: your sign-in token, which file you uploaded, the column names you confirmed, and anything you typed into the wizard, including the interpretation prompt and which analyses you ticked. Signing out or clearing site data removes them. |
Your rights
If the GDPR or the UK GDPR applies to you, you have all of the following. Erasure needs no request: you delete a run from My runs and the whole account from your account page, and it happens immediately. For the rest, ask by writing to support@varnaops.com. We answer within one month, and we do not charge for it.
| Right | What it means here |
|---|---|
| Access | A copy of the personal data we hold about you, and confirmation of what we do with it. |
| Rectification | Correction of anything wrong. |
| Erasure | Deletion of your runs or your whole account, done by you from the site; see deleting a run or your account below. |
| Restriction | We keep the data but stop processing it, for example while you contest something in it. |
| Objection | You can object to anything we do on the legitimate-interests basis, which is the operational and access-review processing named above. |
| Portability | The data you gave us, in a machine-readable form. Your results already come as a self-contained file you own. |
Deleting a run, or your whole account
You do this yourself, from the site, and it takes effect at once: a run and its results from My runs, an uploaded file from the upload step, and the whole account from your account page. Deleting a run stops it if it is still executing, removes its stored results, and removes the record of it. Deleting your account does that for every run you have, and also removes your uploads, your access-request details and your login. You do not have to email us for any of it.
Some things survive that.
| What survives | How long | Why |
|---|---|---|
| Billing records | Indefinitely | Kept under accounting-law retention duties, which Art. 17(3)(b) preserves. |
| Database backups | Up to 35 days | Removed from the live database at once; the rolling backup ages out within 35 days and is not readable by the product. |
| Logs | Until they expire | Log entries already written age out on the schedule above. |
| Security audit records | 400 days | Kept as the record of administrative access, see who can reach your data. |
| The payment processor's own purchase record | On its schedule | Stripe keeps its own record of a purchase. |
When you close your account we produce a destruction record (counts of deleted objects and prefixes, timestamps, and a post-deletion check that each prefix is empty), kept in a separate audit store, and a copy is returned to you.
Complaints
If you think we have handled your data wrongly, tell us first and we will try to put it right. You do not have to, and going to us does not affect your right to complain to a regulator.
You can go to a regulator wherever you are. Art. 77 of the GDPR lets you complain to the supervisory authority in the country where you live, where you work, or where you think the problem happened.
- European Union: your own national authority. The European Data Protection Board lists them all.
- United Kingdom: the Information Commissioner's Office, ico.org.uk.
- Elsewhere: your national data-protection or consumer authority, if your country has one.
Automated decisions and profiling
We do not make automated decisions about you and do not profile you, so Art. 22 does not arise. The pipeline's predictions concern the cells in the file you upload, not you; they carry confidence scores and are for research use only.
Other deployment models
Other deployment models are not available today; ask us what is.