Privacy notice

Part 01

Who we are

Role: controller

"We" means VIVAN LABS LTD. "You" means any individual whose personal data we handle. The contact point for everything in this notice is [email protected], with PRIVACY at the start of the subject line.

We are not required to appoint a statutory Data Protection Officer under Article 37 of the UK GDPR, because our core activities do not consist of large scale regular and systematic monitoring, and we do not process special category data at scale as a controller. We have not appointed one voluntarily. As a UK established company we need no Article 27 representative. Responsibility sits with the company's officers, whose details are on the public Companies House register against company number 17061582.

Back to contents

Part 02

Controller and processor

Role: both, explained

A controller decides why and how personal data is processed. A processor acts only on a controller's documented instructions. We occupy both positions at different times, and confusing them is how supplier privacy notices mislead people.

2.1 We are a controller when

• You visit this website.
• You email us, or we email you, about an enquiry, proposal, contract or invoice.
• We hold contact details for people at client, prospect, supplier or adviser organisations.
• We keep accounting, tax and corporate records containing personal data.
• Somebody applies to work with us, makes a privacy request, or reports a security issue.

2.2 We are a processor when

• We work inside a client platform that contains personal data about the client's customers, staff or users.
• We build pipelines, models, tests or access controls operating on such data.
• We are given an extract, sample or masked copy for an agreed task.

Here the client is the controller. We do not decide what the data is for, do not use it for our own purposes and do not keep it beyond the engagement. If you are an individual whose data sits in a client platform, ask the organisation whose service you used. If you write to us anyway we will say so promptly, and where we can identify the controller we will pass the request on and tell you we have.

2.3 The Article 28 requirement

Before processing personal data for any client we require a written contract meeting Article 28(3): documented instructions only, confidentiality on anyone we authorise, Article 32 security, prior permission for sub-processors, assistance with data subject rights and with Articles 32 to 36, deletion or return at the end, and information sufficient to demonstrate compliance and permit audits. We do not begin without it and we do not accept a purchase order as a substitute.

Back to contents

Part 03

What this notice covers

Role: controller

The website at vivanlabs.co.uk, correspondence with us, our commercial relationships, and any application we may publish in future. Part 20 deals with applications and is explicit that none currently exists. It does not cover systems operated by other organisations, including any we have helped to build.

The short version: we do not sell personal data, do not share it for anyone else's marketing, run no advertising network, no analytics and no tracking on this website, set no cookies of our own, build no profiles and make no automated decisions about anybody.

Back to contents

Part 04

Data inventory: website visitors

Role: controller

This site is a set of static files. No database, no login, no comment system, no contact form, no accounts. What follows happens because a server cannot answer a browser without receiving a request from it.

There is no web analytics on this site: no Google Analytics, Plausible, Matomo, Fathom or self hosted equivalent. We do not know how many people read this page, and not knowing is a price we accept.

Back to contents

Part 05

Data inventory: correspondence

Role: controller

If you email us we hold what you sent and what we replied. There is no customer relationship system behind the inbox, no lead scoring and no enrichment service adding third party information about you.

Please do not send live data, credentials, access keys or other people's personal data in an unsolicited email. If we receive such material we will tell you, will not use it beyond identifying what it is, and will delete it.

Back to contents

Part 06

Data inventory: clients and suppliers

Role: controller

Where the basis is legitimate interests we have carried out a balancing assessment for each purpose. In every case the data is business contact information used in a professional context, the individual would reasonably expect the processing, and the impact is minimal. Ask and we will give you the reasoning in writing.

Back to contents

Part 07

Special category and criminal offence data

Role: both, explained

As a controller we do not seek or knowingly hold Article 9 special category data, and we do not process Article 10 criminal offence data. Nothing on this website or in our commercial records asks for either. If you volunteer such information in an email we hold it only as an inseparable part of that correspondence and use it for nothing.

As a processor, a client platform may well contain special category data, health records and trade union membership being routine examples. Where it does, the Article 28 contract identifies the categories before work starts, we apply the controls in Part 16, and we work against masked or synthetic data wherever the task allows. The lawful basis and any Schedule 1 condition belong to the client as controller.

Back to contents

Part 08

Where the data comes from

Role: controller

• Directly from you, when you email, contract, invoice or apply.
• Automatically from your device, as described in Part 04.
• From your employer or colleagues, where a client tells us who our contact will be.
• From Companies House, when verifying that an organisation we are contracting with exists.

We buy no contact lists, use no enrichment or intent data services and scrape no professional networks. If you have never had contact with us and receive an email from us, something has gone wrong and we want to know.

Back to contents

Part 09

Data we process for clients

Role: processor

This part describes processing where a client is the controller and we are the processor. It creates no right against VIVAN LABS LTD for the individuals concerned; their rights sit against the client.

The work consists of writing extraction and loading code, defining transformation models, writing tests that inspect data for correctness, configuring orchestration and access controls, and investigating defects. Personal data is encountered incidentally rather than being the object of the work. We are not analysing individuals; we are checking that a pipeline moves rows correctly.

9.1 Controls we place on ourselves

• Read only by default. Write access to production is requested per task, with a stated reason and expiry, and recorded.
• Synthetic and masked data first. Unmasked production personal data is accessed only where the task cannot otherwise be completed, under a specific written instruction.
• No local copies without instruction. Nothing is extracted to our own devices or storage unless the instruction permits it and names a deletion point.
• Client tenancy. What we build runs in the client's cloud account. We operate no shared multi-tenant environment through which client data flows.
• Deletion at the end. On completion we delete or return all client personal data at the client's election and confirm in writing.
• Assistance with data subject requests and with Articles 32 to 36, as Article 28(3)(e) and (f) require.

Back to contents

Part 10

Sub-processors and recipients

Role: both, explained

Third parties that may handle personal data on our behalf, each engaged under a written contract meeting Article 28. The list is short because the company deliberately runs on very little.

We will not add a sub-processor handling client personal data without notifying the client in advance and allowing a genuine objection, per Article 28(2). Where a client objects and no workable alternative exists, they may terminate the affected part of the engagement without penalty.

Separately, we may disclose personal data to our professional advisers, insurers, a court, the ICO or a law enforcement body where legally required or where necessary for legal claims. We have received no such request to date.

Back to contents

Part 11

International transfers

Role: both, explained

Our default is that personal data stays in the United Kingdom or the European Economic Area. Some does not, because some services any company depends on are operated from the United States. Each route is lawful as follows.

11.1 UK adequacy

Where data goes to a country covered by UK adequacy regulations, no additional safeguard is needed. That includes the EEA states, covered by the adequacy regulations preserved after the United Kingdom left the European Union. Such transfers rely on Article 45 of the UK GDPR.

11.2 The IDTA

For a direct arrangement with a recipient in a country without adequacy, we use the International Data Transfer Agreement issued by the Information Commissioner under section 119A of the Data Protection Act 2018 and laid before Parliament in 2022. It is a standalone UK contract and it is what we prefer when negotiating directly.

11.3 The UK Addendum to the EU SCCs

Most large providers publish a data processing addendum built on the European Commission's 2021 standard contractual clauses with the ICO's International Data Transfer Addendum attached to extend them to UK transfers. Where that is what a provider offers we accept it. It is the route that applies to Cloudflare in Part 10.

11.4 Transfer risk assessment

A contract alone is not enough. Before relying on the IDTA or the UK Addendum we assess whether the law and practice of the destination would undermine the protection promised, considering sensitivity, volume, the likelihood of government access requests and the technical measures in place. For the transfers here the data is connection metadata and business correspondence, encrypted in transit and at rest, at low volume. We consider the residual risk acceptable and will reassess if that changes.

11.5 When we are a processor

The transfer decision belongs to the client. We do not move client personal data out of the client's chosen region without a written instruction, and where a client's own tooling would cause such a transfer we raise it before work begins.

11.6 Seeing the safeguards

Article 46(1) entitles you to a copy of the safeguards relied on. Ask and we will provide the relevant clauses, with irrelevant commercial terms redacted.

Back to contents

Part 12

How long we keep things

Role: controller

Storage limitation under Article 5(1)(e) means keeping data no longer than necessary. A schedule without a reason attached is a guess, so each row carries the reason it is that length.

Backups are a real exception and we would rather state it than hide it. Data deleted from a live system may persist in an encrypted backup until that backup rotates out. During that window it is not restored, accessed or used.

Back to contents

Part 13

Your rights under the UK GDPR

Role: controller

These apply where we are the controller. Where we act as a processor, direct the request to the client, as Part 09 explains.

13.1 The right to be informed, Articles 13 and 14

You are entitled to know who processes your data, why, on what basis, who receives it, how long it is kept and what rights you have. This notice discharges that duty. If anything is unclear, ask.

13.2 The right of access, Article 15

You can ask whether we hold personal data about you and receive a copy with the supplementary information in Article 15(1), supplied electronically unless you ask otherwise. Where a record contains information about somebody else we redact that part rather than withholding the record. No fee applies unless the request is manifestly unfounded or excessive.

13.3 The right to rectification, Article 16

Inaccurate data can be corrected and incomplete data completed, including by a supplementary statement. Where we have disclosed data to a recipient, Article 19 requires us to tell them of the correction unless that proves impossible or disproportionate, and we will name those recipients if you ask.

13.4 The right to erasure, Article 17

Narrower than its nickname suggests. It applies where the data is no longer necessary, where consent is withdrawn with no other basis, where you object under Article 21(1) with no overriding ground, where processing was unlawful, or where erasure is legally required. It does not apply where we must keep data for a legal obligation such as the statutory accounting retention in Part 12, or for a legal claim. If we cannot erase everything, we erase what we can and tell you exactly what remains and under which exemption.

13.5 The right to restrict processing, Article 18

You can require us to pause while a dispute is resolved: while we verify accuracy you have contested, while we assess an objection, instead of erasure where processing was unlawful but you want the data preserved, or where we no longer need it but you need it for a claim. Restricted data is stored and not otherwise used, and we tell you before any restriction is lifted.

13.6 The right to data portability, Article 20

Where processing rests on consent or contract and is automated, you can receive the data you provided in a structured, commonly used, machine readable format and have it transmitted to another controller where technically feasible. Here that normally means your correspondence, supplied as plain text or standard email files.

13.7 The right to object, Article 21

Where we rely on legitimate interests you may object on grounds relating to your particular situation. We must stop unless we can demonstrate compelling legitimate grounds overriding your interests, or the processing is for legal claims. For direct marketing there is no balancing test and we must stop immediately. We carry out no direct marketing, and the right applies regardless.

13.8 Rights on automated decisions, Article 22

You have the right not to be subject to a decision based solely on automated processing producing legal or similarly significant effects. We make no such decisions, per Part 18. If that changed we would tell you first, explain the logic and provide human intervention.

13.9 The right to withdraw consent, Article 7(3)

Where we rely on consent you may withdraw it at any time, as easily as it was given, without affecting the lawfulness of what preceded it. We rely on consent for nothing in this notice, so there is nothing to withdraw.

13.10 The right to complain, Article 77

You can complain to the ICO at any time, per Part 15. You need not come to us first, and doing so stops no clock.

Back to contents

Part 14

How to exercise a right

Role: controller

14.1 Making the request

Email [email protected] with PRIVACY at the start of the subject line. No form, no article citation and no particular wording is needed. A request is valid if it is clear you are exercising a right, whether it arrives by email or by post to the registered office.

14.2 Identity verification

We must be satisfied you are who you say you are, because disclosing data to an impostor is itself a breach. Writing from an address already in our records is usually enough. Otherwise we ask for something proportionate that connects you to the data, and we ask for the least intrusive thing that will do. We will not demand a passport to release an email thread. Identity material is deleted once identity is established and within 30 days at most. Under Article 12(3) the clock starts when we have what we reasonably need, and we ask without delay rather than sitting on the request.

14.3 Requests made on your behalf

A solicitor, relative or other representative may request for you. We ask for evidence of authority, normally a signed authority or power of attorney. We usually respond to the representative, but may respond to you directly where that is safer.

14.4 Timing

We acknowledge promptly and respond without undue delay and within one month under Article 12(3). The month runs from the day after receipt to the corresponding date in the next month. Where a request is complex or one of several, we may extend by up to two further months, telling you within the first month and explaining why. We do not use the extension routinely.

14.5 What the response contains

A plain statement of what we did, the data or information requested, the reasoning for anything withheld or redacted, and a reminder of your right to complain to the ICO and to seek a judicial remedy.

14.6 When we can refuse

We may refuse or charge a reasonable fee where a request is manifestly unfounded, for example made with no genuine intention of exercising the right or used to harass, or manifestly excessive, for example an identical repeat within a short period with no new circumstance. We may also withhold specific material under a Data Protection Act 2018 exemption such as legal professional privilege, or where disclosure would adversely affect another person's rights and freedoms.

Where we refuse we tell you within one month, identify the specific ground rather than merely asserting an exemption, and explain how to complain to the ICO and seek a judicial remedy. We will not refuse simply because answering is inconvenient.

Back to contents

Part 15

Complaining to the ICO

Role: controller

If you are unhappy with how we have handled your data or your request, we would like the chance to put it right, so please raise it at [email protected]. You are not obliged to. You may complain to the UK supervisory authority directly and at any time.

• Information Commissioner's Office
• Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF
• Telephone: 0303 123 1113
• Online: ico.org.uk/make-a-complaint

You also have the right under Article 79 to an effective judicial remedy and under Article 82 to compensation for material or non-material damage resulting from an infringement. Nothing here limits either.

Back to contents

Part 16

How we protect personal data

Role: both, explained

Article 32 requires measures appropriate to the risk. Ours are deliberately unglamorous, and where we do not do something we say so.

• Encryption in transit. HTTPS only, with HTTP Strict Transport Security. Administrative and client systems over encrypted connections only.
• Encryption at rest through full disk encryption on work devices and provider encryption in cloud storage.
• Multi-factor authentication on every account that supports it, phishing resistant factors preferred.
• Least privilege. Access to a client system is the minimum for the task, requested per task and revoked at the end.
• No shared logins. Every credential is attributable to one identity, so access can be traced and revoked with confidence.
• Separated client environments. Work happens inside each client's own tenancy. No shared environment carries client data.
• A static website, which removes injection, authentication bypass and session hijacking from the threat model entirely.
• Security response headers including a content security policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Strict-Transport-Security.
• Data minimisation as a control. The most reliable protection for a record is not holding it.

What we do not have. VIVAN LABS LTD holds no ISO 27001 certification, no SOC 2 Type I or Type II report and no Cyber Essentials or Cyber Essentials Plus certification. No external body has audited our security. If your procurement requires any of those, we do not currently meet it, and we would rather say so in the privacy notice than let you discover it in week three of an onboarding questionnaire.

Back to contents

Part 17

Personal data breaches

Role: both, explained

A personal data breach is a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. It is broader than a hack: a lost laptop and an email to the wrong recipient both qualify.

17.1 Containment and assessment

We contain first, then establish what data is involved, how many people are affected, the likely consequences and whether the data was encrypted or otherwise unintelligible. Every incident is recorded in an internal breach log under Article 33(5), notifiable or not, with the facts, effects and remedial action.

17.2 Notifying the ICO, Article 33, and the 72 hour threshold

Where we are the controller and the breach is likely to result in a risk to rights and freedoms, we notify the ICO without undue delay and, where feasible, not later than 72 hours after becoming aware of it. A later notification must give reasons for the delay, and ours will. The notification describes the nature of the breach, the categories and approximate numbers of individuals and records, the likely consequences, the measures taken or proposed, and a contact point. Where we lack all of that at the outset we notify within the deadline anyway and supply the rest in phases, as Article 33(4) permits. If we conclude a breach is unlikely to result in a risk we do not notify, and we record the reasoning so it can be checked.

17.3 Notifying you, Article 34

Where a breach is likely to result in a high risk to your rights and freedoms we tell you directly and without undue delay, in clear and plain language, describing the nature of the breach, a contact point, the likely consequences, what we are doing and what you can do to protect yourself. We will not delay telling you in order to finish an internal investigation. Communication is not required where the data was rendered unintelligible, where subsequent measures mean the high risk is no longer likely, or where individual contact would involve disproportionate effort, in which case we make a public communication instead.

17.4 When we are the processor, Article 33(2)

Where a breach occurs in data we process for a client we notify that client without undue delay, in practice within hours rather than days. The 72 hour duty to the ICO is theirs; our job is to give them the facts fast enough to meet it. We assist with the assessment, the notification and any communication to affected individuals, as Article 28(3)(f) requires.

Back to contents

Part 18

Automated decisions and profiling

Role: controller

We make no decisions about you by solely automated means and we do not profile you. There is no lead scoring, no risk scoring, no behavioural segmentation, no advertising audience building and no algorithmic filtering of correspondence beyond an ordinary spam filter. Every decision about whether to engage, quote or reply is made by a person.

We do not use personal data held as a controller to train machine learning models, ours or anyone else's, and we do not feed correspondence into third party generative services in a way that would allow retention or training. As a processor, any use of client data for model training would require an explicit written instruction from that client.

Back to contents

Part 19

Children

Role: controller

Our services are business to business. This website is not designed for or marketed to anyone under 18 and we do not knowingly collect children's personal data as a controller. If you believe a child has sent us personal data, tell us and we will delete it.

Where we act as a processor on a platform containing children's data, in education or health for example, the client remains controller and the additional protections that attract, including the ICO's Age Appropriate Design Code where it applies, are theirs to apply. We follow their instructions and apply the controls in Parts 09 and 16.

Back to contents

Part 20

Mobile applications and permissions

Role: controller

Read this first. VIVAN LABS LTD publishes no mobile application. There is no VIVAN LABS app on the Apple App Store, on Google Play or anywhere else. This part states, in advance, the position we bind ourselves to if we ever publish one, so the commitment is on the public record before the product exists rather than being written to fit it afterwards. Nothing here claims an application exists today.

20.1 Device permissions

Revoking a permission takes effect immediately and we will not nag you to restore it. If revocation genuinely breaks a feature, the app explains which feature and why, once.

20.2 App Tracking Transparency on iOS

Apple's framework requires permission before tracking a user across apps and websites owned by other companies or accessing the device advertising identifier. Our position is that we would not present the prompt at all, because we would not track. No cross app or cross site tracking, no access to the Identifier for Advertisers, no data broker relationships, no advertising software development kits, no attribution networks. An app that never asks is a stronger commitment than one that asks and promises to behave.

20.3 Google Play Data Safety

Any Data Safety declaration we file will match this notice exactly. If the two ever disagree, treat the Play declaration as authoritative for the app, tell us, and we will correct the discrepancy. On present intentions it would state: no data shared with third parties; collection limited to what an account and a support request require; encryption in transit; a route to request deletion; and no advertising or analytics identifiers. We will not file a declaration that is technically defensible but practically misleading. The same applies to the App Store privacy labels, including the Data Not Used to Track You category.

Back to contents

Part 21

Account and data deletion

Role: controller

This website has no accounts, so there is nothing here to delete other than correspondence. The commitments below apply to correspondence now and to any account based product we publish later.

21.1 The in-app route

Any account based product we publish will carry a deletion control inside the product, reachable from the account or settings area in no more than three steps, without contacting support and without a retention offer standing between you and the button.

21.2 The email route

You can always ask by email instead. Write to [email protected] with PRIVACY in the subject and say what you want deleted. This route works whether or not you still have access to an account, which matters if the device or credentials are lost.

21.3 Timing

We acknowledge promptly and complete deletion within 30 days. Where the request is also an Article 17 request, the one month period in Part 14 runs in parallel and we work to whichever is shorter. We confirm in writing when it is done.

21.4 What survives deletion, and why

• Accounting records, retained six years per Part 12. This is a statutory obligation and it overrides an erasure request. We keep the transaction record, not a profile.
• Breach records, where your data was involved in an incident recorded under Article 33(5).
• The request itself, as a minimal record of the fact and date, for three years, so we can demonstrate we honoured it.
• Data needed for a legal claim, retained for that purpose only and under restriction.
• Encrypted backups, which age out on their own rotation. Deleted data is not restored from them.

Anything not on that list is deleted. Where we are a processor, deletion is governed by the client's instruction and Article 28(3)(g), and we confirm completion to the client in writing.

Back to contents

Part 22

Marketing, cookies and PECR

Role: controller

We operate no mailing list, newsletter or marketing automation and we send no unsolicited commercial email. If we email you it is because you wrote to us, because we are working together, or because we are answering something you raised.

If we ever do send marketing it will comply with the Privacy and Electronic Communications Regulations 2003: consent where consent is required, the narrow soft opt-in only where it genuinely applies, a working unsubscribe in every message and identification of the sender. An objection under Article 21(2) is absolute and we would act on it immediately.

PECR regulation 6 requires consent before storing information on, or accessing information stored in, your device, except where strictly necessary for a service you requested. VIVAN LABS LTD sets no cookies on this website, which is why there is no consent banner. A banner asking permission for nothing would be theatre. The full picture, including what our infrastructure provider may set during a security event, is in the cookie notice.

Back to contents

Part 23

Changes to this notice

Role: controller

This is version 1.0, effective 7 August 2026, and the first version. We will update it when what we do changes, when a placeholder in it is resolved, or when the law changes. The version and effective date at the top always tell you which one you are reading.

Where a change materially affects how we use personal data we already hold, or introduces a new purpose, we will not rely on quietly republishing a page. We will tell affected people directly where we hold contact details, before the change takes effect. Superseded versions are kept so we can answer a question about what the notice said on a given date.

Back to contents

Part 24

Contact

Role: controller

For anything in this notice, including a request under Part 13, write to [email protected] with PRIVACY at the start of the subject line.

The company's officers and persons with significant control are on the public Companies House register against company number 17061582. We publish no individual names on this website, and that policy applies to this notice as much as to any other page.

Back to contents