Privacy notice

Part 01

Notation used in this dossier

Role: controller

The discipline this company sells is that a figure in a report can be walked backwards to the row that produced it. A privacy notice deserves the same treatment, so this one is laid out as a lineage dossier rather than as a page of assurances.

Every activity that touches personal data appears below as a numbered record. A record is a table with four stages, read left to right:

1. Entry point. The exact moment personal data arrives, and what causes it to arrive.
2. Handling. What is done to it between arrival and rest, including anything done by machinery rather than by a person.
3. Surviving output. What is left once the handling finishes. This is the thing a retention clock runs against.
4. Readership. Every party able to open that output, us included.

Under each record sit two annotations. Basis names the Article 6 condition relied on. Clock names how long the surviving output lasts and what starts the countdown. Where a stage is genuinely empty the cell says so, because an empty cell in a lineage graph is information and a missing column is a defect.

Back to contents

Part 02

The controller behind it

Role: controller

VIVAN LABS LTD holds the controller position for every record here unless the record states otherwise. The company sits on the register of England and Wales as a private limited company under number 17061582, and the officers accountable for it are listed against that number at Companies House.

One address carries all of this: [email protected]. Opening the subject line with PRIVACY routes a message straight to whoever is handling requests that week. Nothing beyond that word is needed to make a request valid, and a message that omits it still counts from the moment it lands.

2.1 Why no data protection officer is listed

Article 37 makes the appointment compulsory for public authorities, for controllers whose core activity is monitoring individuals on a large scale, and for controllers whose core activity is large scale handling of the Article 9 categories. Our core activity is data platform engineering for organisations, so none of the three conditions is met and no statutory appointment is owed. The company is established in the United Kingdom, which settles the Article 27 question about a representative as well.

Back to contents

Part 03

Controller here, processor there

Role: both, distinguished

Two words decide which half of this dossier applies to you. A controller settles what the data is for and how it will be handled. A processor executes somebody else's written instruction and settles nothing at all. This company occupies both seats, at different moments, and a supplier notice that blurs them is misleading whatever else it says.

3.1 The seat is ours when

• A browser asks this website for a page.
• Correspondence passes between you and our inbox, in either direction.
• We keep working contact details for people at organisations we sell to, buy from or take advice from.
• Ledgers, invoices and statutory filings carry a name in them.
• Somebody sends a privacy request, reports a security defect, or asks about working with us.

3.2 The seat belongs to a client when

• We are inside a warehouse, lakehouse or operational database that already holds the client's customer, staff or user data.
• We author extraction jobs, models, tests, access rules or deletion routines that operate over such data.
• A masked sample, a scoped extract or a restore of a client environment is handed to us for one agreed task.

In every case in section 3.2 the client decides and we execute. Should you write to us about data that sits inside somebody else's platform, we will tell you which organisation instructs us, forward the request where we are lawfully able to, and confirm to you that the forwarding happened. What we will not do is answer on the client's behalf, because that answer would not be ours to give.

3.3 The gate before any client row is touched

No personal data belonging to a client enters our working day before a written contract satisfying Article 28(3) is signed. That contract fixes documented instructions, a confidentiality duty on everyone we authorise, Article 32 measures, advance permission for any sub-processor, help with individual rights, help with Articles 32 to 36, deletion or return at the end, and enough visibility for the client to verify all of it. A purchase order is not a substitute and we have never treated one as such.

Back to contents

Part 04

Record 01: a request for a page

Role: controller

This website is a folder of static files behind a content delivery network. Nothing here logs in, nothing here submits, and there is no database underneath. What follows is the irreducible residue of one computer asking another computer for a document.

Basis. Article 6(1)(f). The legitimate interest is keeping a business website reachable and defending it from scraping, flooding and intrusion, which Recital 49 recognises directly. The processing is limited to what a web server cannot avoid receiving, so the balancing test lands comfortably.

Clock. Held on the provider's own rotation, measured in days rather than months. We take no copy, which means there is nothing on our side for a clock to run against.

Measurement is absent from this record on purpose. No analytics package runs here, of any brand or self hosted variety, so the readership figures for this page are unknown to us and will stay unknown.

Back to contents

Part 05

Record 02: a message in the inbox

Role: controller

Correspondence is the only route into this company, so the inbox is the busiest entry point in the dossier. Behind it there is a mailbox and a person, with no pipeline attached: nothing scores you, enriches you from a third party dataset, or moves you along a sequence.

Basis. Article 6(1)(b) once a conversation is genuinely about arranging work, since answering is a step taken at your request before any contract. Article 6(1)(f) for everything else, the interest being that a company reachable by email must be able to read and answer what arrives.

Clock. A conversation that never becomes work is removed twenty four months after the last message in the thread. A conversation that becomes work moves onto the engagement clock in Part 12.

Back to contents

Part 06

Record 03: a commercial relationship

Role: controller

Once an engagement starts, personal data appears in a second shape: the working details of the individuals on both sides, and the paperwork a limited company is obliged to produce. None of it is about you as a consumer; all of it is about you in your job.

Basis. Article 6(1)(b) where the individual is party to the contract. Article 6(1)(f) where the individual works for the organisation that is party to it, the interest being the ordinary conduct of a business relationship. Article 6(1)(c) for the books, which company and tax law require us to keep whatever anybody would prefer.

Clock. Set out in Part 12, and driven by the limitation and accounting periods rather than by our own preference.

Back to contents

Part 07

Record 04: a request made against this notice

Role: controller

Exercising a right generates personal data of its own. A dossier that omitted that would have a gap in it exactly where somebody was trying to hold us to account, so the meta record appears here alongside the others.

Basis. Article 6(1)(c), because Article 12 obliges a controller to act on requests and Article 5(2) obliges it to be able to show that it did. Security reports rest on Article 6(1)(f), the interest being a website that stays intact.

Clock. Identity documents go within thirty days of the check clearing. Request files and security reports are covered in Part 12.

Back to contents

Part 08

Classes refused at the entry point

Role: both, distinguished

Some classes of personal data are cheaper to keep out of a pipeline than to govern once inside it. As controller we seek none of the Article 9 special categories: health, biometrics processed to identify somebody, race or ethnicity, political opinion, religious or philosophical belief, trade union membership, sex life or sexual orientation, genetic data. Article 10 material about offences and convictions is likewise outside anything we do for ourselves.

If a message arrives carrying one of those classes anyway, usually as an unnecessary attachment, the correct handling is deletion followed by a note to the sender explaining why it was not kept.

As processor the position is different, because a client's warehouse may lawfully hold any of it. Where an engagement will reach such a table we say so before the work is priced, we expect the client to have completed a data protection impact assessment under Article 35, and we expect the Article 28 contract to name the class explicitly. Masked or synthetic material is used for development in preference to the real column wherever the task allows it, which in our experience is most of the time.

Back to contents

Part 09

Rows that belong to a client

Role: processor

Inside a client platform we are hands, not a head. The purposes are the client's, the retention rules are the client's, and the answer to a data subject is the client's to give. Our obligations still bite directly under Articles 28 to 33, and the following are the ones an individual would care about.

• We act on written instruction and record the instruction we acted on. An instruction that looks unlawful is queried in writing before anything runs, as Article 28(3)(h) requires.
• Client data is not reused. It never trains anything of ours, never seasons a demonstration and never leaves the client's environment except where the instruction says so.
• Credentials start read only and stay read only for as long as the task allows. Elevation is per task, reasoned and expiring.
• Development runs on synthetic fixtures or a masked sample. A real extract is taken only where the task cannot honestly be done without one, and it is destroyed when that task closes rather than at some vague later point.
• Where a client asks us to help answer somebody's access or erasure request, we trace which tables, models, extracts and downstream copies hold the individual, and we hand back that map. Tracing is the same skill the rest of this site describes, applied to a person instead of a figure.

If you believe a client platform holds your data and you cannot work out who to ask, write to us. We will identify the controller for you where we lawfully can, and stay out of the substance of your request.

Back to contents

Part 10

Downstream readership

Role: both, distinguished

Every reader named in the records above, collected into one table. The list is short because the company runs on very little, and each entry exists because something practical would stop working without it.

Nobody on that list pays us for access and nobody buys anything from us. Adding a new reader that would handle client personal data requires advance notice to the client and a real opportunity to object, per Article 28(2); where an objection cannot be resolved, the affected part of the engagement can be ended without a penalty attaching to it.

Back to contents

Part 11

Rows that cross a border

Role: both, distinguished

The default is that a row stays in the United Kingdom or the European Economic Area. Two of the readers in Part 10 are United States companies, so two routes out of the country exist and both are papered before anything travels, never afterwards.

11.1 Where adequacy already covers it

Transfers into the European Economic Area rely on the adequacy regulations preserved when the United Kingdom left the European Union, which is Article 45 in operation. Nothing further is owed for those.

11.2 Where a contract has to carry it

For a destination without adequacy we rely on one of two instruments. Negotiating directly, we prefer the International Data Transfer Agreement made under section 119A of the Data Protection Act 2018, because it is a self contained United Kingdom document. Where a large supplier instead publishes the European clauses with the Information Commissioner's addendum bolted on, that is accepted, and it is the route covering the hosting arrangement in Part 10.

11.3 The assessment behind the paperwork

Signing an instrument is the second step, not the first. Before relying on either one we assess whether law and practice at the destination would hollow out the protection promised, weighing how sensitive the data is, how much of it there is, how likely a state access demand would be, and what encryption sits around it. For these transfers the payload is connection metadata and business correspondence, encrypted on the wire and at rest, at low volume. The residual risk reads as acceptable and the assessment is revisited whenever the arrangement changes.

11.4 Client transfers are the client's decision

Acting as processor we move nothing across a border without an instruction. Where a client's chosen tooling would itself cause an international transfer, we flag it during scoping so the client can decide with the facts in front of them.

11.5 Asking to see the safeguard

Article 46(1) entitles you to a copy of the mechanism relied on for a transfer that concerns you. Ask and you will get the relevant clauses, with commercial terms that have nothing to do with your data taken out.

Back to contents

Part 12

The retention clock

Role: controller

Storage limitation under Article 5(1)(e) is a promise that something stops. A retention schedule with no reason beside each period is guesswork dressed as policy, so every line below carries the reason it runs that long and the event that starts it.

Backups. A deletion from a live mailbox or store does not instantly reach an encrypted backup image, and the honest description is that the row persists there until the image rotates out. Inside that window it is not restored, not opened and not used for anything. Saying this plainly is better than a promise of instantaneous erasure that no system with backups can keep.

Back to contents

Part 13

Rights you hold over a row

Role: controller

These bite where we hold the controller seat. Where Part 09 applies instead, the same rights exist but they point at the client. Each is stated below in the terms of this dossier: what it lets you do to a record.

• Be informed, Articles 13 and 14. Know that a record exists and how it runs. This document is that duty being discharged; anything unclear in it is a question worth sending.
• Access, Article 15. Get confirmation that we hold something about you and a copy of it, with the supplementary detail Article 15(1) lists. Where a document also concerns somebody else, the other person's part is masked and the rest still comes to you.
• Rectification, Article 16. Correct a field that is wrong, or complete one that stops short. We will pass the correction to any reader in Part 10 that received the original.
• Erasure, Article 17. Have a record dropped where there is no longer a reason for it to exist. Statutory books are the standing exception, and we will name the obligation rather than refuse in the abstract.
• Restriction, Article 18. Freeze a record instead of deleting it, which is the right move while accuracy or a legitimate interest is being argued about. A frozen record is stored and otherwise untouched.
• Portability, Article 20. Receive what you gave us as a machine readable export, where the handling rests on consent or contract and runs automatically. Ask and it can go straight to another controller instead.
• Object, Article 21. Tell us to stop processing that rests on legitimate interests. We stop unless there is a reason of ours that demonstrably outweighs yours, and if we think there is, you get the reasoning in writing rather than a bare refusal. Objecting to direct marketing is absolute, though Part 22 explains why there is nothing here to object to.
• Withdraw consent, Article 7(3). Available whenever consent was the basis, and as easy to do as giving it was. Withdrawal works forwards and does not unpick what was lawful before it.
• Human review, Article 22. Contest a decision reached by machine alone. Part 18 explains why no such decision is made here.

The full set is: access, rectification, erasure, restriction, portability, objection, and withdrawal of consent where consent applies.

Back to contents

Part 14

Filing a request, and the evidence

Role: controller

Send it to [email protected] with PRIVACY opening the subject line. No form exists, no template is required, and a request written in ordinary words is as valid as one citing article numbers.

14.1 What helps us find you

A lineage search needs a key. Tell us which addresses you have written from, roughly when, and which right you are exercising. If the request is narrow, say so; searching an inbox for one thread is quicker than assembling everything and gives you a more useful answer.

14.2 Proving who you are

Identity is checked only where genuine doubt exists, and proportionately. Writing from an address that already appears in the thread you are asking about usually settles it on its own. Where more is needed we ask for the least that would do, and the document is destroyed once the check clears, as Record 04 sets out.

14.3 Timing

The statutory deadline is one calendar month from receipt, and where a request is genuinely complex or several arrive together, Article 12(3) allows a further two months provided we tell you inside the first month and explain why. Our working practice is that a request answered late is a request mishandled, so the extension is used rarely and never as a convenience.

14.4 Cost, and the two occasions there is one

Requests are free. Article 12(5) permits a reasonable charge, or a refusal, where a request is plainly baseless or repeats one already answered, and if we ever reached for that we would set out precisely which limb applied and how to challenge it.

Back to contents

Part 15

Escalating past us

Role: controller

Article 77 gives you a route to the supervisory authority, and you may take it whether or not you have raised anything with us first. Coming to us first tends to be faster, and it is not a precondition.

The United Kingdom regulator is the Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF. Telephone 0303 123 1113. The complaint route sits at ico.org.uk.

Articles 79 and 82 additionally leave the courts open to you, including for compensation where damage has been suffered. Where a complaint concerns data inside a client platform, the ICO will normally want the controller named, and Part 09 explains how to get that name from us.

Back to contents

Part 16

Controls guarding the pipeline

Role: both, distinguished

Article 32 asks for measures appropriate to the risk, which for a company of this size means a small number of controls actually kept rather than a long list nobody audits.

• Traffic to this site is encrypted in transit; stored correspondence and documents are encrypted at rest by the providers holding them.
• Every account we use carries a second factor. Shared logins are refused, including when a client offers one, because a credential nobody owns cannot be revoked with confidence.
• Client access is named, scoped and time bound, read only wherever the task permits, and handed back at the end of the piece of work rather than left dormant.
• Working machines have full disk encryption and automatic locking. Client data does not travel onto a personal device.
• Development uses synthetic or masked material by default, so most weeks the sensitive column is never copied at all.
• Destructive operations against a client system need written approval recorded against the task, and they are never bundled inside a larger change.
• This website is static, which removes the whole class of injection, upload and authentication defects that a database backed site has to defend.

No control set is a guarantee, and anyone who tells you otherwise is selling something. What we will say is that these are the measures in place, that they are proportionate to what is held, and that a client can ask for evidence of any of them under the Article 28 contract.

Back to contents

Part 17

When a row escapes

Role: both, distinguished

A personal data breach is what has happened when data is destroyed, altered, exposed or reached by somebody with no business reaching it, whether that came about by accident or by design. Losing the only copy counts. So does sending a spreadsheet to the wrong address.

17.1 Acting as controller

The incident is contained first, then assessed for what it means to the people in the data rather than to us. Where a risk to individuals is more than unlikely, the Information Commissioner is told inside seventy two hours of us becoming aware, using Article 33; where the risk is high, the individuals are told directly and in plain language under Article 34, with the facts we have at the time rather than a reassuring summary. Every incident is written up whether or not it crossed the reporting threshold, because Article 33(5) requires the record and because the pattern across incidents is more instructive than any single one.

17.2 Acting as processor

Article 33(2) puts one duty on us and it is unqualified: tell the client without undue delay. We do not sit on an assessment, decide on the client's behalf whether it is reportable, or wait for a working day to begin. The client's own clock cannot start until ours has.

Back to contents

Part 18

No scoring, no automated verdicts

Role: controller

Article 22 concerns decisions taken by machine alone that carry a legal or similarly significant effect. As controller we take none. Nobody here is scored for likelihood of buying, ranked by seniority, sorted by company size or filtered by an algorithm before a human reads their message. An enquiry is answered by a person who has read it.

Profiling in the Article 4(4) sense is equally absent: we build no behavioural picture of a visitor or correspondent, and there is no analytics feed that could supply one. Inside a client platform, automated decisions are the client's design and the client's accountability, and where we are asked to build one we raise the Article 22 question during scoping rather than after launch.

Back to contents

Part 19

Children

Role: both, distinguished

What this company sells is bought by organisations, through procurement, by adults doing a job. The website is written for that reader, nothing on it is directed at a child, and no service here is offered to one.

Should we discover that a message we hold as controller came from a child, it is deleted unless there is a legal reason to keep it, and no attempt is made to keep the contact for later. Where a client platform contains data about children, the extra care is real and specific: the age appropriate design code applies to the client's service, a data protection impact assessment is expected before we touch the tables, and the retention and deletion routines we build get tested against a child's record before the client is asked to sign anything off.

Back to contents

Part 20

Applications published to a phone

Role: processor

Where an engagement includes the data path behind a client's mobile app, the client is the developer of record on the App Store or Google Play and the controller for what the app collects. Our part is upstream: the events it emits, the pipeline that carries them, the tables they land in and the deletion that eventually removes them. Store rules therefore reach our work, and these are the positions we hold to.

20.1 App Tracking Transparency

Apple requires the App Tracking Transparency prompt before an app uses an identifier to follow a user across other companies' apps and websites. Tracking of that kind is not something we build into a client pipeline. Where a client wants it anyway, the prompt is implemented honestly, a refusal is honoured in the pipeline as well as in the app, and the identifier is dropped at ingestion rather than merely hidden in a report. A refusal that stops at the user interface and still reaches the warehouse is a defect, and we treat it as one.

20.2 Play Data Safety

Google Play requires a Data Safety declaration describing what an app collects, what it shares and how long the data lives. We generate the answers from the pipeline rather than from memory: the fields the client emits, the destinations each reaches, and the retention applied to each destination, produced from the lineage graph and handed to the client to file. A declaration that does not match the traffic is a defect too, and easier to find with a lineage graph than with a meeting.

20.3 Permissions

A permission a client's app requests should map to a field somebody is actually going to read. Where we can see that a granted permission feeds nothing downstream, we say so and recommend removing the request, since an unused permission is a liability with no corresponding output.

Back to contents

Part 21

Account deletion and erasure

Role: both, distinguished

This website has no sign in, so there is no account here to close. Deletion of data we hold about you as controller is Article 17 in operation, and Part 14 is the route: write to the inbox with PRIVACY in the subject and say what you want removed.

What happens then is traced rather than assumed. We locate the correspondence, the engagement file and any ledger entry, remove what is removable, and name the specific statutory obligation behind anything that has to stay. You get a written account of what went and what did not, with the backup window in Part 12 stated openly rather than glossed.

21.1 Account deletion inside a client's product

Where a product we helped build offers account deletion, the client owns that route and its published terms govern it. The part we care about is that the request propagates: a deletion that clears the application database and leaves the person sitting in the warehouse, in a downstream extract or in a reporting layer is not a deletion. We engineer that propagation and the test that proves it worked, and we treat both as ordinary scope rather than an extra.

Back to contents

Part 22

Direct marketing and PECR

Role: controller

There is no mailing list, no newsletter and no campaign tooling attached to the inbox. Nobody who writes to us is enrolled in anything, and no list of addresses has ever been bought for this company.

Electronic marketing to individuals is governed by regulation 22 of the Privacy and Electronic Communications (EC Directive) Regulations 2003, on top of the UK GDPR. Corporate subscribers sit outside that regulation, which is what makes cold email to a business address lawful; where we write first to somebody at an organisation, it is a specific message about specific work, it identifies the company sending it, and one reply asking us to stop ends it permanently.

Regulation 6, which governs storage on your device, is dealt with separately in the cookie statement. The short version is that nothing requiring consent is written to your device by us, which is why you were not asked.

Back to contents

Part 23

Amendments and version lineage

Role: controller

The version in force is the one printed at the top of this page with its effective date. A document that changes silently is worth as little as a table that changes silently, so this one carries a version number for the same reason a model carries one.

When something material changes, the record it changed is named in the new version rather than left for you to find by comparison. Superseded versions are retained internally, which means a question about what this notice said on a particular date has an answer rather than an opinion. Ask for the version that was live on a given day and you will be sent it.

Back to contents

Part 24

Contact

Role: controller

VIVAN LABS LTD, a private limited company on the register of England and Wales, company number 17061582. Every route in this notice ends at [email protected].

• A right under Part 13. Open the subject line with PRIVACY and say which right and which addresses to search.
• A question about a client platform. Describe what you used and we will name the controller where we lawfully can.
• A security defect on this site. Open the subject line with SECURITY and include the steps to reproduce it.
• Dissatisfaction with an answer. Say so to us, and take it to the ICO whenever you prefer, using Part 15.

Other routes into the company, and what to expect from each, are set out on the contact page.

Back to contents