Privacy Notice

1. Who runs this protocol

Volunos Labs Ltd is the company behind volunos.uk and behind the research described on it. Our company number is NI741243 on the Northern Ireland register, and anything to do with personal data should be addressed to research@volunos.uk. The lab works on applied research and technical feasibility; our filed activities are software development (SIC 62012) and research and experimental development on natural sciences and engineering (SIC 72190).

A privacy notice usually gets written as a list of promises. We have written this one the way we would write up a study, because that is the shape our work actually takes and because it makes the awkward questions unavoidable. Six headings carry the whole thing: who the people are, what material arrives, what we do with it, what entitles us to do that, the conditions it sits under while we have it, and how it goes away.

If a paragraph here cannot be checked against something we would show an auditor, it should not be in a privacy notice at all.

The words "personal data", "controller", "processor", "processing" and "data subject" carry the meanings given to them by the UK General Data Protection Regulation, read together with the Data Protection Act 2018. "PECR" means the Privacy and Electronic Communications (EC Directive) Regulations 2003. Where anything written below reads as narrower than the legislation, the legislation is what applies.

Accountability for this protocol is held at director level and is not delegated to a supplier or to a shared inbox. Correspondence goes to research@volunos.uk, and the person who answers it is the person answerable for it. Should the lab ever take on work of a scale or character that makes a Data Protection Officer appointment necessary under Article 37, we will make the appointment and reissue this notice.

2. Two positions in one laboratory

Arguments about responsibility for personal data nearly always start with nobody being able to say who set the question. There are two positions the lab occupies and they carry different duties, so we name them at the top of every substantive section rather than leaving you to work it out.

2.1 When the question is ours

In the first position we are the investigator. We decided why the data is being handled and broadly how, and we answer to you for that decision directly. This covers everyone who reads the site, everyone who corresponds with us, the named individuals we deal with at organisations we work with or buy from, anyone who approaches us about a job, and anyone holding an account in software we release. Part B is written for those people.

2.2 When the question is a client's

In the second position we are the bench a sponsor sends samples to. A client hands us material for a study — a dataset, access to a running system, source code with real records left in its fixtures — and that client, not us, decided why it is being handled. Our authority comes from their written instruction under Article 28, they answer to the people concerned, and Part D sets out what we commit to while the material is with us.

2.3 The awkward middle

Some material sits between the two and we resolve the ambiguity by treating it as ours. Our record of who we spoke to at a client, the ledger entry for the invoice, the bench notes carrying the initials of whoever ran a given experiment, and our own access logs are all things we decided to keep, decided how long to keep, and would still hold after the study closed. A contractual duty to destroy a client's material at close-out does not reach the statutory accounts we are obliged to keep, nor our own experimental record where it carries nothing confidential to the client.

We do not share the question with a client such that both of us decide it jointly. Were an engagement ever structured that way, an Article 26 arrangement would be put in place first and named here.

3. Reading the role markers

Each section below opens with a marker. Role: controller means the decision was ours and you can hold us to it. Role: processor means a client made the decision, that client is who your entitlements run against, and our job is to help them meet you.

If you found this page because you read something on the site or sent us an email, sections 5, 6, 25 to 28 and 30 to 32 are the ones that concern you. If you are assessing us as a supplier, Part D and section 20 are the substance and will answer most of a standard questionnaire. If your details reached us inside a dataset somebody else supplied, section 9 explains why we will hand your request to them rather than acting on it ourselves.

Role: controller

4. Participants

Five groups of people appear in our records, and they arrive by very different routes. Somebody reading a page here leaves a trace at the edge of the network without ever meaning to. Somebody who emails us has chosen exactly what to disclose. A named contact at a client organisation is in our files because their employer put them there. A person sending a speculative CV is asking to be considered. A person inside a client's dataset has usually never heard of us at all, and section 9 is written with that asymmetry in mind.

Nobody is added to any list here by inference. We do not enrich what you send us against a broker's file, we do not buy contact data, and there is no mechanism on this site or in our processes that builds a profile of a reader.

Role: controller

5. People who read this site

Every page here is a static file. There is no login, no form, no chat widget, no advertising technology, no session replay, no embedded social media and no measurement script. The interactive parts of the site are links, some of which open your own mail client.

Edge and network records

Cloudflare, Inc. delivers the site for us. Returning a page requires the edge to handle your IP address, the moment of the request, the path asked for, the response code, how many bytes went back, the user agent string your browser announces, a referring URL where one is sent, and whatever signals are needed to keep the site standing under attack. None of that is optional; a server that does not know where to send a page cannot send one.

Article 6(1)(f) is our footing here, and the interest is a plain one: keeping a working site up and keeping scanners, credential stuffing and flood traffic off it. Those records are never used to work out who you are, never combined with anything else we hold, and we take no copy of them for ourselves.

The typeface

One typeface is fetched from Google Fonts, operated by Google LLC and, for readers here and in Europe, Google Ireland Limited. Your browser reaches fonts.googleapis.com and fonts.gstatic.com to get it, which shows Google your address and user agent as an unavoidable part of asking. Google's published position is that the font service neither sets cookies nor feeds advertising personalisation. Blocking those two hosts costs you nothing but the lettering — the page falls back to a serif already on your machine and everything on it still works. Our footing for using a font service rather than running one is again Article 6(1)(f).

Departures

Following a link away from here — to the regulator, for instance — puts you under whoever runs that site. What happens there is theirs to explain and outside our control.

Role: controller

6. People who write to us

Correspondence arrives at research@volunos.uk. We receive what you decided to write and the routing information that every message carries with it: your address, your name, the organisation in your signature, a telephone number if you offered one, and the substance of what you asked.

What follows is that somebody reads it and answers, generally inside two working days. Where a conversation develops we keep notes of it; where a proposal follows we keep the proposal; where nothing follows we keep the thread, because a question that returns eighteen months later makes no sense without the first one, and because we would rather be able to show what we actually said.

Article 6(1)(b) covers correspondence heading towards an engagement, since answering you is a step taken at your request before any contract. Anything else — a general question, a supplier introduction, a request for a view on something — rests on Article 6(1)(f), the interest being in replying to post addressed to us and knowing afterwards what the reply was.

A first email is not a confidential channel and should not be treated as one. Describe the problem at a level that does not need unpublished designs, real records or trade secrets attached. Where the question genuinely cannot be put without them, say that, and confidentiality terms and a sensible transfer route come first. Material that turns up unasked for is held under the same duties as material we were engaged to handle, and destroyed if you ask.

Role: controller

7. Named staff at client and supplier organisations

Working with an organisation means holding details of the people inside it: names, roles, work addresses and numbers, the correspondence, notes of meetings, and the record of who approved what. The same is true in reverse of the firms we buy from and the advisers we use.

Details about somebody in their professional capacity are still details about an identifiable person, so this is personal data and is treated as such. Where the individual is themselves the contracting party our footing is Article 6(1)(b); where they act for the employer that signed, it is Article 6(1)(f), and the interest is in running a contract properly and knowing afterwards who agreed to what. Where a statute obliges us to keep something, Article 6(1)(c) is what supports keeping it.

Files outlive engagements deliberately. Questions surface long after a study has closed, professional indemnity cover only works against a defensible record, and limitation periods run for years past the last invoice. Section 21 gives the periods and the reason behind each one.

Role: controller

8. People who approach us about work

Approaches arrive without a vacancy being open and we would rather read them than turn them away. What we then hold is what you sent: a name, how to reach you, a CV or something serving as one, a covering message, and whatever we noted while reading it.

Where a recruitment process is genuinely running, Article 6(1)(b) covers the steps taken at your request ahead of an engagement. For an unprompted approach the footing is Article 6(1)(f), the interest being in considering somebody who might suit and in giving them an answer.

We hold a speculative approach for twelve months so that we can come back to you if something opens, then destroy it. Ask for it to go sooner and it will. If a formal process is ever run, applicants get a fuller notice at the point of applying that deals with assessment, references, right-to-work checks and what happens to unsuccessful applications.

Nothing in the special categories is asked for at any stage, and we would rather you did not volunteer it. Any diversity monitoring introduced later will be kept apart from selection, optional, and anonymous wherever the numbers allow.

Role: processor

9. People inside a client's material

You may be reading this because your details sat in something a client sent us — rows in a dataset, records in a system we were asked to instrument, sample data left inside a repository. You did not choose us and there is no relationship between us to speak of.

Your entitlements in that situation run against the organisation that supplied the material, because that organisation decided why it was being handled. Write to us anyway if we are who you can reach. We will tell you promptly, we will pass the request to the client, and we will do the work of finding and extracting whatever they instruct us to find, at our cost. We will not act on the request independently, because acting on somebody else's data without their controller's instruction is itself a breach of Article 29.

Role: controller

10. Intake register

Below is everything that enters the lab where we are the ones who decided it should, what it is for, the ground it stands on, how long it stays, and who else sees it. Client material handled on instruction is deliberately not in this table; it belongs to Part D.

11. Grounds we rely on

Four of the six grounds in Article 6 do any work here, and it is worth being plain about which does what.

A contract, or the steps before one. Article 6(1)(b) covers handling that has to happen for an engagement to be negotiated, run or wound up — answering an enquiry that is heading somewhere, delivering against a scoping note, invoicing for it.

A legal obligation. Article 6(1)(c) is what keeps the ledger. Company law and tax law both require records to exist for years, and neither is optional for us.

A legitimate interest. Article 6(1)(f) carries the rest: defending the site, replying to post, running an engagement with somebody's employer, keeping a defensible file, and knowing who signed into our own systems. Section 12 sets out how we test each of those.

Consent. Article 6(1)(a) is reserved for things you actively asked for, and where it applies you can take it back without consequence and without explaining why. Nothing on this site currently runs on consent; if that changes, this notice changes with it.

Where a lawful basis would fail, the handling does not happen. That is the whole point of writing the grounds down at the intake stage rather than assembling them afterwards.

12. Weighing a legitimate interest

Article 6(1)(f) is not a default and we do not treat it as one. Before it is relied on, three questions get answered and the answers are written down: what exactly is the interest, could the same end be reached with less, and would the person concerned find it reasonable if they knew.

Two worked cases. Keeping edge records to fend off attack traffic passes easily — the interest is concrete, the alternative is an unavailable site, and no reader is surprised that a web server logs requests. Keeping a closed engagement file for seven years is a closer call, and it passes because limitation periods and insurance cover both need it, and because the file contains professional correspondence rather than anything intimate.

You can object to anything resting on Article 6(1)(f), and section 25 explains how. An objection is a genuine test, not a formality: we stop unless we can show grounds that outweigh yours, and if we cannot show them, we stop.

13. Special category and offence material

Health, biometrics, genetics, ethnicity, religion, political opinion, trade union membership, sex life and sexual orientation are treated as material we did not ask for and would rather not receive. None of it is needed to answer the kind of question the lab exists to answer, and none of our own processes generate it.

Where a client's material turns out to contain it, that is dealt with before the work starts: the client identifies the Article 9 condition they rely on, we restrict who inside the lab can reach the material, and we record both decisions. Where the question can be answered without those fields at all, they are stripped or replaced before the material lands here, which is nearly always the better route and is discussed in section 24.

Criminal offence data under Article 10 is handled the same way, with the additional requirement that a client point us to the condition in Schedule 1 of the Data Protection Act 2018 that permits it.

14. Participants under eighteen

The lab sells to organisations. This site is written for engineers and technical directors, it offers nothing a child would want, and no service here is directed at children or aimed at them.

Should we ever release something online that a child could sign up to, thirteen is the age at which a child can consent to an information society service in the United Kingdom, and below it we would need the holder of parental responsibility. Any such service would be designed against the Children's code before it opened rather than retrofitted after.

If a client's material describes children, the additional care that requires is agreed before intake: minimised fields, a named restriction on who can open it, and the client's confirmation of the condition they rely on. If you believe a child's data has reached us and should not have, write to research@volunos.uk and we will trace it and remove it.

15. No scoring, no automated decisions

Nothing here decides anything about you by machine. Enquiries are read by a person, applications are read by a person, and no algorithm ranks, scores or filters either. Article 22 rights against solely automated decisions with legal or similarly significant effects are therefore not engaged, and if that ever changed we would say so before it did, not afterwards.

Research work is a different matter, and worth separating. We build models, and some of them make decisions inside a client's system. Where that happens the client is the controller of the resulting decisions, the Article 22 question is theirs, and part of our job is usually to tell them plainly where a model's error would change an outcome rather than merely shift a number.

Role: processor

16. Instructions we will and will not act on

Client material moves only on a written instruction. The scoping note for an engagement is the standing instruction; anything outside it needs a new one in writing, and email is enough provided it is unambiguous.

If an instruction looks to us as though it would put the client in breach of data protection law, we say so before carrying it out, in writing, and we hold off until it is resolved. That is Article 28(3) doing its job. Disagreeing with a client's commercial judgement is not the same thing and we do not confuse the two — the test is legality, not preference.

Everyone here who can reach client material is under a written confidentiality duty that outlasts their time with the company. Access is granted for a named engagement, and it is withdrawn at close-out rather than left to lapse.

Role: processor

17. Custody terms we sign up to

The Article 28 commitments below apply to every engagement whether or not the client's own contract restates them.

Material is handled only for the study it was supplied for, under measures proportionate to what would go wrong if it were lost, altered, taken or opened by the wrong person. We help the client answer requests from the people concerned, within timescales that let the client meet its own deadline rather than ours. We help with security obligations, with reporting an incident, and with an impact assessment or prior consultation where the client has to carry one out. We tell the client without undue delay when something has gone wrong at our end, with what we know at the time rather than waiting for a complete picture.

We make available what a client reasonably needs to satisfy itself that these commitments hold, and we submit to an audit or an inspection carried out by the client or somebody they appoint. In practice a written questionnaire answered from the record settles this, and we would rather answer one properly than host a visit that proves less.

Role: processor

18. Assistants we bring in

A handful of suppliers sit behind the lab. Each is engaged under written terms that carry the same duties down the chain, and no client material reaches a supplier not listed here without the client being told first.

Replacing one of these, or adding one that would touch client material, is notified to affected clients ahead of the change with enough time to raise an objection. A reasoned objection is worked through; where it cannot be resolved, the client may end the engagement for that reason without penalty.

Role: processor

19. Close-out: return and destruction

Every engagement ends with a close-out step, and it is a step with a written output rather than a gradual fading of access. The client chooses whether material comes back or is destroyed. Whichever they choose, working copies, cached artefacts, compute images and the credentials that reached client systems all go, and we confirm in writing what was returned, what was destroyed and on what date.

Two things survive close-out, and clients are told so at the start rather than discovering it later. The ledger survives because company and tax law require it. Our bench record of what was tried and what came of it survives because that is the scientific record of our own work — and where it would otherwise carry anything confidential or identifying belonging to the client, it is redacted down to method and outcome before it goes into the archive.

20. Storage conditions

A laboratory that could not say how its samples are stored would not be much of a laboratory. Ours are digital, and the conditions are these.

Machines that touch client material run full-disk encryption, automatic locking and current operating system and application patches. Sign-in to every service that holds anything of substance requires a second factor, with hardware or an authenticator app rather than a code sent by text. Access follows the engagement: rights are granted against a named study, reviewed while it runs, and removed at close-out. Client material lives in a separate area per engagement, so a person cleared for one study cannot walk into another.

Material in transit is encrypted, and so is material at rest on our storage. Backups are encrypted, held separately from live systems, and restored as a test rather than assumed to work. Personal devices are not used for client material. Where a client's own environment is the safer place for their data, we work inside it and take nothing out — which is frequently the right answer and is one of the first things we propose.

The measures are reviewed at least annually and after any incident, and they are written down in enough detail to answer a supplier questionnaire from the record. Send one to research@volunos.uk and we will answer it in writing.

21. How long material is kept

Retention here is a decision with a reason attached, not a default that nobody revisits. The periods in the intake register at section 10 are the operative ones, and the reasoning behind the longer ones is worth stating.

Engagement files and bench records are kept for seven years from close-out. The driver is the limitation period for a contractual claim, the terms on which professional indemnity cover responds, and the possibility that a client's research relief claim is examined years after the work was done — an examination the client cannot answer if we have destroyed the record. Accounting records run for six years from the end of the accounting period plus the current one, because that is what the Companies Act and tax law require of us.

Everything else is shorter and deliberately so. Correspondence that led nowhere goes at twenty-four months. Approaches about work go at twelve. Access records go at thirteen months, long enough to investigate something noticed late and no longer. When a period expires the material is destroyed, and where it sits in a backup that cannot be selectively edited, it is put beyond use and destroyed when that backup cycles.

22. Material that leaves the United Kingdom

The lab is run from the United Kingdom and so is everything we hold by choice. Two routes take material across a border anyway and both are covered.

Serving this site means your request meets a Cloudflare edge, which may be outside the UK depending on where you are and how the network is routing that day, and Cloudflare's parent is in the United States. Running the mailbox means our provider's support function may be reachable from outside the UK. In each case the international transfer rests on the Information Commissioner's international data transfer agreement, or on the UK Addendum to the EU standard contractual clauses, and we hold the supplier's documentation for it.

Where a country has been recognised by UK adequacy regulations, that recognition is what the transfer rests on. Beyond the paperwork we look at whether the safeguards actually hold in the destination — what a public authority there could demand and what the supplier could refuse — and where that assessment fails, the material stays here. Client engagement material is not sent outside the UK at all unless the client instructs it in writing and the route above is documented first.

23. Adverse events

A personal data breach means material being destroyed, lost, altered, disclosed or reached by somebody who should not have reached it, whether by accident or by intent. Studies have adverse event procedures; this is ours.

The first hour goes on containment and on establishing what actually happened rather than what it looked like. An assessment follows: whose data, how much, how sensitive, what could now be done with it, and whether the people concerned face a real risk. Where the risk to people's rights is more than unlikely, the Information Commissioner is told within seventy-two hours of our becoming aware, with what is known at the time and the rest to follow. Where the risk is high, the people affected are told directly and in plain language — what happened, what it means for them, what we have done, and what they should do.

Where the material was a client's, the client is told without undue delay so that they can meet their own reporting duty, and we give them what they need to do it. Every incident is written up whether or not it was reportable, including the ones that came to nothing, because the pattern across small incidents is usually more informative than any single one.

24. The least identifying material that answers the question

Most technical questions do not need real people in the data to be answered. Whether a surrogate model holds its accuracy, whether filtering recovers a signal, whether a scheduling problem is tractable at the scale being proposed — none of those turn on whose records are in the file.

So the first question we ask about any dataset is how much of it can go. Sometimes the answer is that identifiers can be dropped entirely and the study runs on structure alone. Sometimes a synthetic set with the same statistical shape does the job, and we would rather build one than take a copy of the real thing. Sometimes pseudonymisation is as far as it can go without destroying what is being studied, in which case the keys stay with the client and never travel with the data.

This is not merely a compliance preference. Material that never arrives cannot leak, cannot be requested, and cannot be argued about later. Where a client wants to send us more than the question needs, we push back — politely the first time.

Role: controller

25. What you are entitled to ask for

Where we decided the purpose, the following are yours to exercise. Write to research@volunos.uk and put "Data protection request" in the subject line so it is not mistaken for an enquiry.

You may ask what we hold about you and receive a copy. You may have inaccuracies corrected and gaps completed. You may ask for material to be erased where there is no longer a good reason for us to have it. You may ask us to pause handling while something is in dispute. You may object to anything running on Article 6(1)(f), including at any time and without giving a reason where it concerns direct marketing. Where handling rests on your consent or on a contract and is done by automated means, you may ask for what you gave us in a portable form, and for it to go straight to somebody else where that is technically workable. Where you gave consent, you may withdraw it, and doing so does not unpick what was lawfully done beforehand.

We reply within one month of receiving a request. A complicated request may take up to a further two months, and if it does we will tell you inside the first month and say why. There is no charge. We may need to confirm you are who you say you are before releasing anything, and we will ask for the least that settles it rather than demanding documents we do not need.

Occasionally we cannot give you everything. A copy that would expose somebody else's personal data, or material covered by legal professional privilege, or a client's confidential information that happens to sit alongside yours, gets withheld or redacted — and we will tell you that we have done so and on what basis, rather than quietly editing.

26. Withdrawal, account deletion and erasure

Anything you gave us can be taken back out. Ask for deletion of data held about you and we will do it, subject only to records a statute obliges us to keep — chiefly the ledger, where an invoice line naming you cannot lawfully be removed until its retention period runs out. Where that applies, we say which record is staying and why, and we restrict it so that it is used for nothing else.

Should we ever run software with sign-in, account deletion will be available from inside the account itself and by writing to research@volunos.uk, both routes reaching the same place. A deletion request would be completed within thirty days, covering the account, its content and its backups on the next backup cycle; the confirmation would be in writing; and the only thing retained would be the minimum needed to show that the deletion happened.

Where the material is a client's and we hold it as processor, the request goes to that client under section 9, and we carry out the deletion they instruct.

27. Cookies, browser storage and the typeface

No measurement, advertising or preference cookie is set here. Cloudflare may place one strictly necessary security cookie, which is exempt from consent under regulation 6(4) of PECR; our cookie policy names it, gives its lifetime and explains the exemption in full. Nothing here writes to localStorage or sessionStorage, and the typeface request described in section 5 is the only third-party call any page makes.

28. Electronic mail and PECR

We reply to people who write to us. Beyond that, nothing goes out by email without somebody having asked for it.

Should the lab ever circulate research updates, joining would take a positive act — an unticked box or an explicit request — and we would keep the record of when and how that was given, as Article 7(1) requires. Consent under Article 6(1)(a) would be the ground, and regulation 22 of PECR would be satisfied by that same consent. Every message would carry a working unsubscribe link that takes effect at once and without conditions, and leaving would put your address on a suppression list purely so that we do not write to you again by mistake. Lists are not bought, a business card is not consent, and a connection on a professional network is not consent either.

29. Applications we release

The lab builds tooling for its own use, and a piece of it may one day be released publicly. This section is the standard any such release is held to, written now so that the position is settled before there is any commercial pressure on it.

An application asks for a device permission only where a feature you have chosen cannot work without it, asks at the moment that feature is used rather than at first launch, and continues to function in a reduced form if you decline. Declining is never punished.

On iOS, App Tracking Transparency governs any access to the advertising identifier, and we have nothing to track you across other companies' apps and sites with — so the ATT prompt would not appear, because there would be nothing to ask for. On Android, the Google Play Data Safety declaration would be filled in to match this notice line for line: what is collected, what it is used for, whether it is shared, whether it is encrypted in transit, and how deletion is requested. Where the Data Safety form and this notice ever disagreed, the discrepancy would be treated as a defect and fixed in both places.

Purchases and subscriptions made through an app store are billed by that store under its own terms, and the store — not us — holds your payment details. Account deletion inside any application we release follows section 26.

30. Amendments

This notice carries a version number and an effective date, and the header of every issue names what it supersedes. Version 2.0 restructured the notice around the way the lab actually works and reissued it in full.

Small corrections — a clearer sentence, a supplier's name changing — are made as they arise and the effective date moves. A change that alters what we do with your material, or the ground we do it on, is a new version, and where we hold your address and the change matters to you, you will hear about it before it takes effect rather than after.

31. Raising a concern, and the ICO

Tell us first if you can. Write to research@volunos.uk with "Data protection concern" in the subject and it goes to a director. You will get a considered answer setting out what we found and what we are doing, and where we got something wrong we will say so plainly.

You do not have to come to us first, and going to us does not use up any other route. The Information Commissioner's Office regulates data protection in the United Kingdom and takes complaints directly at Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF, by telephone on 0303 123 1113, and at ico.org.uk. You may also take the matter to court, and you may do that whether or not you have complained to the regulator.

32. Reaching us

One address covers all of it: research@volunos.uk. Mark the subject line "Data protection request" to exercise an entitlement under section 25, or "Data protection concern" to raise something that has gone wrong. Formal notices under a contract should go to the registered office as that contract directs, with a copy to the same address.

The company is Volunos Labs Ltd, company number NI741243 on the Northern Ireland register. How we scope and run an engagement is described on the working with us page, and the contractual footing is in our terms.