Ida Solutions & Partners Ltd, a company registered in England and Wales, is the controller of the personal data described below.
Contact: data@runida.com — for any question about this notice, or to exercise a right
under it.
We have not appointed a statutory Data Protection Officer. On the current analysis one is not required (Art. 37: we are not a public authority, and our core activities are not large-scale systematic monitoring or large-scale special-category processing).
It is NOT the notice for a studio's own clients, suppliers or contacts. See §9.
| What | Why | Lawful basis |
|---|---|---|
| Account data — name, work email, the org you belong to, your role | To create your account, authenticate you, and apply the right permissions | Contract (Art. 6(1)(b)) |
| Authentication data — sign-in events, session tokens | To keep the account secure | Legitimate interests (security) |
| Billing data — org, plan, usage volumes, spend | To invoice, and to keep the accounting records the law requires | Contract; legal obligation (Art. 6(1)(c)) |
| Support correspondence | To answer you | Contract; legitimate interests |
| Security and audit logs — who approved what, and when | To keep the Service secure, and to evidence what the Service did on whose authority | Legitimate interests (security, accountability) |
| Website analytics | To understand how the site is used | Consent, where required |
| Marketing to prospects | To tell you about the Service | Consent, or legitimate interests (B2B) |
What is NOT in this table is the mail, documents and business records a studio connects to Ida. That is the studio's data, they are its controller, and it is governed by the DPA. Keeping the two apart is not presentational: we classify every table in our database by which of the two applies, and the classification is enforced in our build (ADR-065 §6). We do this because the ICO's position is that a party unable to distinguish in its systems what it processes as controller from what it processes as processor is likely to be treated as a joint controller of all of it.
When a studio connects a mailbox, Ida builds an index of message headers — who, to whom, subject, date. Message bodies are never written to our database. When a task genuinely needs one, it is read live from the mailbox, used, and not kept.
Disconnecting a mailbox deletes the index and everything derived from it, not just the access tokens.
What the Service holds of your correspondence is the envelopes, not the letters.
Stored in the EU. One thing is processed in the US.
Your data is stored in the EU. Our servers and our database are EU-resident.
But AI processing happens in the United States. When the Service needs to read or write something intelligently, that content goes to our AI provider, and they are US-based. That transfer is covered by the Standard Contractual Clauses as amended by the UK Addendum — the safeguard UK law provides for exactly this, approved by the Information Commissioner, governed by English law with the ICO as the supervisory authority. We keep a Transfer Risk Assessment for it.
Our suppliers ("sub-processors"), each under a contract that binds them to the same protections and forbids training on our data. The current list is published at Sub-processors and we give 30 days' notice, by email and on that page, before adding or replacing one.
We also disclose personal data where the law requires it, or to establish or defend legal claims.
| What | How long |
|---|---|
| Account data | While your account is active, then deleted with your org |
| Your org's data | On exit: 30 days to export or change your mind, then erased |
| Accounting records | 6 years from the end of the relevant financial year (Finance Act 1998 Sch. 18 para 21), longer if HMRC opens an enquiry — the period runs to the latest of the anniversary, the enquiry's completion, or the closure of the enquiry window |
| Access and approval records | Kept while we may need to evidence what the Service did on whose authority, then deleted. You can object (§8) — this retention rests on our legitimate interests, not on a legal duty, so an objection releases it |
| Backups | See below |
Two things worth saying out loud, because most notices imply the opposite:
What survives an erasure survives per RECORD, not per customer. An invoice we are obliged to keep is not a licence to keep your correspondence. When we keep an accounting record we strip the identifying parts of it — the invoice keeps the org, the money and the period; it does not keep which of your staff did what.
Backups. When we delete your data, it goes from our live systems immediately. It may persist in encrypted backups until they expire on our rotation schedule — a maximum of 7 days. During that window the data is held beyond use: we do not access it, we do not use it to inform any decision about anyone, and it is deleted on schedule. If a backup is ever restored, deleted records are re-deleted automatically.
We tell you this because the ICO expects us to be absolutely clear about what happens to your data in backups when you ask for erasure — and because "deleted immediately" would be a simpler sentence and a false one.
You can ask us to: give you a copy of your data (access); correct it; delete it (erasure); restrict or object to how we use it; or give you a portable copy. Where we rely on consent, you can withdraw it at any time.
Some of these have limits:
Email data@runida.com. We respond within one month. If we need to verify who you are
or ask what you mean, the clock pauses while we wait (UK GDPR Art. 12A, in force 5 February
2026). If it is genuinely complex we may extend by two further months, and we will tell you
why within the first month.
You can complain to the Information Commissioner's Office (ico.org.uk, 0303 123 1113). You do not have to raise it with us first.
We hold information about you, and the studio — not us — is the controller of it.
You are likely to be the largest group of people this system touches, and the least likely to have heard of us.
If a studio uses Ida, our Service may hold your name, your email address, the subject lines and dates of correspondence between you and them, and things their staff have recorded about your working relationship. We hold it on their instructions and we do not use it for our own purposes.
Your rights are exercised against the studio, because they decide what is held and why. Contact them. If you contact us instead, we will not act on the request ourselves — we will tell them promptly and help them respond, which is what a processor is required to do and what any other answer would misrepresent.
If you do not know which studio holds your data, write to data@runida.com and we will do
what we can to point you the right way.
We will post changes here, and tell you about anything significant by email rather than waiting for you to notice.
Last updated: 27 August 2026