Privacy policy

Version 2.0 · in force from 15 August 2026 · supersedes version 1.0

1. Reading conventions

Most privacy notices are written as an essay. Ours is written as a dictionary, because that is the artefact our trade actually produces and because an essay makes it easy to hide the one fact that matters — how long something is kept and who can read it.

Each record type we hold appears below as a named entity. Under every entity you will find the same six labels, and they carry the meanings set out here.

Where a term carries a statutory meaning — controller, processor, personal data, special category data — it is used with that meaning and not loosely.

2. Controller identity

For everything in sections 5 to 11, the controller is:

We are a studio rather than a group, so there is no parent company, no shared service centre and no affiliate that quietly receives a copy. The directors read the privacy mailbox themselves and the data protection duty sits with them; the company is not of a size or activity profile that obliges it to appoint a statutory data protection officer, and appointing one would put a layer between you and the people who can actually change the system.

3. Which role we occupy

We sit on two sides of the same regulation depending on whose data is in front of us, and conflating the two is the commonest error in notices of this kind.

As controller we decide why and how data is handled. That covers people who write to us, the people we contract with, our suppliers, job applicants, anyone using an application we publish under our own name, and the automatic logs our hosting produces. Sections 5 to 11 document those entities.

As processor we handle data belonging to a client, on that client's written instructions, inside systems we are building or maintaining for them. We did not choose the purpose of that data and we are not free to invent new uses for it. Section 12 documents the arrangement, and if you are a customer, patient, employee or contact of one of our clients, that is the section that concerns you.

A single engagement routinely puts us in both roles at once: the client's contact details sit in engagement, where we are controller, while the warehouse we are populating for them holds client_dataset, where we are not.

4. Entity catalogue

The full set of record types is listed here so that nothing is documented only by omission. If a record type is absent from this catalogue, we do not keep it.

5. enquiry

We do not run the received addresses through enrichment services, we do not append firmographic data bought from a broker, and an enquiry that goes nowhere is not repurposed into a prospect list.

6. engagement

7. ledger

8. supplier_contact

9. applicant

10. app_account

Advertising identifiers are not collected, no advertising software development kit is compiled into anything we publish, and account data is not sold, rented or traded. Section 25 sets out what this means for the App Store and Google Play disclosures.

11. access_log

No analytics product runs on this website, so there is no measurement identifier to reconcile against these logs.

12. client_dataset

If you believe your data sits in a client's system that we built, section 18 explains where to direct a request, and why sending it to us first will usually slow you down.

13. Processor undertakings

Article 28 of the UK GDPR requires a written arrangement between controller and processor before the processor touches anything. We sign the client's terms where they have them and offer our own where they do not. Either way the following undertakings bind us.

• We act only on documented instructions from the client, and we tell the client if an instruction looks to us like a breach of data protection law rather than quietly carrying it out.
• Everyone we let near client data is bound by confidentiality that survives the engagement.
• We apply the controls described in section 23, sized to the sensitivity of what we are handling.
• No sub-processor is engaged without the client's authorisation, and we remain answerable for what a sub-processor does.
• We help the client answer requests from individuals, since it is usually our system that has to produce the answer.
• We help the client meet its own duties on security, breach notification and impact assessments.
• At the end of the engagement the client chooses return or destruction, and we carry out the choice.
• We make available what the client needs to satisfy itself we are doing all this, including submitting to an audit the client wishes to run.

14. Client data during a build

Undertakings matter less than the daily habits that make them true. These are ours.

Synthetic first

Development and testing run on manufactured data by default. Real records are pulled into a test environment only where a defect cannot be reproduced without them, only with the client's agreement, and only for as long as the investigation takes.

Minimised extracts

When a sample is genuinely required we take the narrowest slice that answers the question — the columns needed, the rows needed, masked where masking still allows the bug to show itself.

Client-owned environments

Wherever the engagement allows, the warehouse, the pipelines and the application run in cloud accounts the client owns from the first day. That is partly a data protection choice and partly a commercial one: it means the client can revoke our access without asking us to co-operate.

Encryption in both states

Data moves over TLS and rests on encrypted storage. Where a client's platform offers customer-managed keys we will configure them on request.

Controlled workstations

Engineering machines have full-disk encryption, automatic locking and current operating system updates. Client extracts live in designated project locations that are wiped at handover, not scattered through a downloads folder.

Credential hygiene

Access uses named accounts with multi-factor authentication. Shared logins are avoided; where a client's own tooling forces one, we say so in writing and agree a rotation schedule. Secrets are held in a manager, never in source control or a message.

Observability without leakage

Pipelines we build log the shape of a failure rather than its contents — row counts, error codes, the offending column name. Payloads are excluded from log output by design, because a log that quietly copies personal data into a second system is the most common way a well-built pipeline creates a breach.

15. Aggregates and re-identification

Much of what we build produces summaries: revenue by week, orders by channel, throughput by site. A summary computed from personal data is not automatically free of it, and a chart with a small enough denominator can name a person as surely as a list.

Where the output of a dashboard is meant to be anonymous we design for that outcome rather than assume it — suppressing thin cells, avoiding breakdowns that isolate a single individual, and being candid with the client where a requested view cannot be made safe at the granularity asked for. Where a figure remains capable of singling someone out, we treat it as personal data and it keeps the protections of the entity it came from.

We do not build models that score individuals, and nothing we operate produces a decision about a person by automatic means alone.

16. Special category values

Article 9 of the UK GDPR fences off data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic and biometric identifiers, health, sex life and sexual orientation. Article 10 does the same for criminal offence data.

As controller we hold none of it. Nothing in sections 5 to 11 asks for it, and if an enquiry or an application arrives carrying such a detail unprompted, it stays inside that thread and is used for nothing.

As processor we sometimes encounter it, because a client in health, care or recruitment may hold it lawfully. Where an engagement will touch data of that kind we establish it during scoping, record it in the processing arrangement, tighten the controls in section 23 accordingly, and expect the client to have completed a data protection impact assessment. We will contribute to that assessment; we cannot be the party that carries it out, since the purpose being assessed is the client's own.

17. Children

Our services are sold to businesses and this website is written for the people who run them. Nothing here is aimed at a child, and we do not knowingly hold a child's data as controller.

Where we publish an application in our own name, it is offered to adults and rated accordingly on each store. Should we discover an account belonging to a child who was not entitled to open one, we close it and drop the row rather than leave it dormant.

As processor the position differs: a client in education, paediatric care or youth services may lawfully hold data about children, and we may be building the system that stores it. Engagements of that kind get the heightened controls in section 23, the recognition that a child's data deserves particular care in how it is displayed and exported, and a clear record that the client is the controller who owes those duties.

18. Reached us through a client

If you are a customer, patient, member or employee of an organisation we work for, your data may sit in a system we built without you ever having heard our name. That is ordinary, and it does not make us the party accountable to you.

Your rights run against the controller, which is that organisation. Its privacy notice tells you how to exercise them, and it is better placed than we are to identify you, to know what the data is for, and to act on your request across every system it runs rather than the one we happen to have touched.

Write to us anyway if that is easier. We will pass the request to the client without unnecessary delay, tell you that we have done so, and then support the client in answering it. What we will not do is reach into a client's environment and alter or delete records because a third party asked us to; a processor that did that would be exactly the wrong sort of supplier to give a database to.

19. Lawful basis index

The lawful bases named against each entity are gathered here so that they can be read together.

Where we rely on legitimate interests we have weighed our interest against your rights and concluded the processing is what a reasonable person would expect in the circumstances. Ask and we will send you the reasoning for the entity you care about.

20. Retention schedule

Each entity carries its own schema note; this table is the same information gathered for anyone auditing it. The periods are ceilings rather than targets, and a row that becomes unnecessary earlier is dropped earlier.

Deletion is carried out in an annual sweep and on demand. Backups are the honest exception: a row deleted from a live system persists in backup images until those images rotate out on their own cycle, and during that window the data is restorable but not otherwise used.

21. Grants and sub-processors

We buy infrastructure rather than build it, so some entities necessarily rest on someone else's servers. Each of the following is engaged under a written contract carrying the Article 28 terms, and each is chosen for a specific function rather than a bundle of them.

• Email and office platform — hosts the mailbox behind the published address, and therefore enquiry and much of engagement.
• Website hosting and content delivery — serves these pages and writes access_log.
• Cloud platform — where an application we publish runs, or where a client has asked us to operate in our own tenancy rather than theirs.
• Accounting software and our accountant — maintain ledger.
• Source control and secret management — hold the code we write and the credentials that reach client systems.

Beyond those: professional advisers when we need advice, a regulator or court where we are obliged to respond, and an acquirer if the business were ever sold, in which case you would be told before anything moved. Nobody buys access to these entities, and there is no advertising network anywhere in the list.

Ask by email for the current named list and we will send it. It is short enough to read in a minute, which is rather the point.

22. International transfers

We keep data in the United Kingdom or the European Economic Area wherever the supplier offers that choice, and it usually does.

Some suppliers are headquartered outside the UK, and support or engineering functions can involve access from elsewhere. Where an international transfer happens, one of the following carries it, and we check which before the supplier is engaged rather than afterwards:

• UK adequacy regulations, where the destination has been recognised as offering equivalent protection.
• The International Data Transfer Agreement, or the UK Addendum applied to the EU standard contractual clauses.
• The UK extension to the EU–US Data Privacy Framework, where the recipient is certified under it.

Where the safeguard is a contractual one we carry out a transfer risk assessment covering the destination's surveillance regime and the practical remedies available to you, and add supplementary measures — encryption we hold the keys to, or pinning the data to a chosen region — where the assessment calls for them. On a processor engagement we do not add an overseas sub-processor without the client's authorisation, whatever our own assessment concludes.

23. Security controls

Article 32 asks for measures appropriate to the risk. Ours are stated plainly so you can judge whether they are.

Technical

• Transport encryption on everything served or transferred, and encryption at rest on the platforms holding the entities above.
• Multi-factor authentication on every account that can reach personal data, ours and the client-side accounts issued to us.
• Role-based access granted per engagement at least privilege, reviewed when a project closes and revoked as part of handover.
• Secrets held in a manager, rotated when someone's access ends, and kept out of source control by automated checks.
• Dependency and platform updates applied on a routine cycle, with security patches pulled forward.
• Backups encrypted, with restores actually tested rather than assumed to work.
• Logging designed to exclude payload contents, as described in section 14.

Organisational

• A small team, which means a short list of people with access and no ambiguity about who has it.
• Confidentiality obligations on everyone involved, continuing after the engagement ends.
• Synthetic data as the default for development and testing.
• A written breach procedure, rehearsed rather than filed.
• Data protection considered at design time, so that minimisation and retention are properties of the system rather than promises about it.

These measures reduce risk; they cannot eliminate it, and any supplier claiming otherwise is describing a system that does not exist. Section 24 says what happens when something does go wrong.

24. Breach handling

A personal data breach is any security failure leading to accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of or access to personal data. It covers a laptop left on a train as squarely as an intrusion.

On becoming aware of one we contain it first — revoking credentials, isolating the affected system, stopping the pipeline. We then establish which entities and which people are affected, and record what we found and when we found it.

Where we are the controller and the breach poses a risk to people's rights, we report it to the Information Commissioner within seventy-two hours of becoming aware. Where the risk is high, we also tell the affected individuals directly, in language that says what happened and what they should do about it rather than language chosen to minimise the event.

Where we are the processor, the duty to notify is the client's and the duty to alert the client is ours. We do that without undue delay on becoming aware, with whatever detail we have at the time, and we keep the client updated as the picture fills in instead of waiting until it is complete.

Every incident is logged whether or not it met the reporting threshold, and the log is reviewed to see what in the design allowed it.

25. Mobile applications

This section covers applications we publish under our own name. Where we have built an application published under a client's name, that client's notice governs it and ours does not.

What an application holds

The app_account entity in section 10 is the whole of it: the account, its settings, the content you create, and the diagnostic values needed to investigate a fault. Device permissions are requested at the moment a feature needs one, with the reason on screen, and declining a permission disables that feature rather than the application.

App Tracking Transparency

Apple's framework requires an application to ask before tracking a user across apps and websites owned by other companies. We do no such tracking, so nothing we publish presents that prompt. There is no advertising identifier collected, no advertising or attribution software development kit compiled in, and no data broker relationship. Our App Store privacy labels say the same, and they are filled in from the entity documented above rather than from a template.

Google Play Data Safety

The Play Data Safety form declares what an application collects, what it shares, and how it is protected. Ours declares the account identifier and the content you create as collected for the functioning of the app, declares no sharing with third parties for advertising or analytics, confirms encryption in transit, and confirms a route to request deletion. Where a declaration and this notice ever diverge, treat it as a mistake on the form and tell us, because the schema above is the thing we implement.

Account deletion

Both stores require a reachable way to delete an account, and so does the UK GDPR. Deletion is available inside the application where the product has a settings screen, and by email to contact@ur-data.co.uk in every case. Ask for account deletion and we close the account, drop its content and remove the row within thirty days, keeping back only what the ledger rule in section 7 obliges us to keep. We will tell you if anything is being kept and under which rule.

26. Cookies and local storage

This website carries no analytics, no advertising tags and no third-party embeds that watch you. What little is stored on your device, and the reason there is no consent banner in front of it, is documented in the cookie policy, which is written in the same entity-by-entity form as this one.

Applications we publish use device storage to keep you signed in and to remember your settings. That storage is functional; it is not a profile and it is not shared.

27. Marketing messages

We do not run a newsletter, we do not send campaigns, and there is no list to be added to. If you write to us you get an answer about the thing you asked about, and nothing else arrives afterwards.

Should that ever change, it would begin with an opt-in you actively gave, every message would carry a working unsubscribe, and withdrawal would take effect on receipt rather than after a settling period. Under the Privacy and Electronic Communications Regulations we may contact a business address about a service similar to one already discussed; we would still stop immediately on being asked.

28. Operations you may run

The UK GDPR gives you a set of operations you can run against the rows we hold about you. They map onto the verbs of any database, which is how we think about them.

There is also a right not to be subject to a decision based solely on automated processing that produces a legal or similarly significant effect. We make no such decisions, so the right has nothing to bite on here — which is a statement about our systems, not a way of declining it.

29. Submitting an operation

Send it to contact@ur-data.co.uk. Say which operation you want and, if you can, which entity you think you are in — an enquirer, a client contact, an applicant, an account holder. That is a convenience, not a condition; a request that simply says what you want is valid and we will work out the rest.

We may ask for something that ties you to the rows, and we ask for the least that will do it: usually a reply from the address already on the record. Where identification is genuinely in doubt we will say what would settle it rather than refusing outright.

The answer comes within one month of receipt. Complexity, or several requests arriving together, buys us two further months under the statute. If we take them you will hear so before the first month is out, with the reason attached. There is no charge. A request that is manifestly unfounded or excessive can attract a fee or a refusal, and if we ever took that view we would set out the reasoning and tell you how to challenge it.

If we decline an operation in whole or in part, we will say which rule it ran into — a retention duty, another person's rights, legal privilege — rather than leaving you to guess.

30. Escalation to the ICO

Tell us first if something has gone wrong, because we can usually fix it faster than any regulator can direct us to. If that gets you nowhere, the Information Commissioner's Office is the UK supervisory authority and you are entitled to complain to it.

Complaining to the ICO costs nothing and does not require you to instruct anyone to act for you. Your right to go to court for a remedy is unaffected by anything in this notice.

31. Revisions

This document is versioned like the schemas it describes. The version and the date it took effect are printed at the top, and each revision replaces the one before it in full rather than accumulating amendments at the end.

Changes that alter what we do — a new entity, a longer retention rule, a sub-processor in a new country — are published here before they take effect, and anyone with an open account or a live engagement is told by email. Changes that only make the wording clearer take effect when published. Superseded versions are kept, so ask if you need to see the text that applied on a particular date.

32. Contact

One address covers privacy questions, rights requests, breach reports and complaints about how this was handled:

Prospective clients wanting our processing terms, our sub-processor list or a transfer risk assessment before signing anything should ask at the same address; we would rather answer those questions during scoping than after.