Privacy Notice

1. Who we are and what this notice covers

Volunos Labs Ltd ("Volunos Labs", "the lab", "we", "us", "our") is a company incorporated on 7 June 2026 and registered in Northern Ireland under company number NI741243. Our registered office is City East, 72 Newtownards Road, Belfast, Northern Ireland, BT4 1GW. We trade as Volunos Labs and operate the website at volunos.uk.

We are an applied research lab. Our registered activities are software development (SIC 62012) and other research and experimental development on natural sciences and engineering (SIC 72190). In practice we carry out applied research and technical feasibility studies for organisations, run our own internal research across algorithms, simulation, signal processing, edge computing and engineering data modelling, and undertake research and development engineering — taking laboratory code into maintainable production systems and producing the technical documentation and experiment records that research and development work requires.

This notice explains what personal data we handle, why, on what legal footing, who else sees it, how long we keep it, where it goes, and what rights you have over it. It applies to this website, to correspondence with us, to our commercial and research engagements, and to any mobile or desktop application we publish. Part F applies specifically to mobile applications and applies only where we have actually published one; at the effective date of this notice we have not, and Part F is included so that the position is documented in advance rather than written after the fact.

We are the data controller for the personal data described in Part B. For the personal data described in Part C we are a processor acting for a client who is the controller. The distinction matters and section 2 explains it.

"Personal data", "special category data", "controller", "processor", "processing" and "data subject" have the meanings given in the UK General Data Protection Regulation (the "UK GDPR") as it forms part of the law of England and Wales, Scotland and Northern Ireland, read with the Data Protection Act 2018 (the "DPA 2018"). References to the Privacy and Electronic Communications (EC Directive) Regulations 2003 are to "PECR".

We are not required to appoint a Data Protection Officer under Article 37 of the UK GDPR and have not appointed one. Responsibility for data protection sits with the company's directors, and privacy correspondence should be addressed to research@volunos.uk. Where we take on an engagement whose scale or nature would make an appointment necessary, we will make it and update this notice.

2. Our two roles: controller and processor

Almost every dispute about responsibility for personal data begins with confusion about who decided what. We therefore state our roles explicitly and mark every substantive section of this notice with the role it belongs to.

2.1 Where we are a controller

We are a controller where we decide, on our own account, why personal data is processed and how. That covers people who visit this website, people who write to us with an enquiry, the named individuals we deal with at client and supplier organisations, anyone holding an account in an application we publish, anyone who asks to receive research updates from us, and people who apply to work with us. Part B deals with all of these.

2.2 Where we are a processor

We are a processor where a client gives us material to work on in the course of a research engagement, that material contains personal data, and the client — not us — decides why we are processing it and broadly how. Typical examples are a dataset supplied for a feasibility study, access to a client system needed to instrument it, or source code that happens to contain personal data in fixtures or logs. In those cases the client is the controller and answers to the data subjects; we act on the client's documented instructions under Article 28 of the UK GDPR. Part C sets out our commitments in that role.

2.3 Where the roles meet

Some processing sits close to the boundary and we treat it as controller processing to avoid ambiguity. Our record of who we corresponded with at a client, our invoicing records, our own experiment records naming which of our people ran which experiment, and our security logs are all our own — we decide to keep them, we decide for how long, and we would keep them even if the engagement ended. Where a client's contract requires us to delete engagement material, that requirement does not extend to our own accounting records, which we must keep by law, or to our internal experiment records to the extent they contain no client confidential information.

We do not act as a joint controller with any client at the effective date of this notice. If an engagement were structured so that we and a client genuinely determined purposes together, we would put an Article 26 arrangement in place and say so.

3. How to use this notice

The contents list above links to every section. Each substantive section carries a role marker: Role: controller means we decide the purpose and are accountable to you directly; Role: processor means a client decides and you should approach that client, though we will help.

If you are a visitor to this website or someone who has written to us, sections 4, 5, 27 to 33 and 41 to 43 are the ones that concern you. If you are a client considering an engagement and completing a supplier assessment, Parts C, D and E are the substance, and section 29 states honestly what security assurances we do and do not hold. If you are a data subject whose data was supplied to us by a client, section 16 explains why we will route your request to them.

This notice is written to be read. Where a legal term is unavoidable we have used it and explained it. Nothing in this notice restricts a right you have under data protection law, and where anything here appears to conflict with the UK GDPR or the DPA 2018, the legislation prevails.

4. Website visitors

This website is a set of static files. It carries no analytics, no advertising technology, no tracking pixels, no social media embeds, no session recording, no chat widget and no third-party scripts other than the web fonts described below. There is no login and there are no forms; the only interactive elements are links, including links that open your own email client.

4.1 Server and network logs

The site is served through Cloudflare, Inc. as our content delivery network and hosting provider. In delivering a page, Cloudflare processes your IP address, the time of the request, the URL requested, the HTTP status returned, the volume of data transferred, your user agent string and referring URL where your browser sends one, and information necessary to defend the site against attack. This is ordinary web-server processing and it is not optional — a server cannot return a page without knowing where to send it.

We rely on Article 6(1)(f) of the UK GDPR, legitimate interests, for this processing. Our interest is in operating a functioning website and protecting it from denial-of-service traffic, credential stuffing and vulnerability scanning. We do not use these logs to build a profile of you, do not attempt to identify you from them, and do not combine them with any other source.

4.2 Cookies and local storage

We set no analytics, advertising or preference cookies. Cloudflare may set a strictly necessary cookie for security purposes; that cookie, its purpose and its lifetime are listed in our cookie policy, which also explains why it does not require consent under regulation 6(4) of PECR. This site does not write to localStorage or sessionStorage.

4.3 Web fonts

Typefaces are requested from Google Fonts, operated by Google LLC and, for users in the United Kingdom and Europe, Google Ireland Limited. Your browser makes a request to fonts.googleapis.com and fonts.gstatic.com, which discloses your IP address and user agent to Google as a necessary consequence of the request. Google states that Google Fonts does not set cookies and does not use the request data for advertising personalisation. If you would rather not make that request, blocking those two hosts in your browser or an extension will cause the site to fall back to typefaces already installed on your device; the site remains fully readable and every function still works.

We rely on legitimate interests under Article 6(1)(f) for the use of a font service, our interest being consistent legible typography without self-hosting infrastructure we would then have to secure and maintain.

4.4 Links to other sites

Where this site links to an external site — for example to the Information Commissioner's Office — that site's own privacy notice governs what happens when you arrive there. We have no control over and take no responsibility for third-party sites.

5. Enquirers and prospective clients

There is deliberately no contact form on this site. Enquiries reach us by email at research@volunos.uk. When you write to us we receive whatever you choose to put in the message and its headers: your name, your email address, your employer where you mention it, your telephone number if you include it, the substance of your enquiry, and the routing information every email carries.

5.1 What we do with an enquiry

We read it, we decide whether it is work we can usefully do, and we reply — normally within two working days. If a conversation follows, we keep notes of it. If a proposal follows, we keep the proposal and the correspondence around it. If nothing follows, we keep the thread so that we can recognise the context if you write again, and so that we can evidence what was said if a question later arises about it.

5.2 Lawful basis

Where you are enquiring about a possible engagement, our processing is necessary in order to take steps at your request prior to entering into a contract, Article 6(1)(b). Where the enquiry does not lead towards a contract — a general question, a supplier approach, a request for comment — we rely on legitimate interests, Article 6(1)(f), our interest being in responding to correspondence addressed to us and keeping a record of what we said.

5.3 What we do not do

We do not add enquirers to a marketing list. We do not sell, rent or share enquiry details. We do not use enquiries to enrich a database, run them against data brokers, or score them automatically. We do not pursue people who did not reply; a single follow-up at most, and only where you asked us to follow up or where a proposal was outstanding.

5.4 Please do not send confidential material first

Email is not a confidential channel by default. We ask that a first enquiry describes the problem at a level that does not require unpublished designs, personal data or trade secrets to be attached. Where the question genuinely cannot be described without them, say so and we will agree confidentiality terms and a suitable transfer route first. If confidential or personal material arrives unsolicited, we will handle it under the confidentiality obligations described in section 23, and will delete it on request.

6. Client and supplier contacts

When we work with an organisation, we hold personal data about the individuals we deal with there: names, job titles, work email addresses and telephone numbers, correspondence, meeting notes, and records of decisions and approvals. The same applies in reverse to our suppliers and to professional advisers.

This is business contact data about identifiable people and is therefore personal data, even though it concerns them in a professional capacity. Our lawful basis is Article 6(1)(b) where the individual is a party to the contract, and Article 6(1)(f) where they are acting for a company that is the contracting party — our legitimate interest being in administering a contract we have entered into with their employer and in maintaining a record of what was agreed with whom.

Where the law requires us to keep records — company law, tax law, the accounting record requirements described in section 28 — the lawful basis for retaining those records is Article 6(1)(c), compliance with a legal obligation.

We keep records of engagements after they end. We do this because disputes and questions arise afterwards, because professional indemnity insurance requires a defensible record, and because statutory limitation periods run long after the work is finished. Section 28 sets out the periods and the reason for each.

7. Account holders in our applications

We do not currently publish any application with user accounts. This section states the position that will apply if and when we do, so that it is documented in advance rather than assembled afterwards.

Where we offer an account, we would hold: the identifier used to create it, normally an email address; an authentication credential, stored as a salted hash and never in plain text; a display name where the account holder chooses to set one; the settings and preferences attached to the account; a record of significant account events such as creation, password reset, sign-in from a new device, and deletion; and any content the account holder creates within the application.

Our lawful basis for account processing would be Article 6(1)(b), performance of a contract with the account holder, since without an account the service cannot be provided. Security event logging attached to accounts rests on Article 6(1)(f), our interest being in detecting and investigating unauthorised access, and in some circumstances on Article 6(1)(c) where a legal obligation to keep such records applies.

Account deletion, including the routes and the thirty-day completion commitment, is described at section 40. Those commitments would apply from the day any such account service opened.

8. Recipients of research updates

We do not operate a newsletter or a mailing list at the effective date of this notice, and no one is subscribed to anything. If we later publish research updates by email, they will work as follows.

Subscription will require a positive opt-in — an unticked box or an explicit request — and we will keep a record of when and how consent was given, as Article 7(1) requires. The lawful basis will be consent, Article 6(1)(a), and the PECR requirement at regulation 22 for unsolicited electronic marketing will be satisfied by that consent. Every message will carry a working unsubscribe link, unsubscribing will take effect immediately and without conditions, and we will keep a suppression record of the fact that you unsubscribed so that we do not contact you again in error. A suppression record is the minimum needed to honour the objection and is itself justified under Article 6(1)(c) read with Article 21(3).

We will not buy lists, will not use "soft opt-in" as a route into research updates for people who merely enquired, and will not treat a business card or a LinkedIn connection as consent.

9. Job applicants and speculative approaches

We are not currently recruiting and have no applicant tracking system. Speculative approaches do arrive and this section covers them.

If you write to us about work, we hold what you send: your name, contact details, curriculum vitae or equivalent, covering message, and any notes we make about it. Our lawful basis is Article 6(1)(b) where a recruitment process is under way and processing is necessary to take steps at your request before entering into a contract of employment or engagement, and Article 6(1)(f) for speculative approaches, our interest being in considering people who may be a good fit and replying to them.

We keep speculative approaches for twelve months from receipt so that we can come back to you if something opens up, and then delete them. If you would rather we deleted yours sooner, say so and we will. Where a formal recruitment process runs in future, we will provide applicants with a separate, fuller notice at the point of application covering assessment methods, references, right-to-work checks and retention of unsuccessful applications.

We do not ask for special category data in recruitment and ask that you do not volunteer it. Where diversity monitoring is introduced it will be separate, optional, anonymous where possible, and never visible to anyone making a selection decision.

10. Controller data inventory

The table below is the complete inventory of personal data we process as a controller at the effective date of this notice. Rows describing services we do not yet operate are marked as such and are included so that the position is stated in advance.

11. The lawful bases we rely on

Article 6(1) of the UK GDPR permits processing only on one of six bases. We rely on four of them and never on the remaining two.

11.1 Article 6(1)(a) — consent

Used only for research updates by email, if and when we operate them, and for any non-essential cookie should we ever introduce one. Consent is asked for separately, in plain terms, with no pre-ticked boxes, and can be withdrawn at any time as easily as it was given. Withdrawing consent does not affect the lawfulness of processing carried out before withdrawal.

11.2 Article 6(1)(b) — contract

Used for negotiating and performing engagements, for steps taken at your request before a contract, and for providing an application to an account holder. Where processing is not genuinely necessary to deliver what was agreed, we do not use this basis.

11.3 Article 6(1)(c) — legal obligation

Used for statutory accounting and tax records, for company law obligations, and for responding to lawful requests from a regulator, court or law enforcement body where we are compelled to do so. We do not treat a request as compelling unless it is properly made, and we will tell the data subject where we are lawfully able to.

11.4 Article 6(1)(f) — legitimate interests

Used for site security and availability, for ordinary business correspondence, for keeping records that let us defend the work we have done, for managing supplier relationships, and for considering speculative approaches about employment. Section 12 sets out how we assess this basis.

11.5 Bases we do not use

We do not rely on Article 6(1)(d), vital interests, or Article 6(1)(e), public task. Neither applies to what we do. If circumstances ever arose in which a vital interests basis were genuinely engaged — an emergency in which someone's life depended on disclosure — we would act and record the decision, but no routine processing rests on it.

12. Legitimate interests, assessed

Where we rely on Article 6(1)(f) we carry out and record a three-part assessment: whether the interest is legitimate, whether the processing is necessary to achieve it, and whether it is overridden by the interests, rights and freedoms of the people concerned. The summaries below state the conclusions we reached. The fuller assessments are available on request to research@volunos.uk.

Website security and availability

Purpose: keeping the site online and defended. Necessity: a web server cannot function without processing request metadata, and defensive filtering is impossible without it. Balance: the data is minimal, is not used to identify or profile visitors, is not combined with other sources, and the processing is what any visitor would expect. We concluded the interest is not overridden.

Business correspondence

Purpose: reading and answering messages sent to us, and keeping a record. Necessity: we cannot answer a message without processing it, and a record is necessary to be consistent and to evidence what was said. Balance: the data is what the correspondent chose to send, retention is limited to 24 months where nothing follows, and nothing is used for a different purpose. Not overridden.

Records supporting the defence of claims

Purpose: keeping engagement records long enough to answer a claim or complaint. Necessity: limitation periods in Northern Ireland run for six years for simple contract claims, and a defence without records is no defence. Balance: retention is capped at seven years, records are held securely and not used for any other purpose, and the interest in access to justice cuts both ways. Not overridden.

Speculative employment approaches

Purpose: considering people who write to us about work. Necessity: we cannot consider an approach without holding it. Balance: the person chose to send it, retention is twelve months, deletion is available on request, and nothing is shared. Not overridden.

You have an absolute right to object to processing based on legitimate interests where it is for direct marketing, and a qualified right to object in all other cases. Section 31.6 explains how.

13. Special category and criminal offence data

Special category data is data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data processed to identify a person uniquely, data concerning health, and data concerning a person's sex life or sexual orientation. Processing it requires a condition under Article 9(2) in addition to an Article 6 basis, and in most cases a condition in Schedule 1 to the DPA 2018.

We do not seek special category data and, as a controller, do not process it in any of the categories set out in section 10. We do not ask about health, we do not ask about protected characteristics, and we do not process biometric or genetic data.

Two situations require honesty rather than a flat denial. First, someone may volunteer special category data unprompted in an email — a reference to a health condition affecting a deadline, for example. Where that happens the data exists in our mailbox because the sender put it there. We do not use it, do not extract it into any record, and delete the message on request. Second, a research engagement may involve a client dataset containing special category data; in that case we are a processor, the client is responsible for identifying the Article 9 condition, and section 17 sets out the additional controls we apply. We will not accept special category data into an engagement without that condition being stated in the instruction and appropriate safeguards being agreed in writing.

Criminal offence data under Article 10 and Part 3 of Schedule 1 to the DPA 2018 is not processed by us in any capacity. We do not run criminal record checks and do not accept datasets containing offence data.

14. Children's data

This website and our services are directed at organisations and at professionals acting for them. They are not directed at children and are not designed to appeal to them. We do not knowingly collect personal data from anyone under the age of 18, and there is no functionality here — no account, no form, no comment facility, no community — through which a child could provide data to us.

Where an application is published in future, we will assess whether it is likely to be accessed by children and, if it is, apply the ICO's Age Appropriate Design Code in full, including data protection by default, no profiling, no nudge techniques and a clear child-facing explanation. We would state that position in the store listing and here.

Where a research engagement involves data about children, that is client data and we are a processor. Our position is that such an engagement requires an explicit written instruction identifying the lawful basis and, where relevant, the Article 9 condition, a documented data protection impact assessment carried out by the client, and agreement that the data will be pseudonymised or synthetic where the research question permits. We will decline work involving children's data that does not meet those conditions.

If you believe a child has provided us with personal data, write to research@volunos.uk and we will delete it.

15. Automated decision-making and profiling

Article 22 of the UK GDPR gives you the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning you or similarly significantly affects you.

We take no such decisions. Enquiries are read by a person and answered by a person. We do not score, rank or filter correspondents automatically. We do not use automated tools to decide whether to work with an organisation, what to charge, or whether to accept an application for work. Spam filtering applies to inbound email, as it does to every mailbox, but it neither makes nor supports a decision about a person in the Article 22 sense; where a message is misfiled by a filter, the consequence is that we did not see it, and a second message or a telephone call fixes it.

Our research work involves building and evaluating algorithmic systems, including systems that make predictions. That is the subject matter of the research, not a decision-making process applied to you. Where we build such a system for a client, the client decides whether and how to deploy it and is responsible for its Article 22 position, for any impact assessment it requires, and for the safeguards under Article 22(3). We will say so in writing at the point the question arises, and our findings reports state the evaluated limits of any model we produce precisely so that a deployment decision can be made on evidence.

If we ever introduced automated decision-making that engaged Article 22 in respect of you, we would tell you before it applied, explain the logic involved and the significance and envisaged consequences, and provide a route to obtain human intervention, express your point of view and contest the decision.

16. What being a processor means here

A research engagement frequently requires us to work on material the client holds. A feasibility study on maintenance prediction needs the maintenance history. A study on record matching needs records. A study on how a system behaves under load needs a realistic corpus. Where that material contains personal data, the client is the controller — they collected it, they decided why it exists, and they answer to the people it describes — and we process it only to perform the engagement.

16.1 The practical consequences

We do not decide what the data is used for beyond the agreed research purpose. We do not use client data to improve our own tools, to train models retained by us, or as material in our internal lines of enquiry. We do not disclose it except as instructed or as legally compelled. We do not keep it after the engagement ends beyond what section 22 permits.

16.2 If you are a data subject in client data

If your personal data reached us because an organisation supplied it for research, and you want to exercise a right over it, the request properly goes to that organisation. If you approach us, we will tell you promptly that we act as a processor, will not disclose the client's identity unless the client agrees or the law requires it, and will pass the request to the client without undue delay so that they can respond. We will assist them in doing so, as Article 28(3)(e) requires. We cannot lawfully act on the request ourselves, because doing so would be processing outside the controller's instructions.

16.3 Minimising the question

The best answer to processor risk is usually to avoid holding the data at all. Before an engagement starts, we ask whether the research question can be answered on anonymised data, on synthetic data generated to the same statistical shape, on a sample rather than a population, or on the client's own infrastructure with nothing transferred to us. Section 24 explains this in more detail. Where one of those routes works, we take it.

17. Our Article 28 commitments

Where we act as a processor, we enter into a written agreement with the controller containing the terms required by Article 28(3) of the UK GDPR. Our standard data processing terms, offered to every client and available on request before an engagement begins, commit us to the following.

17.1 Documented instructions

We process personal data only on the controller's documented instructions, including as to transfers to a third country, unless required to do otherwise by law — in which case we inform the controller of that legal requirement before processing, unless the law prohibits us from doing so on important grounds of public interest.

17.2 Confidentiality of personnel

Everyone we authorise to process personal data is bound by a written duty of confidentiality that survives the end of their engagement with us, and is given access only to what their task requires.

17.3 Security

We implement appropriate technical and organisational measures under Article 32, taking account of the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as well as the risk to individuals. Section 29 describes those measures honestly, including what we do not have.

17.4 Sub-processors

We do not engage a sub-processor without the controller's prior specific or general written authorisation. Where general authorisation is given, we inform the controller of intended changes and give them the opportunity to object. Any sub-processor we engage is bound by data protection obligations no less protective than ours, and we remain fully liable to the controller for their performance. Section 18 lists our sub-processors.

17.5 Assistance with data subject rights

Taking account of the nature of the processing, we assist the controller by appropriate technical and organisational measures, insofar as possible, in fulfilling their obligation to respond to requests to exercise data subject rights.

17.6 Assistance with Articles 32 to 36

We assist the controller in ensuring compliance with the obligations on security of processing, breach notification to the ICO and to data subjects, data protection impact assessments and prior consultation, taking into account the nature of processing and the information available to us.

17.7 Deletion or return

At the controller's choice, we delete or return all personal data at the end of the provision of services and delete existing copies, unless the law requires storage. Section 22 sets out how this works in practice.

17.8 Information and audit

We make available to the controller all information necessary to demonstrate compliance with Article 28 and allow for and contribute to audits, including inspections, conducted by the controller or an auditor they mandate. Section 21 explains the practical arrangements.

17.9 Additional controls for sensitive engagements

Where an engagement involves special category data, data about children, or data whose disclosure would cause serious harm, we apply additional controls agreed in writing before the data moves: processing on a dedicated encrypted volume, access restricted by name rather than by role, no copies to personal devices, an access log retained for the engagement and provided to the client at the end, and destruction confirmed in writing.

18. Sub-processors and change notification

A sub-processor is a third party we use that may process personal data on a controller's behalf in the course of us delivering a service. Our sub-processor list is deliberately short, because the smaller the supply chain, the smaller the surface a client has to assess.

Where a client engagement requires no cloud processing — because the work runs on the client's infrastructure, or on isolated hardware in our possession — the third row does not apply to that engagement, and we say so in the engagement's data processing terms.

18.1 Change notification

We commit to giving each client at least thirty days' written notice before adding or replacing a sub-processor that would process their personal data. The notice identifies the sub-processor, its function, the location of processing and the transfer mechanism. A client may object on reasonable data protection grounds within that period; if we cannot resolve the objection, the client may terminate the affected part of the engagement without penalty and we will return or delete the data under section 22.

The named third-party organisations above are our current suppliers. Where an entry names a function rather than a company, that is because the specific supplier is confirmed to each client in their engagement documentation, which is where a client's assessment obligation properly bites. Any client or prospective client can ask for the current, fully named list at research@volunos.uk and we will provide it.

19. Instructions and unlawful instructions

We act on the controller's documented instructions. In practice, the instruction set for a research engagement is the statement of work read with the data processing terms: what data we may access, for what research purpose, using what methods, on what infrastructure, and for how long.

Where an instruction is ambiguous, we ask rather than assume. Where an instruction would take us outside the agreed purpose — a request mid-engagement to use a dataset to answer a different question, for instance — we treat it as a new instruction requiring the controller to confirm in writing that it is within their own lawful basis.

Article 28(3) requires us to inform the controller immediately if, in our opinion, an instruction infringes the UK GDPR or other data protection law. We will do so in writing, will explain why, and will suspend the affected processing until the position is resolved. Examples of instructions we would challenge include: processing personal data for a purpose materially different from the one it was collected for without a basis for that change; retaining data beyond the period the controller has told data subjects about; accepting a dataset that appears to have been obtained without a lawful basis; and transferring data to a jurisdiction without a valid transfer mechanism.

We would rather lose the work than process unlawfully, and we will say so early enough that a client can change course.

20. Assistance with rights and Articles 32 to 36

20.1 Data subject requests

If a data subject contacts us about data we hold as a processor, we notify the controller without undue delay and in any event within three working days, providing the request and any information we hold that is relevant to answering it. Where the controller needs us to search, extract, correct, restrict, export or delete records in order to respond, we do so on their instruction and within a timescale that allows them to meet the one-month deadline under Article 12(3).

20.2 Security assistance

We provide, on request, a description of the technical and organisational measures applied to the engagement, so that the controller can satisfy themselves under Article 32. Section 29 is the general statement; engagement-specific measures are described in the engagement documentation.

20.3 Breach assistance

Where we become aware of a personal data breach affecting data we process for a controller, we notify that controller without undue delay, as Article 33(2) requires, and in any event within twenty-four hours of becoming aware. Section 30 sets out what the notification contains and how we support the controller's own notification obligations, including the seventy-two hour deadline that applies to them.

20.4 Impact assessments and prior consultation

Where a controller is carrying out a data protection impact assessment under Article 35, or consulting the ICO under Article 36, we provide the technical information they need: what the processing actually does, what data it touches, what safeguards are applied, what residual risk we consider to remain, and what alternatives we considered. For research engagements this is often the most useful assistance we give, because the technical detail that determines the risk is exactly what we are working on.

21. Audit and information rights

Controllers have the right under Article 28(3)(h) to audit our processing. We support that right in three ways, in ascending order of intrusiveness, and we do not charge for the first two.

First, a written information request: send a security questionnaire or a list of questions to research@volunos.uk and we will answer it accurately and in writing, normally within ten working days. We answer honestly, including where the answer is that a control is not in place. We do not have certifications to substitute for this and we do not pretend otherwise.

Second, a call with the people who do the work, where a questionnaire is not sufficient and a client needs to probe specifics.

Third, an on-site or remote inspection by the client or an auditor they mandate. We will accommodate one such audit in any twelve-month period on thirty days' notice, at a mutually convenient time, subject to the auditor being bound by confidentiality and to the audit not compromising the confidentiality of other clients' information. Where a competent supervisory authority requires an audit, or where an audit follows a personal data breach affecting the client, the twelve-month limit and the notice period do not apply.

We reserve the right to charge for time spent supporting an inspection that goes materially beyond a routine assessment, and we will agree any such charge in advance rather than presenting it afterwards.

22. Return and deletion at engagement end

At the end of an engagement, the client chooses whether we return their personal data or delete it. In the absence of a choice, we delete.

22.1 Timing

We complete return or deletion within thirty days of the end of the engagement, or within thirty days of the client's instruction if that comes later. If a client asks us to hold material for a defined period after the engagement — for example while an internal review runs — we do so only on written instruction stating the period, and delete at the end of it.

22.2 What deletion means

Deletion means the removal of the material from working storage, from any working copies made during the engagement, and from backups on the backup rotation schedule. Where an item persists in an encrypted backup that cannot be selectively edited, we isolate it from any further processing and confirm the date by which the backup itself expires. We describe this rather than claiming instantaneous erasure everywhere, because instantaneous erasure everywhere is not how backup systems work and claiming it would be untrue.

22.3 What we keep

We retain the minimum record necessary to evidence what was done: the statement of work, the findings report as delivered, correspondence about the engagement, and our own experiment records stripped of client personal data and confidential material. We keep these under section 28 for the reasons stated there — statutory accounting obligations, limitation periods, and professional indemnity requirements. They are controller data, not client data, and are retained under Articles 6(1)(c) and 6(1)(f).

22.4 Confirmation

We provide a written confirmation of deletion or return, identifying what was covered and the date completed, signed by a director. Clients regularly need this for their own records and we provide it without being asked.

23. Confidential materials and non-disclosure

Research engagements involve receiving material that matters commercially and would damage the client if it escaped: unpublished designs, measurement data, process detail, source code, cost models, and the fact of the research itself. Much of this is not personal data at all, but the handling obligations run alongside our data protection obligations and we set them out here because clients assess both at once.

23.1 The obligation

Material provided to us for an engagement is confidential whether or not it is marked confidential and whether or not a non-disclosure agreement is in place. We use it only to perform the engagement, disclose it only to the people working on that engagement, and do not disclose it to any third party without written authorisation, save where disclosure is compelled by law — in which case we tell the client first if we lawfully can, and disclose only what is required.

23.2 Non-disclosure agreements

We will sign a client's non-disclosure agreement where they have one, and we have our own where they do not. We do not treat an NDA as a substitute for the handling controls described in section 17.9; the controls apply regardless.

23.3 Our people

Everyone with access to engagement material is bound by written confidentiality obligations that survive the end of their engagement with the lab. Access is granted by name for the duration of the work and removed at the end of it.

23.4 The fact of the engagement

We treat the existence of an engagement as confidential unless the client agrees otherwise. We do not name clients on this site, in proposals to other organisations, or in conversation, without written permission. If a client is content to be named, that is their decision to make and to revoke.

23.5 Segregation between clients

Engagement material is kept separate by engagement. We do not pool client datasets, do not use one client's material to answer another's question, and do not carry across anything beyond the general professional skill and know-how that any practitioner acquires from doing work of this kind. Where two engagements would create a conflict of interest, we disclose it and decline one of them.

24. Anonymised and synthetic data in experiments

Our strong preference is to answer research questions without holding identifiable personal data at all. Three routes are available and we consider them in this order at scoping.

24.1 Synthetic data

For many technical questions — how an algorithm scales, whether a filter recovers a signal, where a surrogate model's error changes a decision — the data only needs to have the right statistical and structural properties, not to be about real people. Synthetic data generated to match the shape of the real thing answers the question and carries no data protection risk. Where synthetic data is generated from a real dataset, we treat the generation process itself as processing of the real dataset and apply the same controls to it, and we assess whether the synthetic output could permit re-identification before it leaves the controlled environment.

24.2 Anonymised data

Data that has been anonymised so that individuals are no longer identifiable, taking account of all means reasonably likely to be used, is not personal data and falls outside the UK GDPR. We treat this threshold seriously rather than as a labelling exercise: removing names from a dataset with rich behavioural detail does not anonymise it. Where a client says data is anonymised, we assess that claim before relying on it, and if we consider the data still identifiable we say so and treat it as personal data.

24.3 Pseudonymised data

Pseudonymised data remains personal data under Article 4(5) because a key exists that can restore identification. Where an engagement uses pseudonymised data, the client keeps the key, we never receive it, and that arrangement is recorded in the engagement documentation. This reduces risk substantially without pretending to eliminate it.

24.4 Data minimisation in research design

Where identifiable data genuinely is required, we ask for the narrowest slice that answers the question: fewer fields, a sample rather than a population, a shorter time window, and coarsened values where precision is not needed. Research designed around a smaller dataset is usually a better research design in any case, because it forces the question to be stated precisely.

25. Publication, intellectual property and research outputs

Research produces outputs, and outputs raise questions about who owns them and who may talk about them. Our position is set out in full in our terms and summarised here because it affects what happens to data.

25.1 Publication of client work

We do not publish anything arising from a client engagement — findings, methods, figures, the existence of the work — without the client's written agreement to the specific wording. There is no implied right to publish and no "unless you object" default.

25.2 Publication of internal research

Our own internal lines of enquiry, including the entries in our public ledger, are ours to publish. Before anything is published we check that it contains nothing confidential to a client, nothing that could identify a client, and no personal data. Internal research is conducted on synthetic, public or self-generated data precisely so that this check is straightforward.

25.3 Background and foreground intellectual property

Background intellectual property — what each party brings to an engagement, including our internal tooling, harnesses, libraries and methods, and the client's existing systems, data and designs — remains with the party that brought it. Foreground intellectual property created specifically for the client during the engagement is assigned to the client on payment, subject to a licence back to us to continue using our own tooling and the general know-how that any competent practitioner carries away.

Where an engagement would require us to assign or exclusively license background IP, we say so before the engagement starts. We will not agree terms that would prevent us from continuing our own internal research lines.

25.4 Personal data is never an output we own

Whatever the IP position, personal data supplied by a client is not an asset we acquire. It is processed for the engagement and returned or deleted at the end of it. A transfer of intellectual property in a deliverable does not transfer any right in personal data to us, and the deletion obligation in section 22 applies regardless of who owns the code.

25.5 Models trained on client data

Where an engagement produces a trained model, that model is a deliverable belonging to the client under section 25.3, and we do not retain a copy for our own use beyond the retention permitted in section 22.3. We do not train models retained by us on client data. Where a model could memorise personal data from its training set, we raise that risk explicitly in the findings report, because it affects what the client can safely do with the model afterwards.

26. Secure deletion and media handling

Deletion is a technical operation and deserves a technical description rather than an assurance.

26.1 Working storage

Engagement material held in cloud object storage or on a managed volume is deleted through the provider's delete operation, and where the storage is encrypted at rest with a key we control, we additionally destroy the key so that any residual ciphertext is unrecoverable. Where a dedicated encrypted volume was created for an engagement under section 17.9, the volume is destroyed in its entirety.

26.2 Local devices

Working copies on lab machines are held on full-disk-encrypted storage and removed at the end of the engagement. Devices used for research work are encrypted, are not shared with anyone outside the lab, and are wiped cryptographically before disposal or re-use. We do not permit engagement material on personal devices.

26.3 Backups

Backups are encrypted and expire on a defined rotation. Where an item has been deleted from working storage but persists in a backup until that backup expires, it is not restored into use and is not processed further; we tell the client the date on which the last backup containing it expires. We consider it more honest to describe this than to claim erasure from immutable backups.

26.4 Physical media

Where a client supplies material on physical media, that medium is returned to the client or destroyed at their choice, and we confirm which in writing. Printed material is avoided; where it exists, it is cross-cut shredded.

26.5 Confirmation and record

We keep a record of what was deleted and when, and provide the written confirmation described at section 22.4. The record of deletion is retained even after the data is gone, because being able to evidence deletion is part of accountability under Article 5(2).

27. International transfers

Our default is to keep personal data in the United Kingdom. Some processing nonetheless involves a transfer outside the UK, and Chapter V of the UK GDPR governs when that is permitted.

27.1 Adequacy

Transfers to countries covered by UK adequacy regulations may take place without additional safeguards. That currently includes the European Economic Area and the other jurisdictions specified in regulations made under section 17A of the DPA 2018, together with the UK Extension to the EU–US Data Privacy Framework for US organisations that are certified to it. We check adequacy status at the point of a transfer rather than relying on a list we wrote once.

27.2 The IDTA and the UK Addendum

Where no adequacy regulation applies, we rely on the International Data Transfer Agreement issued by the ICO under section 119A of the DPA 2018, or on the UK Addendum to the European Commission's Standard Contractual Clauses where the counterparty's paperwork is built on the EU clauses. Both are Article 46 safeguards. Our suppliers' data processing addenda incorporate one or the other, and we check which before relying on it.

27.3 Transfer risk assessments

Article 46 safeguards are not sufficient on their own. Before relying on the IDTA or the UK Addendum we carry out a transfer risk assessment considering the destination country's laws on government access to data, the practical likelihood of such access given the nature of the data, the technical measures applied — encryption in transit and at rest, and the location of decryption keys — and whether the recipient has a record of challenging unlawful requests. Where the assessment concludes that the safeguards would not be effective in practice, we do not make the transfer.

27.4 Transfers in research engagements

Where we act as a processor, we make no transfer of client personal data outside the United Kingdom except on the client's documented instructions. Where an engagement requires compute capacity in a specific region, we agree the region in writing before any data moves, and default to a UK region where one is available.

27.5 Support access

Some suppliers provide technical support from outside the UK, which can constitute a transfer even where the data is stored in the UK. Where we know this to be the case we say so in the sub-processor table at section 18, and we rely on the transfer mechanism in that supplier's addendum together with our own assessment of it.

Copies of the transfer mechanisms we rely on are available on request from research@volunos.uk, redacted only where a supplier's commercial terms require it.

28. Retention

We keep personal data only for as long as we need it for the purpose we collected it for, or for as long as the law requires. The table gives the period for each category and the reason for it — a period without a reason is arbitrary, and an arbitrary period is not a retention policy.

At the end of a retention period, records are deleted using the methods described in section 26. Where a record is subject to a legal hold — an actual or anticipated claim, a regulatory enquiry, or a court order — it is retained until the hold is lifted, and the hold is documented with a reason and a review date.

29. Security measures

Article 32 requires appropriate technical and organisational measures, judged against the risk. This section states what we actually do, and — equally importantly — what we do not have. A supplier assessment answered aspirationally is worse than useless to the organisation relying on it.

29.1 What we do not hold

We do not hold ISO/IEC 27001 certification, a SOC 2 report, or Cyber Essentials or Cyber Essentials Plus certification, and we will not represent otherwise — not on this website, not in a proposal, not in a tender response, and not in answer to a security questionnaire. We are a new company and have not been through any of those assessments. If a certification becomes a requirement for work we want to do, we will obtain it and say so on the date it is granted, not before.

We also do not operate a security operations centre, do not have twenty-four hour monitoring, and do not have a dedicated security team. Those are honest limits of a lab of our size and clients should factor them into their own risk assessment.

29.2 Technical measures in place

• Transport encryption: HTTPS with TLS enforced site-wide, HTTP Strict Transport Security, and no mixed content.
• A restrictive Content Security Policy and the associated response headers — X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy — served on every response.
• A static website with no application server, no database and no third-party scripts beyond web fonts, which removes most of the attack surface a marketing site normally carries.
• Full-disk encryption on every device used for lab work, with automatic locking.
• Encryption at rest for engagement material held in cloud storage, with keys managed separately from the data.
• Multi-factor authentication on every account that can reach email, code, cloud infrastructure or the domain registrar, using authenticator applications or hardware keys rather than SMS wherever the provider allows it.
• A password manager with unique generated credentials; no shared credentials between people.
• Least-privilege access granted by name for the duration of a piece of work and removed at the end of it, with access to engagement material segregated by engagement.
• Encrypted, rotated backups with a defined expiry, and periodic restoration checks.
• Prompt application of operating system and dependency security updates, and dependency review before a new library enters a project.

29.3 Organisational measures in place

• Written confidentiality obligations for everyone with access to client material, surviving the end of their engagement with us.
• A documented incident response procedure with named responsibilities, a defined assessment step and the notification timings set out in section 30.
• A record of processing activities maintained under Article 30, and this notice maintained as its public expression.
• Data protection considered at the design stage of every engagement, with the minimisation questions at section 24 asked before data is requested.
• A supplier assessment before a new sub-processor is engaged, covering its security posture, its transfer mechanism and its own sub-processing.
• Regular review of access, at least at the end of every engagement and at least twice a year in any case.

29.4 Residual risk

No set of measures eliminates risk. Email in particular is not a confidential channel; we ask that sensitive material is not sent by ordinary email and will agree a better route on request. Where a client's own assessment concludes that our controls are insufficient for a particular dataset, the right answer is usually to change the research design — synthetic data, a smaller sample, or processing on the client's infrastructure — and we will propose that rather than argue about the assessment.

30. Personal data breaches

A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That includes losing a device, sending material to the wrong recipient, and a supplier being compromised — not only a deliberate attack on us.

30.1 Our procedure

On becoming aware of a suspected breach we contain it, record the time we became aware, and assess it: what data, whose data, how many people, what harm could follow, and whether the data was rendered unintelligible by encryption. The assessment is documented with the reasoning, whatever the conclusion.

30.2 Where we are the controller

Where the breach affects personal data for which we are the controller, and it is likely to result in a risk to the rights and freedoms of individuals, we notify the ICO without undue delay and, where feasible, not later than seventy-two hours after becoming aware of it, as Article 33(1) requires. Where notification is later than seventy-two hours, we give the reasons for the delay. Where the risk is high, we also communicate the breach to the affected individuals without undue delay under Article 34, in clear and plain language, describing the likely consequences and the measures taken or proposed.

Where we conclude that a breach is unlikely to result in a risk and therefore does not require notification, we record that conclusion and the reasons for it. Every breach, notifiable or not, is entered in our breach register under Article 33(5) and kept for the period stated in section 28.

30.3 Where we are the processor

Where the breach affects personal data we process for a client, we notify that client without undue delay and in any event within twenty-four hours of becoming aware. The notification describes the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures we have taken or propose, and a point of contact. We provide further information as the investigation proceeds. The seventy-two hour clock for notifying the ICO belongs to the client as controller, and our twenty-four hour commitment exists so that they can meet it.

30.4 After the event

Every breach is reviewed for cause, and the corrective action is recorded and tracked to completion. Where a supplier caused it, we reassess the supplier and, where appropriate, replace it under the change process in section 18.

To report a suspected breach or a vulnerability in this website or in anything we operate, write to research@volunos.uk. We will acknowledge within one working day. We will not pursue anyone who reports a genuine vulnerability to us in good faith and gives us a reasonable opportunity to fix it before disclosing it.

31. Your rights under the UK GDPR

These rights apply to personal data for which we are the controller. Where we hold data as a processor, section 16.2 explains how a request is handled. To exercise any right, write to research@volunos.uk marking the message Data protection request. We do not charge, we do not require a particular form of words, and we will not ask for identification beyond what is necessary to be satisfied that the request is genuinely yours. We respond within one month of receipt, extendable by two further months for complex or numerous requests, in which case we will tell you within the first month and explain why.

31.1 The right to be informed

You have the right to know what we do with your personal data, which is what this notice is for. Where we obtain personal data from a source other than you, Article 14 requires us to tell you within a month, or at first communication, unless an exemption applies. In practice we obtain personal data almost exclusively from the people it concerns.

31.2 The right of access

Under Article 15 you may ask whether we process personal data about you and, if so, receive a copy of it together with the supplementary information Article 15(1) specifies: the purposes, the categories of data, the recipients, the retention period, your rights, the source, and whether there is automated decision-making. We provide the copy in a commonly used electronic form unless you ask otherwise. Where a document contains other people's personal data, we will redact what is necessary to protect their rights rather than withhold the document entirely.

31.3 The right to rectification

Under Article 16 you may have inaccurate personal data corrected and incomplete data completed, including by providing a supplementary statement. Where a record is a contemporaneous note of what was said at the time, we will not rewrite history, but we will append your correction to it so that the file reflects both.

31.4 The right to erasure

Under Article 17 you may ask us to delete personal data where one of the grounds applies — the data is no longer necessary, consent is withdrawn and there is no other basis, you object and there is no overriding legitimate ground, or the processing is unlawful. The right is not absolute. We will refuse, and explain why, where we are required by law to keep the data — statutory accounting records in particular — or where it is necessary for the establishment, exercise or defence of legal claims. Where we refuse in part, we will delete everything not covered by the exemption.

31.5 The right to restrict processing

Under Article 18 you may ask us to limit what we do with your data while a dispute about its accuracy or about our legitimate interests is resolved, or instead of erasure where you need the data preserved for a legal claim. Restricted data is stored but not otherwise used, and we will tell you before a restriction is lifted.

31.6 The right to object

Under Article 21 you may object to processing based on legitimate interests. Where you do, we stop unless we can demonstrate compelling legitimate grounds that override your interests, rights and freedoms, or the processing is for legal claims. Your right to object to direct marketing is absolute: if we ever send you marketing and you object, we stop immediately and permanently, and we record the objection so it is honoured.

31.7 The right to data portability

Under Article 20, where processing is based on consent or on a contract and is carried out by automated means, you may receive the personal data you provided in a structured, commonly used and machine-readable format, and have it transmitted to another controller where technically feasible. In practice this would apply to account data if we operate an application; correspondence held under legitimate interests is outside the right, although we will usually provide it in a portable form anyway.

31.8 Rights in relation to automated decision-making

Under Article 22 you have the right not to be subject to a solely automated decision with legal or similarly significant effects. As section 15 explains, we take no such decisions. If that ever changed you would be told first and given the safeguards Article 22(3) requires.

31.9 The right to withdraw consent

Where processing is based on consent you may withdraw it at any time, as easily as you gave it, and we will stop that processing. Withdrawal does not affect the lawfulness of what was done before. At present the only processing we would base on consent is research updates by email, which we do not currently operate.

31.10 The right to complain

You may complain to the ICO at any time. Section 42 gives their details. You do not have to come to us first, although we would like the chance to put things right.

32. Cookies and similar technologies

Regulation 6 of PECR requires consent before storing information on, or gaining access to information stored on, a user's device, unless the storage or access is strictly necessary to provide a service the user has explicitly requested.

This website sets no analytics, advertising, personalisation or preference cookies, and writes nothing to local or session storage. The only cookie that may be set is a strictly necessary security cookie placed by Cloudflare in the course of protecting the site, which falls within the exemption at regulation 6(4) and therefore does not require consent. That is why you are not shown a consent banner: there is nothing to consent to, and a banner asking permission for nothing would be theatre.

Our cookie policy lists every cookie by name, purpose and duration, explains the exemption, sets out per-browser instructions for controlling cookies, and states our position on Do Not Track and Global Privacy Control signals. If we ever introduce a cookie that is not strictly necessary, we will ask for consent through a mechanism that makes refusing as easy as accepting, will not deploy the cookie before consent is given, and will update both documents before doing so.

33. Marketing and electronic communications

We do not send marketing email, do not make marketing calls, do not send marketing text messages, and do not run advertising campaigns that process personal data. We have no mailing list.

Regulation 22 of PECR prohibits unsolicited electronic marketing to individual subscribers without consent, subject to the limited "soft opt-in" for existing customers of similar products. We do not use the soft opt-in. Regulation 22 does not apply in the same way to corporate subscribers, but our practice does not distinguish: we do not send unsolicited marketing to business addresses either.

What we do send is correspondence — replies to enquiries, proposals that were asked for, updates during an engagement, and administrative messages about work in progress. These are service communications, not marketing, and are sent under Article 6(1)(b) or 6(1)(f) as described in sections 5 and 6.

If we ever introduce research updates by email, section 8 sets out how consent would work. If you receive anything from us that you consider to be marketing you did not ask for, tell us at research@volunos.uk and we will investigate it as a complaint.

34. Mobile applications — scope of this part

At the effective date of this notice, Volunos Labs has not published any mobile application on the Apple App Store, on Google Play or anywhere else. This part is written in advance so that our commitments are on the record before there is any commercial pressure to soften them, and so that a client or a store reviewer can see the position we intend to hold. Nothing in this part should be read as implying that an application exists.

Research engagements sometimes produce an application that belongs to the client and is published under the client's own developer account. In that case the client is the controller for everything the application does, their privacy notice governs it, and we are at most a processor under Part C. This part applies only to an application published by Volunos Labs Ltd under our own name.

If and when we publish an application, we will update this notice with the application's name and the date of publication, and the commitments below will apply from that date.

35. Application permissions

Our position on permissions is that an application should request the smallest set that lets it work, should request each one at the moment it is needed rather than at first launch, and should continue to function in a reduced form when a permission is refused. The table sets out how we would treat the permissions an application of ours might plausibly need, and confirms those we would not request at all.

Permissions can be reviewed and revoked at any time in the device settings on both iOS and Android, independently of anything the application offers, and revoking one takes effect immediately.

36. Analytics and crash reporting

Where an application of ours includes analytics or crash reporting, it will be limited to what is needed to keep the software working, and the position will be stated plainly in the store listing as well as here.

36.1 Crash and error reporting

A crash report typically contains a stack trace, the application version, the operating system version, the device model, the locale, and the state of the application at the moment of failure. It is technical diagnostic data and it is the only realistic way to fix a defect that occurs on a device we do not have. Our commitments: crash reports will not carry a persistent identifier that lets us follow a user between sessions, will not include the contents of user data, will be retained for no longer than ninety days, and will be used only to diagnose and fix defects.

36.2 Product analytics

We do not consider general behavioural analytics necessary for the kind of application we would publish, and our default is not to include it. If we introduced usage analytics, it would be aggregate and event-based rather than user-journey tracking, it would be off by default and enabled only with consent, and turning it off would be a single control in the application's settings rather than a buried preference.

36.3 No advertising or attribution SDKs

We will not embed advertising software development kits, attribution or install-tracking SDKs, social media SDKs that collect data in the background, or session-replay tools. This is a design commitment, not a current-configuration statement: an application of ours will not ship with them.

36.4 Lawful basis

Crash reporting rests on Article 6(1)(f), our legitimate interest in the software working correctly, balanced by the minimisation commitments above. Any optional analytics would rest on Article 6(1)(a), consent, and on the equivalent consent requirement for storing or accessing information on a device.

37. Identifiers and App Tracking Transparency

37.1 Identifiers we would use

Where an application needs to recognise its own installation between launches — to keep a session, to hold a preference, to route a push notification — it uses an identifier scoped to that installation and generated by the application or the platform. On iOS that is the vendor identifier or an application-generated value; on Android it is an application-scoped installation identifier. These are reset when the application is deleted and reinstalled, and are not shared with anyone.

37.2 Identifiers we would not use

We will not request or use the Identifier for Advertisers on iOS or the Advertising ID on Android. We will not use device fingerprinting, will not derive an identifier from hardware characteristics, and will not attempt to link an installation to a person across applications or websites.

37.3 App Tracking Transparency

Apple's App Tracking Transparency framework requires an application to obtain permission before tracking a user across applications and websites owned by other companies. Because we do not track, an application of ours would have no reason to present the App Tracking Transparency prompt, and we would not present it. Our App Store privacy labels would declare that no data is used to track users, and any data collected — crash diagnostics — would be declared as not linked to the user's identity.

37.4 Consistency

Store privacy declarations and this notice must say the same thing. If we ever changed the behaviour of an application, we would update the store declarations and this notice before the change shipped, not afterwards.

38. Google Play Data Safety consistency

Google Play requires a Data Safety declaration covering what data an application collects and shares, whether it is encrypted in transit, whether the user can request deletion, and whether data collection is optional. Google requires the declaration to be accurate and consistent with the application's privacy policy, and treats inconsistency as a policy violation.

Our commitment is straightforward: the Data Safety declaration for any application we publish will match this notice line for line. Specifically, and subject to the actual functionality of the application when it exists, we would expect to declare that data is encrypted in transit; that the user can request deletion of their data by the routes described in section 40; that no data is shared with third parties for advertising or analytics purposes; that no data is used to track users across applications or websites; and that any optional collection is genuinely optional and refusable without loss of core functionality.

Where the two documents could be read differently, this notice governs our actual practice and we will correct the declaration. If you find an inconsistency between a store listing of ours and this notice, tell us at research@volunos.uk and we will fix it and say what we fixed.

39. Subscriptions billed by app stores

If an application of ours offers a paid subscription, and that subscription is sold through the Apple App Store or Google Play, the payment is processed by Apple or Google and not by us. We never receive your card number, bank details or full billing address. What we receive from the store is a transaction identifier, the product purchased, the subscription status and its renewal or expiry date, and the country of the store account — enough to know whether an account is entitled to a paid feature.

The store operator is a separate controller for the payment itself and their own privacy policy governs it. Apple's and Google's terms also govern how a subscription is cancelled, and cancellation is done in the store account settings rather than by us; we cannot cancel a store-billed subscription on your behalf, although we can and will tell you exactly where to do it.

Refunds for store-billed purchases are handled by the store operator under its refund policy. Where you have a statutory right to a refund under UK consumer law, that right is unaffected by the store's policy, and our terms set out the position on the fourteen-day cancellation right for digital content and the waiver that applies where supply begins immediately.

Deleting your account with us does not cancel a store-billed subscription. Cancel the subscription in the store first, or you may continue to be charged by the store for a service you can no longer use. We say this prominently because it is the single most common way people lose money on application subscriptions.

40. Account and data deletion

Both major application stores require a published, in-application route to account deletion, and Article 17 of the UK GDPR gives you the right to erasure independently of any store rule. Our commitments below apply to any account service we operate.

40.1 In-application route

Where an application of ours supports accounts, account deletion is available inside the application at Settings → Account → Delete account. The route requires no email, no telephone call, no live chat and no explanation. It presents a plain statement of what will be deleted and what will be retained, requires one confirmation to guard against accidental taps, and then proceeds.

40.2 Email route

You may instead write to research@volunos.uk from the address associated with the account, or from another address if you tell us which account you mean, asking for deletion. We will verify the request proportionately — usually by replying to the account address — and then proceed. We do not require a form, a reason, or a conversation with anyone about staying.

40.3 The thirty-day commitment

We complete deletion within thirty days of a verified request and confirm in writing when it is done. In practice, live systems are cleared within a small number of days; the thirty-day window exists to cover backup rotation, which is the honest limiting factor. Backups containing deleted data are not restored into use and expire on their normal schedule.

40.4 What is deleted

Your account identifier and credential, your display name and settings, the content you created in the application, and any usage or diagnostic record linked to your account.

40.5 What is retained, and why

Records of transactions we are required to keep for accounting and tax purposes, retained under section 28 and reduced to the minimum needed for that purpose. Records necessary for the establishment, exercise or defence of legal claims, where any are live at the time. Suppression records showing that an address asked not to be contacted, kept so that the objection is honoured. Fully anonymised aggregate counts that cannot be linked back to you, which are no longer personal data.

40.6 Cancel the subscription too

As section 39 explains, deleting an account does not cancel a subscription billed by an application store. Cancel that in the store account settings, ideally before requesting deletion.

41. Changes to this notice

This is version 1.0, effective 5 August 2026. It is the first version and supersedes nothing.

We will update this notice when what we do changes — a new sub-processor, a published application, a new category of processing, a change of lawful basis — and when the law changes in a way that affects it. Every version carries an effective date and a version number at the top of the page, and the section that changed is identifiable from the version note we will add from version 1.1 onwards.

Where a change materially affects how we handle personal data for which we are the controller, we will take reasonable steps to bring it to the attention of the people affected before it takes effect: by email where we hold an address and the change concerns them, by notice in an application where one exists, and by prominent notice on this page in every case. Where a change would require consent, we will ask for consent afresh rather than treating continued use as agreement.

Where we act as a processor, changes to our processing are governed by the change control provisions of the relevant engagement documentation and the sub-processor notice period at section 18.1, not by an update to this page.

42. Complaints and the Information Commissioner's Office

If you are unhappy with how we have handled your personal data, tell us first if you are willing to: write to research@volunos.uk marking the message Complaint. We acknowledge within five working days and give a substantive response within twenty working days, or explain why we need longer and when you will hear from us.

You have the right to complain to the Information Commissioner's Office, the UK's supervisory authority for data protection, whether or not you have come to us first.

Information Commissioner's Office
Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF
Telephone: 0303 123 1113
Website: ico.org.uk

You also have the right to an effective judicial remedy under Article 79 of the UK GDPR, and the right to compensation under Article 82 where you have suffered damage as a result of an infringement. Nothing in this notice limits either.

43. How to contact us

All privacy correspondence goes to one address, which is read by the company's directors.

Volunos Labs Ltd
Email: research@volunos.uk
Registered office: City East, 72 Newtownards Road, Belfast, Northern Ireland, BT4 1GW
Company number: NI741243, registered in Northern Ireland
Incorporated: 7 June 2026

Please mark data protection requests Data protection request and complaints Complaint in the subject line, which helps us meet the deadlines set out above. If you need this notice in another format, ask and we will provide it.