Privacy notice

The company's registered office is recorded against company number 17061761 on the public register at Companies House, which is the address with legal effect for service of a document. "We" means UMZI LABS LTD. "You" means any individual whose personal data we handle. Reach us at [email protected].

We have not appointed a statutory Data Protection Officer. Article 37 requires one only for public authorities, or where core activities involve large scale systematic monitoring or large scale special category processing. None applies to us. Responsibility sits with the company's officers, whose details are on the public Companies House register under company number 17061761. Send requests to the address above, not to any individual.

We have no establishment in the European Union and do not currently offer goods or services to individuals in the EU, so we have appointed no Article 27 representative.

The law splits responsibility between the controller, which decides why and how personal data is processed, and the processor, which processes on the controller's documented instructions. We act in both roles, and our obligations differ sharply between them. Every processing section below is marked with the role we are acting in.

2.1 Where we are the controller

We are the controller for data we collect for our own purposes: enquiries sent to us, correspondence with clients and suppliers, contract and accounting records, recruitment correspondence, and the technical data generated when a browser requests a page from this site. For all of it we set the purpose, choose the lawful basis, set the retention period, and answer to you and to the ICO. Sections 4, 5 and 6 cover it.

2.2 Where we are the processor

When we build, investigate or maintain software for a client, we encounter personal data belonging to that client's users, customers or staff. The client decides why it exists. The client is the controller and we are the processor, acting only on documented instructions under a written contract meeting Article 28. Section 7 covers it.

The practical consequence: if your data sits in a client system we work on, we are not the right people to answer a rights request about it. We must pass your request to the controller and assist them. We cannot delete, correct or disclose that data on our own initiative, because Article 29 forbids it.

2.3 Where the roles meet

Business contact details of a client's staff, meaning names, job titles, work email addresses and work telephone numbers of the people we deal with, are processed by us as controller rather than processor, because we decide to keep them to run the relationship and our accounts. Section 5 covers that.

2.4 What we are not

We are not a joint controller with anyone. We do not sell, rent, licence or broker personal data. We run no advertising business, no data enrichment service and no marketing list, and we buy contact data from nobody.

UK GDPR

Regulation (EU) 2016/679 as it forms part of UK law by virtue of the European Union (Withdrawal) Act 2018, as amended.

DPA 2018

The Data Protection Act 2018, which supplements the UK GDPR and provides the exemptions referred to in section 11.12.

Personal data

Information relating to an identified or identifiable living individual, per Article 4(1).

Special category data

The Article 9(1) categories: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used for identification, health data, and data concerning sex life or sexual orientation.

Sub-processor

A third party we engage to process on our behalf, such as a hosting provider. Listed in section 8.

IDTA

The International Data Transfer Agreement issued by the Information Commissioner under section 119A of the DPA 2018, used to safeguard restricted transfers out of the UK.

UK Addendum

The International Data Transfer Addendum to the European Commission's Standard Contractual Clauses, also issued under section 119A, which adapts the EU clauses to operate under UK law.

Our role: controller

This covers what happens when you email us. It is currently the main way personal data reaches the company.

Scroll the table sideways on a narrow screen to see every column.

4.1 Special category data

We do not ask for it and have no purpose needing it. If you volunteer it, we use it for nothing and it is deleted with the thread on the schedule above. Please do not send special category data or financial account details by unsolicited email, which is not a confidential channel.

4.2 Marketing

We run no mailing list, newsletter or marketing automation. Contacting us adds you to nothing. If we ever start a list it will be opt in by a positive action, never bundled into another agreement.

Our role: controller

Personal data about individuals at client and supplier organisations, and the records a UK company must keep. The company has not yet traded, so these records are largely empty. The rules are published now, before the records exist.

5.1 The legitimate interests balancing test

Where we rely on Article 6(1)(f) we must name the interest, show the processing is necessary for it, and check it is not overridden by your rights. Each row above names the interest. Common features of our assessment: the data is business contact data rather than data about your private life; the processing is what someone in your position would expect from a supplier or prospective supplier; we do not combine it with other sources or build a profile; and you can object at any time under section 11.9. Ask and we will send the written assessment for any specific activity.

Our role: controller

umzilabs.co.uk is a static site. No accounts, no forms, no comments, no search, no server side application code. Nothing on it can submit data to us, which is why email is the only contact route. It sets no analytics or advertising cookies and loads no analytics, advertising, chat, heatmap, session recording or social media script.

We set no cookie ourselves and there is no consent banner, because there is nothing to consent to beyond the strictly necessary security cookie above. If we ever add something requiring consent under PECR, a banner will appear, refusing will be as easy as accepting, and nothing non-essential will load until you choose. Detail is in the cookie notice.

6.1 The Google Fonts position

This site loads two typefaces from Google, so your browser contacts Google's servers and Google receives your IP address and user agent as a result. We receive nothing and get no analytics from it. Self hosting the font files would avoid it and we consider that the better position. We have not done it yet. When we do, this section will be replaced with a statement that no third party font request is made.

Our role: processor

Engineering or research work on a client's system may give us access to personal data the client controls: user records in a database we migrate, identifiers in log files, a production sample used to test whether an approach works, support tickets visible while debugging. We choose to collect none of it and have no purpose of our own for it.

7.1 What the Article 28 contract requires of us

Before any engagement involving client personal data we enter a written data processing agreement obliging us to: process only on documented instructions; tell the controller if an instruction appears to breach data protection law; keep the data confidential and bind everyone with access to the same duty; apply Article 32 security measures; obtain prior written authorisation before engaging any sub-processor and flow the same terms down; assist with rights requests, security, breach notification and impact assessments; delete or return the data at the end of the engagement at the controller's election; and provide the information and audit access the controller needs to demonstrate compliance.

7.2 Working practices we apply by default

We prefer not to hold client personal data at all. Where we can work inside the client's own environment using accounts the client issues and revokes, we do, and no copy reaches our systems. Where a local copy seems necessary we first ask whether anonymised or synthetic data would answer the question, because usually it will. Where a real extract is unavoidable we take the smallest extract that answers the question, keep it for the shortest time that answers it, and delete it with written confirmation when the task ends.

7.3 What this means for your rights

If your data is in a client system we have worked on, your rights are exercised against the client, not us. Contact us anyway and we will not ignore you: we will forward the request to the controller without undue delay and, where permitted, tell you who they are. We cannot act on it ourselves, because Article 29 prohibits a processor from processing except on the controller's instructions.

7.4 Sub-processors on client work

We engage no sub-processor on client personal data without the client's prior written authorisation, recorded in the data processing agreement. Section 8 lists sub-processors for our own controller processing; engagement specific ones are named in that engagement's agreement.

Our role: controller

Third parties processing personal data on our behalf for our own operations. The list is short because the company runs on very little infrastructure. Each is engaged under a written contract containing the Article 28 terms.

8.1 Independent controllers we may disclose to

Separately from the above, data may go to organisations acting as controllers in their own right: our bank, for payments made and received; HM Revenue and Customs and Companies House, where a statutory filing requires it; our insurers, if a claim arises; our solicitors, for legal advice or the conduct of a claim; and any law enforcement body, regulator or court where we are legally compelled. Where disclosure is compelled we will tell you unless legally prohibited from doing so.

8.2 Changes to this list

If we add a sub-processor, this table is updated before that sub-processor begins processing. Clients under an Article 28 agreement get advance written notice of any change affecting their engagement, and a period in which to object.

8.3 Google as a font provider

Google is not a sub-processor of ours. Your browser contacts Google directly for typefaces, and Google is a separate controller of the connection data it receives. We have no contract with Google covering this and receive nothing back. See section 6.1, including our intention to remove it.

Our role: controller, and processor on client work

A restricted transfer is personal data sent to a receiver outside the United Kingdom. Chapter V of the UK GDPR permits one only where a listed condition is met. We use three, in this order of preference.

9.1 Adequacy regulations

Under Article 45 the Secretary of State may make regulations declaring that a country, territory or sector provides adequate protection, in which case no further safeguard is required. Coverage includes the European Economic Area states and the other jurisdictions listed in the adequacy regulations made under the DPA 2018. Adequacy for the United States operates only through the UK Extension to the EU-US Data Privacy Framework, and only for organisations self certified to that extension and still on the certified list. We do not assume a US receiver is covered. We check, and if certification is absent or lapsed we use a transfer agreement instead.

9.2 The IDTA

Without adequacy cover, our first choice is the International Data Transfer Agreement issued by the Information Commissioner under section 119A of the DPA 2018. It is a standalone UK contract drafted for UK law, and the cleanest instrument where we contract directly with an overseas receiver.

9.3 The UK Addendum to the EU SCCs

Many international suppliers offer only the European Commission's Standard Contractual Clauses, because their contracts are drafted for the EU market. We then use the International Data Transfer Addendum to those clauses, also issued under section 119A, which adapts them to operate under UK law by replacing references to EU law and EU supervisory authorities with UK equivalents. Cloudflare's data processing addendum incorporates the UK Addendum, and that is the mechanism relied on in table 8.1.

9.4 Transfer risk assessments

Neither instrument suffices on its own. Before relying on either we assess whether the contractual protection will be effective in practice in the destination country. That means considering its surveillance and government access laws, whether the receiver has faced an access request, what technical measures such as encryption in transit and at rest reduce exposure, and what the consequences for an individual would be if the data were accessed. Where the assessment shows the contract would not be effective, we do not make the transfer. We find a UK or EEA alternative, or restructure the work so the data does not leave.

9.5 Client work

Where we are a processor, the controller decides whether an international transfer may happen and the permitted destinations are recorded in the data processing agreement. We transfer no client personal data out of the UK without that written instruction.

9.6 Getting a copy

Ask us at [email protected] for a copy of the mechanism relied on for any transfer of your data. We may redact commercial terms such as pricing, but not the data protection provisions.

Our role: controller

Article 5(1)(e) requires that data is kept in identifiable form no longer than necessary. Every period below has a reason attached, because a retention schedule without reasons is not a schedule, it is a preference.

10.1 What happens at the end of a period

Records are deleted, or where deletion is not technically possible, anonymised so no living individual can be identified from them alone or combined with other data we hold. Backups are not exempt. Where a record is deleted from live systems but persists in a backup, the backup copy is put beyond ordinary use, meaning it is not restored for any purpose other than a disaster recovery event, and it goes on the backup rotation.

10.2 Legal holds

Where we become aware of an actual or reasonably anticipated legal claim, regulatory investigation or criminal proceeding to which a record is relevant, that record is preserved beyond its normal period until the matter concludes. This is narrow and does not extend to unrelated records.

Our role: controller. For processor held data see section 7.3

These rights are yours by law. Exercising them is free, and asking does not affect how we treat you in any other respect.

11.1 How to exercise any right

Email [email protected] with "Data protection request" in the subject line. You need not use particular words, cite an article, or explain why. A request made verbally, or in a message that never uses the word "request", is still valid. It helps if you say which right and which data you mean, but neither is a condition. You may appoint someone to act for you, in which case we need written authority from you first.

11.2 Verifying your identity

Article 12(6) lets us ask for information reasonably necessary to confirm identity where we have genuine doubt, and Article 5(1)(f) obliges us not to disclose to the wrong person. If you write from an email address we already hold for you, that is normally enough and we will ask for nothing further. Where doubt remains we ask for the least intrusive confirmation that resolves it, often a detail already in the record. We will not routinely demand a passport or driving licence scan by unencrypted email. The one month clock starts only once we can identify you, and we will tell you promptly if we need something.

11.3 Timing

We respond without undue delay and within one calendar month of receiving your request, per Article 12(3). For genuinely complex requests, or where you have made several, we may extend by up to two further months, and if we do we will tell you within the first month and explain why. We aim to acknowledge within five working days so you know it arrived.

11.4 Right of access, Article 15

You can ask whether we hold your personal data and, if so, receive a copy plus the Article 15(1) supplementary information: purposes, categories of data, recipients, retention period or the criteria for it, your other rights, the right to complain to the ICO, the source if we did not get it from you, and whether there is automated decision making. We supply the copy in a commonly used electronic format unless you ask otherwise. Where a record contains someone else's personal data we redact it, unless they consent or disclosure without consent is reasonable, as paragraph 16 of Schedule 2 DPA 2018 permits.

11.5 Right to rectification, Article 16

You can have inaccurate data corrected and incomplete data completed, including by a supplementary statement. Where the record is of an opinion we formed or advice we gave, we will not rewrite it to say something different, but we will record accurately that you dispute it and what your position is, which is what Article 16 requires there. Where we have disclosed the data, Article 19 requires us to tell recipients of the correction unless that is impossible or disproportionate, and we will name those recipients if you ask.

11.6 Right to erasure, Article 17

You can have data erased where an Article 17(1) ground applies: it is no longer necessary for its purpose, you have withdrawn consent and no other basis applies, you have objected under Article 21 with no overriding ground, or it was unlawfully processed. The right is not absolute. We must refuse where processing is necessary to comply with a legal obligation, which is why accounting records cannot be erased inside the six year period in table 10.1, and where it is necessary for the establishment, exercise or defence of legal claims. If we refuse we will say which exception applies to which specific data, and erase everything not covered by it.

11.7 Right to restriction of processing, Article 18

You can require us to stop using data while keeping it, in four situations: while we verify accuracy you have contested; where processing is unlawful but you prefer restriction to erasure; where we no longer need the data but you need it for a legal claim; and while we consider an objection under Article 21. Restricted data is stored and not otherwise processed except with your consent, for a legal claim, to protect another person's rights, or for important public interest reasons. We will tell you before any restriction is lifted.

11.8 Right to data portability, Article 20

Where processing rests on consent or on a contract with you and is carried out by automated means, 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. In practice this reaches little of what we hold, because most of it rests on legitimate interests or is correspondence we created rather than structured data you supplied. We will tell you plainly which parts qualify rather than refusing the whole request.

11.9 Right to object, Article 21

Where we process on legitimate interests you can object on grounds relating to your particular situation. We must stop unless we can demonstrate compelling legitimate grounds overriding your interests, rights and freedoms, or that the processing is for legal claims. If we rely on an override we will explain the reasoning, not merely assert it. For direct marketing the right is absolute and we must stop on request with no balancing exercise. We do not do direct marketing, so this should not arise.

11.10 Right to withdraw consent, Article 7(3)

Where we rely on consent you can withdraw it at any time, and withdrawing must be as easy as giving it. Withdrawal does not make earlier processing unlawful. At the date of this notice we rely on consent for nothing in sections 4 to 6, so there is nothing to withdraw, but the right is stated because that may change.

11.11 Rights on automated decision making, Article 22

You have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects or similarly significantly affects you. We make no such decisions. See section 17.

11.12 When we may refuse a request

Article 12(5) lets us refuse, or charge a reasonable fee, where a request is manifestly unfounded or manifestly excessive. That is a high bar and we will not use it to dodge an inconvenient request: a request is not excessive merely because it is broad, nor unfounded merely because you are unhappy with us. We may also rely on the exemptions in Schedules 2 to 4 DPA 2018, for instance where compliance would disclose another person's data, where the material is subject to legal professional privilege, or where it would prejudice the prevention or detection of crime. If we refuse in whole or part we will tell you within one month which exemption we rely on, what it covers, and that you can complain to the ICO or apply to a court.

If you are unhappy with how we handled your data or your request, please tell us first, because we can usually fix it faster than anyone else. Either way you have the right under Article 77 to complain to the Information Commissioner's Office, the UK supervisory authority. Complaining to us is not a precondition and does not affect that right.

Information Commissioner's Office

Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF, United Kingdom

Telephone

0303 123 1113

Website

ico.org.uk

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 caused by an infringement.

Our role: controller and processor

13.1 Measures we apply

Article 32 requires technical and organisational measures appropriate to the risk. Ours are proportionate to a very small company that deliberately holds very little: transport encryption throughout, with HTTPS enforced by HSTS on this site; encryption at rest on devices and storage holding company data; multi factor authentication on every account that supports it; access limited to those who need it for a specific task and revoked when the task ends; a strong preference for working in client environments rather than taking copies; anonymised or synthetic data for development wherever it will answer the question; and separation of client work so access to one engagement never carries access to another.

13.2 What counts as a breach

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 covers losing a device, emailing the wrong recipient and a ransomware event that makes data unavailable, not only an external intrusion.

13.3 Notifying the ICO, Article 33

Where we are the controller we assess whether a breach is likely to result in a risk to the rights and freedoms of individuals. If it is, we notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware. If full information is not available within 72 hours we still report in time and supply the rest in phases, as Article 33(4) allows. If we report late we tell the ICO why. Where we decide a breach is below the threshold we record the decision and the reasoning, because Article 33(5) requires a record of every breach whether reportable or not.

13.4 Notifying you, Article 34

Where a breach is likely to result in a high risk to your rights and freedoms we will tell you directly and without undue delay, in clear plain language, describing the nature of the breach, a contact point, the likely consequences, what we have done and what we recommend you do. Individual notification is not required where the data was rendered unintelligible to anyone unauthorised, for example by strong encryption, or where later measures mean the high risk is no longer likely to materialise. Where individual notification would involve disproportionate effort we make a public communication instead.

13.5 Where we are the processor

Article 33(2) requires us to notify the client without undue delay after becoming aware. We do not notify the ICO or affected individuals ourselves there, because the controller makes that assessment and holds that duty. Our contractual commitment to clients is notification within 24 hours of becoming aware, tighter than the law requires, with the information they need for their own 72 hour assessment.

13.6 Reporting something to us

If you think data we hold has been exposed, email [email protected] with "Security report" in the subject line. We acknowledge within two working days. We run no paid bug bounty and will not imply that we do.

Our role: controller, for any application published under our own name

14.1 The governing rule

No device permission will be required to use the core function of an application we publish. Every permission is optional. Each is requested at the moment it is first needed rather than queued at first launch, and preceded by a plain explanation of what it is for. Declining will never terminate the application, hide unrelated functionality, or produce a repeated prompt. We ask once. If you say no, the answer stays no until you change it in device settings.

Scroll the table sideways on a narrow screen to see every column.

14.2 Changing your mind later

Every permission above can be granted or revoked at any time in device settings, without uninstalling anything and without asking us. Revocation takes effect immediately, and data already collected under it is subject to the deletion route in section 15.

Our role: controller

We operate no user accounts today: no login on this site and no application to hold an account in. The commitments below apply to any account system we later operate, and to correspondence records now.

15.1 The in-app route

Any product we publish holding user accounts will include a deletion control inside the product, reachable without contacting support. The path will be Settings, then Account, then Delete account, no more than three steps from the main screen. It will show what will be deleted and what must be retained before you confirm, and require one confirmation rather than a retention offer or a sequence of discouraging screens.

15.2 The email route

You can always ask by email instead, whether or not an in-app control exists, and this is the route that applies today. Write to [email protected] with "Deletion request" in the subject line. We acknowledge within five working days.

15.3 The 30 day commitment

Deletion is completed within 30 days of a verified request, across live systems and any sub-processor holding a copy. That is shorter than the month plus extension Article 12(3) would permit, and we hold ourselves to it deliberately. Backup copies are put beyond ordinary use immediately and removed on the backup rotation, which is why the commitment is deletion in live systems within 30 days rather than every byte everywhere. We confirm in writing when it is done.

15.4 What is retained after deletion, and why

• Invoices and payment records, six years from the end of the relevant financial year, because HMRC and the Companies Act 2006 require it. A legal obligation we cannot waive at your request.
• The fact that a deletion request was made, by whom and when completed, for 36 months, to evidence compliance and to avoid recreating the record from a backup.
• A suppression record where one is needed to stop data being reintroduced, kept to the minimum that achieves that and used for nothing else.
• Records under a legal hold per section 10.2, for as long as the matter continues.
• Anonymised and aggregated information from which you cannot be identified, which is no longer personal data and falls outside a deletion request.

Nothing else is retained. We keep no shadow copy of a deleted account for analytics, reactivation or any other reason.

15.5 Deletion where we act as a processor

If your data is in a client's system we cannot delete it on your instruction, for the reasons in section 7.3. We will forward the request to the controller without undue delay.

16.1 The App Tracking Transparency position

Apple's App Tracking Transparency framework requires permission through the system prompt before an app tracks a user across apps and websites owned by other companies, or accesses the device advertising identifier. We do neither, in any product, and do not intend to. We will therefore not present the ATT prompt at all: there is no prompt to accept or decline, and no functionality is conditioned on one. We do not use the Identifier for Advertisers, integrate advertising or attribution SDKs, use device fingerprinting as a substitute for the advertising identifier, or share data with data brokers. If that position ever changed, a prompt would appear, this section would be rewritten before it did, and declining would not reduce what the product does.

16.2 The Google Play Data Safety declaration

Google Play requires every app to publish a Data Safety declaration covering what it collects and shares, why, whether it is encrypted in transit and whether deletion can be requested. Our commitment is that the declaration for any Umzi Labs application will match this notice exactly. Where the Play form forces a coarser category than the truth, we will select the category and use the free text to state the narrower reality, rather than accept a label that overstates collection.

If you ever find a discrepancy between a Data Safety declaration of ours and this notice, treat it as our error and tell us at [email protected]. We will correct whichever is wrong and say which it was. The same undertaking applies to Apple App Store privacy labels. At the date of this notice no Umzi Labs application is published on either store, so no declaration and no privacy label exists. We are not claiming to have filed one.

We make no decisions about you based solely on automated processing producing legal or similarly significant effects, so the Article 22 restriction is not engaged. We build no behavioural profiles, we do not score or rank individuals, and we do not use personal data to train machine learning models, our own or anyone else's.

Where an engagement involves building an automated decision system for a client, the client is the controller of it and holds the Article 22 compliance, lawful basis and impact assessment duties. Our role is to raise the issue when we see it and build the safeguards the controller specifies. We will say so in writing if we think a system a client has asked for would be unlawful.

This website and our services are directed at businesses and at adults acting professionally. They are not directed at children and we do not knowingly collect personal data from anyone under 18. We operate no service engaging the Article 8 information society services consent rules, under which the UK age of consent is 13.

If you believe a child has given us personal data, email [email protected] and we will delete it promptly. If we later publish a consumer product that children could plausibly use, we will assess it against the ICO's Age Appropriate Design Code before release and update this notice.

This is version 1.0, effective 7 August 2026. We review it at least annually and whenever we change something it describes, such as adding a sub-processor, starting a new processing activity or publishing an application.

The effective date and version at the top always reflect the current text. Where a change materially affects your rights or substantially alters what we do with your data, we will not rely on a silent update: we will contact those affected directly where we hold contact details, and state what changed rather than only that something did. Minor corrections such as a broken link are made without notice and the review date is updated. We do not backdate. A new version applies from its effective date, and processing that already happened is judged against the version then in force.

For anything in this notice, including the rights in section 11, write to [email protected]. Put "Data protection request" in the subject line if that is what it is, which routes it faster, though a request is valid however it is worded.

Controller

UMZI LABS LTD

Company number

17061761, registered in England and Wales

Email

[email protected]

Acknowledgement

Within 5 working days

Substantive response

Within 1 calendar month, extendable by up to 2 months for complex requests, with notice inside the first month

Related documents: the terms of use and the cookie notice.

Back to the top