Legal

Privacy Policy

Revision 2.0 — in force 5 August 2026, last revised the same day

This policy explains how THINKPOD STUDIOS LIMITED ("Thinkpod Studios", "we", "us") handles personal data — on our website, in our client work, in the systems we build and maintain for other organisations, and in the mobile applications we publish under our own name.

A development studio touches personal data in more ways than most small companies: enquiry correspondence, contracts, access to clients' live systems, and software that runs on other people's phones. Each is a different relationship with a different legal shape, so this document is longer than a template.

1. Introduction and scope

This policy applies to personal data we process in connection with: the website at thinkpodstudios.co.uk and the correspondence it generates; our commercial relationships, from enquiry through contract to support; the design, build, deployment and maintenance of software for clients, including access we are given to systems holding personal data; and applications we publish under our own name and developer accounts.

It does not govern how a client uses a system we built once it is under their control (section 19), third-party sites we link to, or data you have chosen to publish publicly.

Read it alongside our Cookie Policy and Terms. On engagements where we are somebody's processor, whatever data processing agreement got signed for that job outranks this page, which then stands only as a description of how the studio generally behaves rather than the particular instructions binding us. Everything below rests on three pieces of legislation — the UK GDPR; the Data Protection Act 2018, shortened here to DPA 2018; and the 2003 Privacy and Electronic Communications (EC Directive) Regulations, shortened to PECR.

2. Which parts apply to you

Different readers arrive here for different reasons, and nobody needs the whole document.

• Website visitors — sections 7 and 22, plus the Cookie Policy.
• Anyone who emailed us about a project — sections 8, 24 and 27.
• Clients and contacts at clients — sections 5, 9 and 12 to 18.
• Users of an app we published ourselves — sections 29 to 36.
• Someone whose records happen to live inside a system we look after for another organisation — sections 5, 12 and 38.
• Suppliers, contractors and collaborators — sections 10 and 24.
• People who wrote to us about work — section 11.

Everyone has the rights in section 27 and can complain to the regulator under section 28.

3. The studio behind this policy

Where this policy says we are the controller, the controller is:

THINKPOD STUDIOS LIMITED
Registered in Northern Ireland, Company No. NI737566
Companies House holds an address for us under NI737566, and that entry on the public register is the one to use when a document has to be formally served.
Email: studio@thinkpodstudios.co.uk

"Thinkpod Studios" is a trading name of THINKPOD STUDIOS LIMITED. The same company operates the website, signs client contracts and holds our Apple and Google developer accounts.

The privacy contact. Privacy questions, rights requests, sub-processor queries, breach reports and complaints all go to studio@thinkpodstudios.co.uk, monitored by the company's directors, who hold responsibility for data protection personally. To write instead, use the registered office above and mark the envelope "Data protection". For anything urgent, put "Urgent — data protection" in the subject line; we acknowledge within one working day.

4. Responsibility, DPO position and ICO registration

Who is responsible. Data protection sits with the directors. In a studio this size that is not a formality: the people who write the code decide what the code touches. We maintain an Article 30 record of processing activities, review it when we take on a new kind of engagement or supplier, and review this policy at least annually.

Data Protection Officer. Article 37 UK GDPR sets a narrow trigger for appointing one — public authorities, plus organisations whose central activity is either watching people regularly and systematically at scale or handling sensitive and offence records at that same scale. A private software studio building products to order meets none of those descriptions, and no large-scale sensitive processing happens here, so the duty has not arisen. Should the work ever change shape, an officer gets appointed and named on this page. Until then the contact route above reaches the same people.

ICO registration. An annual data protection fee is owed to the Information Commissioner's Office by most organisations. One instrument sets that up: the 2018 Data Protection (Charges and Information) Regulations. Where that duty reaches us we are registered, the fee is paid, and the entry is kept up to date. We deliberately do not print a registration number here, because a number on a web page drifts out of date; the ICO's public register of fee payers is searchable by company name at ico.org.uk, or ask us and we will confirm in writing.

Impact assessments. Where a project is likely to result in high risk to individuals — large-scale profiling, systematic monitoring, or special category data at scale — we carry out a DPIA under Article 35 before development starts. Where we are processor, the DPIA is the client's and we assist under Article 28(3)(f) with the technical detail it needs. We will say plainly if we think one is required and has not been done.

5. Which hat we are wearing

A controller is whoever settles the why and the how of a piece of processing, picks the lawful basis under which it runs, and stands answerable to the people involved and to the regulator. A processor works to instructions the controller wrote down and serves no end of its own: it cannot repurpose what it holds, cannot hang onto it once the job finishes unless a law says so, and has to be under an Article 28 contract. Hand a processor a rights request and its duty is to route it onward, not to answer it. What separates the two roles is who decides — not whose hardware the records happen to sit on.

We are the controller for: website visitors and technical data from serving the site; enquiries, proposals and correspondence with prospective clients; contract, billing and account-management data, including personal data of named contacts at client organisations; supplier, contractor and collaborator records; approaches about work; all personal data processed by applications published under our own name and by our own hosted services behind them; and our own accounting, tax and compliance records.

We are the processor for: personal data inside a client's systems that we access in order to build, migrate, test, debug, deploy or maintain them; databases, exports, logs, tickets or backups a client shares for a defined technical purpose; personal data flowing through an application we built for a client and which the client operates, including one published under the client's own store account; and hosting or infrastructure we administer where the client decides what is stored in it.

Which applies to you. If you gave your data to us, we are almost certainly the controller. If it reached us because an organisation you deal with asked us to work on their system, that organisation is the controller and we are the processor — see section 38. Sections below are labelled with the role they describe.

What we never do as processor. We do not use client data for our own purposes: no mining for insight, no model training, no aggregate products, no sample or demonstration data. Public case studies use synthetic content and the client's permission.

6. What we process as controller

Role: controller

Sections 7 to 11 are our controller-side inventory: what the data is, example fields, its source, why we process it, the lawful basis with its article reference, retention, and recipients.

Where we rely on legitimate interests under Article 6(1)(f), we name the interest and have carried out and documented a balancing test — weighing our interest against the individual's interests, rights and freedoms, including whether they would reasonably expect the processing. Where that balance fails to come out in favour of the processing, the basis goes unused. Ask and a summary of any such assessment can be sent over.

7. Website visitors and server logs

Role: controller

This site is a set of static pages with no login, no form and no basket — the only route to us is email, covered in section 8.

There is no analytics product on this site, no social pixels or share buttons, no advertising tags, and strictly-necessary security cookies only (see the Cookie Policy). The site does load a web font from Google Fonts, which discloses your IP address and user agent to Google as any third-party request would; if we move to self-hosted fonts we will update this line.

8. Enquiries and prospective clients

Role: controller

Please do not send live personal data at the enquiry stage. Briefs regularly arrive with real customer exports attached to explain a data model, or screenshots with real names in them. We do not need any of it to quote — send the structure, not the contents. If we genuinely need to see real data we will say so and put an agreement in place first. If you have already sent something like that, tell us and we will delete it and confirm.

9. Clients and contract administration

Role: controller

10. Suppliers, contractors and collaborators

Role: controller

We sometimes bring in a specialist — a designer, a native mobile developer, a security or accessibility reviewer.

Where a subcontractor will process client personal data they are engaged as our sub-processor on written terms no less protective than those we owe the client, and we remain fully liable to the client for their acts and omissions.

11. People who approach us for work

Role: controller

Please leave special category data out of an application — health, ethnicity, political or religious affiliation and the like. We do not want it and it plays no part in any decision; section 20 explains what happens if it arrives anyway.

12. What we process as processor

Role: processor

Building or maintaining somebody's system puts their customers, staff, members and users — or rather the records describing them — within our reach. None of the decisions were ours: what those records contain, the reason they exist, how long they stay, all of that was settled by the client. They are the controller; we are the processor.

The categories depend on what the system does. Across engagements they have included customer contact records, user accounts and authentication data, order and booking histories, support tickets, uploaded documents, application and audit logs containing user identifiers, and notification queues. We have no interest in the contents beyond making the software work.

The terms we work under. Before we are given access to a live system containing personal data we put written terms in place meeting Article 28(3) UK GDPR. Under them we may act only on what the client has written down for us, transfers included, unless a law overrides that; everyone we let near the system owes a duty of confidence; the safeguards catalogued in section 25 have to be running; no sub-processor joins without the client clearing it first, and intended changes reach them early enough to say no; we help with rights requests and with the duties in Articles 32 to 36; at the close of the engagement the client chooses whether their personal data comes back or is destroyed; and we hand over whatever evidence of compliance an audit calls for, and take part in it.

Rights requests. If your data sits in a client's system and you send us a request, we cannot answer it ourselves — that would mean acting outside the controller's instructions. We forward it without undue delay, tell you we have, and help the client answer it (section 38).

What we do not do. We do not copy client data to our own machines except where a specific agreed task requires it, and not after. We build nothing of our own from it, and we do not use it as training data for machine learning systems, ours or anyone else's. Live personal data is not pasted into AI-assisted coding tools.

13. The development lifecycle

Role: processor unless stated

"We may access customer data to provide support" is not an honest description of what a development studio does. Sections 14 to 18 set out the points in a build-and-maintain lifecycle where personal data is genuinely at risk. The principle running through them is data minimisation applied to engineering: the safest way to protect personal data in development is not to have it in the development environment at all.

14. Access to client production systems

Role: processor

Some maintenance cannot be done anywhere but production: a stuck queue, one customer's failed payment, a bug that appears only against real data. Our rules for that access:

• Named accounts, never shared ones, so every action is attributable; we decline a shared administrator login where an alternative exists.
• Least privilege — the narrowest role that does the job, read-only where reading is enough, scoped to one service where the platform allows.
• Time-bound where possible, with multi-factor authentication on every account that offers it; we prompt for revocation at the end of an engagement rather than waiting to be asked.
• No bulk export — we do not download a dataset to look at one record.
• Logging by the client's platform, which we expect and do not object to being audited against; where a system cannot log, we note when and why we went in.
• Purpose limitation — we look at the record we need. Curiosity is not a purpose.

Where an outage requires immediate elevated break-glass access outside normal hours, we take it, fix the problem, then tell the client what we did, what was visible and when the access was given up. Where a client asks us to administer the infrastructure account itself, we remain the processor for the data in it, apply the controls above to ourselves, and hand over ownership and credentials at the end of the relationship on request.

15. Test, synthetic and anonymised data

Role: processor

Our default is that development and test environments contain no real personal data. Wherever possible we generate fabricated records matching the shape of the real thing, with no connection to a living person. Synthetic data is not personal data, so UK GDPR does not apply to it, and it tests better because we can create the edge cases we need rather than hope they exist.

Anonymised extracts. Where a bug depends on the statistical shape of real data we may ask for an anonymised extract. Anonymisation must be irreversible to take data outside UK GDPR: dropping a name column while leaving a postcode, date of birth and rare attribute in place anonymises nothing. Where genuine anonymity is not achievable we treat the extract as pseudonymised personal data — still personal data, handled under the section 14 rules.

If a production copy is unavoidable — a migration, or a defect that reproduces nowhere else — the client authorises it in writing for a stated purpose; the copy is the minimum subset rather than the whole database; it is held encrypted on an encrypted machine or in an access-controlled environment, never on removable media, in personal cloud storage or in a repository; it is deleted as soon as the task ends and we confirm the deletion; and we record that it existed, when it was made and when it was destroyed. Documentation, screenshots, demos and case studies use synthetic data only.

16. Source code repositories

Role: processor for client repositories; controller for our own

Source code is not usually personal data, but repositories hold it more often than people expect: configuration and connection details that map where the data lives; seed and fixture files, which is exactly where a real customer export gets committed by accident; test snapshots and recorded API responses captured against a live system; log excerpts pasted into an issue; and commit metadata, which is permanent personal data about our own team.

• Client repositories are private by default, with access limited to people on the project.
• Secrets stay out of source control and are injected at deploy time (section 18); ignore rules and pre-commit checks catch credential-shaped and dataset-shaped files before they are committed.
• Fixtures are synthetic; where a real payload is needed to reproduce something, identifiers are redacted first.
• Where personal data is committed by mistake, a later deletion commit is not enough — the history still holds it. We treat it as an incident: tell the client, purge the object from history or rotate what was exposed, and record what happened.
• At the end of an engagement, repository ownership transfers to the client if not already theirs and our access is removed.

Where the platform is the client's choice it is their sub-processor and their agreement governs; where we choose it, it appears in section 22.

17. Error reporting from client systems

Role: processor

Applications report their own failures. That is how software gets fixed, and also a route by which personal data leaves a system without anyone deciding it should. A report typically holds a stack trace, application and runtime version, environment and timestamp; depending on configuration it can also carry the requested URL with query-string parameters, the signed-in user's identifier, request headers including session tokens, the failed request body, and local variable values captured at the exception.

So we configure it deliberately: scrubbing of passwords, tokens, authentication headers and payment fields at the client library before transmission; an internal user identifier rather than a name or email address, so a report ties to an affected account without exposing who it is; automatic capture of request bodies and local variables switched off unless a specific debugging need justifies it, and off again afterwards; retention set as short as the debugging cycle allows; and dashboard access limited to people on the project.

Where the client already uses an error reporting service we work within their configuration and contract, and flag anything over-permissive. Where we choose and operate it, it is our sub-processor, named to the client before use and subject to sections 22 and 23. Reporting from our own apps is a controller activity — see section 32.

18. Credential and secret handling

Role: processor

Credentials are not usually personal data. They are the keys to it, and a policy that describes data protection without describing key handling is not describing much.

• Secrets never go in source control — not in code, configuration, a commented-out line or a README.
• Secrets are not sent by email or chat. Where a client sends one anyway we use it, rotate it if we can, and ask for the message to be deleted; we prefer their secret manager, a platform invite or a one-time link.
• Storage is the platform's secret store or a dedicated password manager with a unique strong master credential and MFA — not a spreadsheet, note app or text file.
• Environments are separated — a development key must not open a production database.
• Rotation when a person leaves a project, when an engagement ends, and immediately on any suspicion of exposure.
• Machines have full-disk encryption, automatic screen lock, current updates and a firewall enabled; personal email and personal cloud storage are never used for client credentials or data.
• Offboarding produces a list of every credential and access grant we held, so the client can verify all of it was revoked.

19. Apps we build for clients

Role: processor

An application built for a client and shipped from that client's own App Store or Google Play developer account leaves the client as controller of every piece of personal data it touches — not us. The listing carries their name, the privacy policy linked from it is theirs and it governs, and the calls on what gets collected, why, for how long and where it goes are all theirs. Stay involved past launch under a maintenance agreement and our role is processor to them.

So: rights requests go to the client, and any reaching us are forwarded under section 12; the App Store privacy labels and Play Data Safety declaration are the client's, which we complete accurately on their behalf where asked, from what the code actually does; their analytics, crash reporting and backend providers are their responsibility, on which we advise but do not decide unilaterally; and this policy does not apply to that app.

The opposite case — an app published under our developer accounts, in our name — makes us the controller, and sections 29 to 36 apply in full. If we and a client jointly determined the purposes and means of processing we would be joint controllers under Article 26 UK GDPR and would have to agree and publish the essence of an arrangement. We operate none at present; if we enter one, it will be named here.

20. Sensitive records and offence records

Role: both

Special category data is the label for a defined group of particularly sensitive records:

• anything disclosing racial or ethnic origin;
• political opinions; religious or philosophical belief; membership of a trade union;
• genetic material, and biometric material where it is being used to identify somebody;
• health; and whatever concerns a person's sex life or sexual orientation.

Records about criminal offences sit separately again, governed by Article 10 UK GDPR together with section 10 and Schedule 1 DPA 2018.

As controller we do not intentionally collect, request or process any of it. The website collects none, the enquiry process needs none, contract administration needs none, and the apps we publish ourselves are not designed to collect it. If we ever built one that did, we would identify the Article 9(2) condition and the corresponding DPA 2018 Schedule 1 condition before a line of code shipped, publish an appropriate policy document where Schedule 1 requires one, and update this policy first.

If it is sent to us anyway — a health reason for a missed deadline, a diagnosis in a support message, a trade union role in a CV — we use it for no purpose, copy it into no structured record, and delete it once the message it sits in no longer needs keeping. Tell us and we will delete it and confirm. Where it unavoidably remains in correspondence we must retain, we hold it under Art. 9(2)(f), establishment, exercise or defence of legal claims, with the corresponding condition in Part 1 of Schedule 1 DPA 2018, and do nothing further with it.

As processor it depends on the client. A clinic's patient records or a charity's beneficiary files are special category data; the client is controller and identifies the Article 9 and Schedule 1 conditions, and our job is to handle it securely on their instructions. We apply heightened care — tighter production access, no copies leaving the client's environment, synthetic data mandatory rather than preferred, and an expectation that a DPIA was completed before we start. No written processor terms, no access.

21. Children's data

Role: both

Our website, services and commercial relationships are aimed at organisations and adults. We do not market to children and hold no children's data on the controller side.

Nothing we publish under our own name is aimed at children under 13, and we do not knowingly gather anything personal from them. Each carries an age rating on its store listing, set honestly against what the app does. Where an app could appeal to children we design it to meet the ICO's Age Appropriate Design Code — minimisation by default, no nudge techniques, no profiling, privacy-protective defaults — rather than relying on an age gate alone. A parent or guardian who suspects a child has handed something over should write in: we will erase it quickly and tell you once it is gone.

Where we build a system for a client aimed at children, the client is controller and sets the age assurance and consent model; we build to the standard the Code requires and raise it with them if the design falls short.

22. Who else ever sees it

Role: both

The roster of outside companies is kept short on purpose. Every one of them works to instructions we have written down, under terms signed in advance, and not one is free to turn the data to any end of its own.

Some entries are described by function rather than brand, because the stack for a given client project is chosen with that client and named in the processor terms for that engagement. Any client or app user can email us and we will name every current provider in writing.

Keeping the list current. We review this table whenever we change a provider and at least annually. On processor work, a client hears from us in writing before any sub-processor is added or swapped, with long enough to push back; where the objection rests on sound data protection reasoning we go looking for another route, and should none exist the client can walk away from the affected service without penalty. Where we act as controller, a material change affecting app users is announced under section 39 before it takes effect.

Where the line sits. Personal data here is never sold, never rented or passed along to fuel somebody else's marketing, never fed into an advertising network or a data brokerage, and never disclosed to anyone outside the list above unless a law leaves us no choice. Where a legal demand looks unlawful or overbroad we challenge it, and we tell the affected controller or individual unless prohibited.

23. International transfers

Role: both

Some providers above are established outside the UK or operate global infrastructure. Where personal data is transferred outside the UK, Chapter V UK GDPR requires an appropriate safeguard.

Transfer risk assessments. A contractual mechanism alone is not enough. Leaning on the IDTA or the UK Addendum comes after an assessment, not before one. We weigh which records travel and how sensitive they are; the destination, and what its legislation lets officials there compel; how the provider has behaved when asked for more than it should give; and which extra measures pull the leftover risk down. Where the assessment does not come out acceptably we look for a UK or EEA region, a different provider, or a way of doing the work without the transfer.

Supplementary measures: encryption in transit and at rest; UK or EU processing regions where offered, the default for our own app infrastructure; minimising what is transferred, in particular keeping identifiers rather than names in diagnostic payloads; and provider commitments to notify us of government access requests where permitted.

As processor, transfers are made only on the client's documented instructions; the transfer decision is theirs as controller, and we tell them which mechanism the provider offers and what our assessment found.

24. How long anything survives

Role: both

We keep personal data only as long as the purpose needs or the law requires, whichever is longer, then delete or irreversibly anonymise it.

Where data is needed for a legal claim, or a regulator or court requires preservation, we keep it until the matter concludes — and only what the matter needs.

25. Security measures

Role: both

Article 32 UK GDPR requires measures appropriate to the risk. What follows is what we actually do.

25.1 Technical measures

• Encryption in transit: TLS with modern cipher suites and HSTS on the website; TLS on every connection to a provider, database or API we administer; key-based SSH rather than passwords for server access.
• Encryption at rest: full-disk encryption on every work machine, and platform encryption at rest on managed databases, object storage and backups.
• Access control: individual named accounts; MFA on every account that supports it, including developer, hosting, source control and email; roles scoped to the narrowest permission; production separated from development; periodic review of who holds what.
• Logging and monitoring: platform audit logs where available; authentication and administrative actions logged; alerting on failures for services we operate; logs configured not to capture credentials or, where avoidable, personal data.
• Backups: automated, encrypted, on a rolling retention, with restores tested rather than assumed.
• Endpoints: automatic screen lock, current updates, host firewall on, no client data on removable media.

25.2 Secure development practices

• Code review before merge for anything touching authentication, authorisation, payments or personal data.
• Dependency vulnerability scanning with automated alerts, and prompt patching.
• Parameterised queries and framework protections against injection; output encoding against cross-site scripting; CSRF protection on state-changing requests; security headers as standard configuration.
• Authentication built on established libraries rather than hand-rolled; passwords stored with a modern password-hashing function, never reversibly; authorisation checked server-side on every request.
• Privacy by design and by default under Article 25, and separated development, staging and production environments and credentials.

25.3 Organisational measures

• Everyone with access to personal data is bound by written confidentiality obligations that survive their engagement; access is need-to-know for a defined task and revoked when it ends.
• Responsibility sits with the directors; anyone working on a client system is briefed on sections 14 to 18 first.
• Supplier due diligence before any provider or subcontractor gets access: what it does with data, where it processes it, its security posture, whether its terms meet Article 28, and what transfer mechanism it offers.
• An Article 30 record of processing activities, reviewed on change and at least annually; documented incident response (section 26); and a digital clean-desk habit, so client data is not left in downloads folders or chat threads after a task ends.

25.4 Honesty about limits

No set of measures makes a system immune, and we do not run a 24-hour security operations centre. What we have is a small attack surface, very few people with access, no accumulation of data we do not need, and a practice of deleting things. Data never collected cannot be breached, and that is the control we lean on hardest.

26. When something goes wrong

Role: both

A personal data breach, in the sense the legislation uses, is any security failure that wipes out personal data, alters it, mislays it, or opens it to somebody who had no business reaching it — whether that came about by accident or because a person acted unlawfully. Hacking is only one way in. A message sent to the wrong recipient, a laptop left on a train, a repository whose visibility was set wrong, and a deletion nobody meant to run all qualify.

Our process. Anyone who becomes aware reports it to the directors immediately — no internal threshold and no penalty for a false alarm. We contain before analysing: revoke credentials, rotate keys, take the component offline. Assessment follows containment: which records, belonging to whom, in what volume, by what route, recoverable or not, and what is likely to follow. Article 33(5) requires the incident logged whether or not anybody has to be told, and that log stays with us six years. Notification runs as set out below, and the fix goes in at the root rather than the symptom.

As controller, once a breach looks likely to put somebody's rights and freedoms at risk, Article 33 has us raise it with the ICO promptly, and inside 72 hours of the moment we realised, wherever that is achievable. If full information is not available in time we notify within the deadline anyway and supply the rest in phases, explaining the delay. Should the risk rate as high, Article 34 brings the affected people into it too, told without undue delay and in ordinary words: what took place, which records it touched, the steps we are taking, the steps open to them, and where to find us.

As processor, we notify the client without undue delay under Article 33(2), targeting within 24 hours of confirming a breach. We give them everything needed to make their own notification decision — what happened, when, which data and how many records, what we have done and what we recommend. Whether the regulator and the affected people get told is the client's call alone; we do not make that judgement on their behalf, and we do not slow them down in making it.

Telling us about a problem. Email studio@thinkpodstudios.co.uk with "Urgent — data protection" in the subject. We welcome good-faith reports from security researchers and will not pursue anyone who reports responsibly without exploiting the issue or accessing more data than needed to demonstrate it. We acknowledge within one working day.

27. Your rights

Role: controller — see 27.10 for the processor position

Where we are the controller of your personal data, UK GDPR gives you the following rights. Not every right applies in every situation; where one does not, we tell you which exemption we rely on and why.

27.1 To be informed

You are entitled to know who is processing your data, why, on what basis, for how long and who it goes to. This document is how we meet that duty. If something in it is unclear, tell us.

27.2 Access

Ask, and you can have confirmation of whether anything about you is held here, a copy of whatever is, and the further detail Article 15 lists — the purposes, the categories, who receives it, how long it stays, where it came from, and the rights you hold. Copies go out in an ordinary electronic format unless you would rather have something else, and another person's details may be blacked out of a document first. A first copy costs nothing.

27.3 Rectification

Anything wrong in our records has to be put right, and anything half-recorded has to be finished off, a supplementary statement being one acceptable way of doing it. If the flawed version already went to somebody else, we pass the correction on to them too, unless reaching them turns out to be impossible or wildly out of proportion to the point.

27.4 Erasure

You can ask us to delete data no longer necessary for its purpose, where you withdraw consent, where you object and no overriding ground exists, where processing was unlawful, or where the law requires erasure. The right is not absolute: we may refuse where we need the data for a legal obligation — accounting records being the usual example — or for legal claims. If we refuse we tell you which ground applies to which data, and delete everything not covered by it.

27.5 Restriction

Processing can be frozen at your request: while a challenge you have made to accuracy is being checked, while an objection of yours is under consideration, in place of erasure where the processing was unlawful but you would rather the records survived, or where a legal claim of yours still needs them although our own use has finished. While restricted we store the data and do nothing else with it without your consent, and tell you before the restriction is lifted.

27.6 Portability

For material you handed over yourself, held by machine, and resting on either your consent or a contract between us, you may take delivery in a structured and widely readable machine format, and have us send it straight to a different controller wherever the technology allows. In practice this covers content and account data in our own apps, exported as JSON or CSV.

27.7 Objection, and withdrawing consent

Any processing of yours that rests on legitimate interests can be objected to whenever you like, on grounds particular to your circumstances. Once you do, we have to halt it — the only ways out are showing compelling grounds of our own that outweigh your interests, rights and freedoms, or needing the records to bring or defend a legal claim. Object to direct marketing and there is nothing to weigh at all: the right is absolute, and we stop there and then, for good.

Where processing is based on consent — notification permissions, optional in-app analytics, keeping a speculative application on file — you can withdraw at any time, and it must be as easy to withdraw as to give. Withdrawal does not affect the lawfulness of processing before it. Where consent came from a device permission prompt, revoking that permission in system settings withdraws it.

27.8 Automated decision-making and profiling

Where a decision carrying legal weight — or something that lands on you nearly as hard — would be reached by software on its own, Article 22 UK GDPR lets you refuse to be subject to it, ask that a person step into the loop, put your own case, and challenge what came out. Our position: we carry out no solely automated decision-making of that kind and do not profile individuals. Nothing we do decides anything significant about a person without a human involved, and we do not score, rank or categorise individuals. If we ever introduce processing that engages Article 22 we will update this policy first, explain the logic involved and its significance and consequences, and provide the safeguards the Article requires.

27.9 How to exercise a right

• How: email studio@thinkpodstudios.co.uk or write to the registered office. There is no form, and you need not cite the legislation.
• What helps: say which right you are exercising, and if you want only part of your data, say which part.
• Identity verification: where we have reasonable doubts we ask for enough to satisfy ourselves, usually no more than that you can send and receive email at the address the data is connected to. We ask for proportionate proof only, not identity documents where a simpler check will do; the one-month clock pauses until we have what we need.
• Someone acting for you: a solicitor, relative or advocate can request on your behalf with written authority; we may still confirm with you directly.
• Timing: we respond within one month of receiving the request and any verification. Complexity, or several requests arriving together, can buy us up to two further months, provided we tell you inside that first month that the extension is being taken and what lies behind it.
• Cost: free. The only openings for charging an administrative sum, or declining altogether, are a request that is plainly baseless or out of all proportion — repetition being the usual example. Any refusal is explained, with your right to complain to the ICO and to seek a judicial remedy.

27.10 If we hold your data as a processor

Where your data reached us because we work on a system belonging to an organisation you deal with, that organisation is the controller and your rights are exercised against them. We pass any request we receive to them without undue delay and tell you we have. See section 38.

28. Taking it to the regulator

Role: both

Unhappy with how your personal data, or a request of yours, was handled? Raise it here first, at studio@thinkpodstudios.co.uk. It gets looked at properly, answered inside a month, and where we got something wrong you will be told what is changing as a result. None of that is a precondition, though: the UK supervisory authority is open to you whenever you choose, without passing through us at all.

Information Commissioner's Office
Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF
Telephone: 0303 123 1113
Website: ico.org.uk

Complaining to the ICO does not affect your right to an effective judicial remedy, or to seek compensation for damage caused by a breach of data protection law.

29. Our own mobile apps: scope

Role: controller

Sections 29 to 36 apply to applications published under our own name and developer accounts — listings where the seller is shown as THINKPOD STUDIOS LIMITED or Thinkpod Studios. For those we are the controller and this is the policy linked from the listing. They do not apply to apps we built for a client and the client publishes; section 19 explains that split.

Our apps are built to collect as little as possible: no advertising SDKs or advertising; no third-party tracking SDKs and no cross-app or cross-site tracking; no data brokers; no sale or sharing of personal data; no location, contacts, call log, SMS or health access; no account unless a feature needs one; and on-device processing wherever a feature can work on-device.

Any individual app uses only a subset of what follows, and none collects a category this policy does not list. Where an app would process anything beyond it, we update the policy before release. The App Store privacy labels and Google Play Data Safety form for each app match this policy; if you spot a discrepancy, tell us and we will correct it.

30. App permissions

Role: controller

We request a permission only when a feature needs it, with an explanation, rather than in a burst at first launch. Every permission is optional: declining disables one feature and leaves the rest working, and we do not re-prompt after a refusal.

Revoking a permission after granting it is always allowed and never punished. Any permission a future app needs will be added to this table before it ships.

31. On-device and server storage

Role: controller

By default, content you create is stored on your device, in the app's sandboxed storage, protected by your device encryption. We cannot see it, and if you delete the app without enabling sync there is no copy for us to give back.

Where an app offers accounts, sync or sharing and you enable it, a copy is stored on infrastructure we operate so it can be restored, used on a second device or shared with someone you choose. Then we hold:

Where a region can be chosen, our app infrastructure is provisioned in the UK or EU, and backups are encrypted and follow section 24.

Your content is yours. We claim no ownership, and we do not read it, analyse it, train anything on it, or derive features or statistics from it. The only circumstances in which anyone here would look at your account contents are that you asked us to as part of a support request, or we are legally compelled to.

32. App analytics and crash reporting

Role: controller

Analytics, where an app has them, are limited to aggregate feature-event counts: how many installs used a feature in a period, which screens are reached, where a flow is abandoned. Events never contain what you created, never contain an advertising identifier, are not joined to your account to build a profile, and go to no advertising network.

Where we ask for consent in-app the basis is Art. 6(1)(a), off by default and withdrawable in settings. Where analytics are non-identifying aggregate counts with no prompt, the basis is Art. 6(1)(f); interest: understanding which features of our own product are used so we can improve it. Balancing test: identifies nobody, combined with no other source, never used for advertising, deleted on a short cycle. PECR applies to storage on your device, and where an item is not strictly necessary we ask first. Apple's App Analytics and Google's Play Console also give us aggregate anonymised install and retention figures, generated by the stores and controlled by your device diagnostics settings.

Crash reports contain the stack trace and exception; app version and build; device model, OS version, language and region; memory and storage available; the app's state — which screen you were on and what action was in progress; and a random installation identifier. They do not contain what you were working on, your name or email address, your contacts, your location, or an advertising identifier. Where a crash occurs inside a feature handling your content we log the shape of the failure, not the content; if a report arrives carrying something it should not, we delete it and fix the capture rule.

Basis: Art. 6(1)(f); interest: keeping our software working and safe for the people using it. Balancing test: technical data, minimised by design, retained 90 days, used only to fix defects; the alternative is shipping software we cannot debug. Not overridden. Where reporting runs through Apple's or Google's developer console it depends on your device diagnostics setting, which you can turn off. Reports are kept 90 days.

33. Identifiers and App Tracking Transparency

Role: controller

App Tracking Transparency. Apple defines tracking as linking data from your app with data from other companies' apps, websites or offline sources for advertising or measurement, or sharing data with a data broker. Our apps do none of that, so they show no ATT prompt. That is not an oversight or an avoidance — there is nothing to ask you for. If a future app ever met Apple's definition, it would request permission through the ATT framework first, would work fully if you declined, and this policy would be updated before release. On Android we do not request the AD_ID permission and declare no advertising ID use.

34. Google Play Data Safety and App Store labels

Role: controller

Both stores require a structured declaration of what an app collects and shares, shown before you install. For every app we publish, the Google Play Data Safety section declares the same categories, purposes, sharing and security practices as this policy, states that data is encrypted in transit, and confirms a deletion route exists. The App Store privacy labels declare the same under Apple's taxonomy — typically "Data Not Linked to You" for diagnostics and "Data Linked to You" only where an account exists, with nothing used for tracking. We complete both from what the code actually does, including anything a third-party component collects on our behalf, and review them at every release rather than at first submission. Where a taxonomy does not map neatly onto reality we choose the more conservative declaration. A mismatch between a store declaration and this policy is a defect — tell us and we will fix it.

35. Purchases and subscriptions

Role: controller, alongside the stores as independent controllers

Where an app offers a paid upgrade or a subscription, the transaction is handled entirely by the App Store or Google Play. We never see or receive your card number, bank details or billing address. Apple and Google act as independent controllers for the payment under their own privacy policies.

What reaches us is a purchase or transaction identifier and the product bought; the purchase date and, for subscriptions, renewal and expiry dates and whether it is active, cancelled, in a grace period or refunded; the store and storefront country, which determines tax treatment; a receipt or purchase token validating entitlement; and aggregate, non-identifying sales and payout reporting. Basis: Art. 6(1)(b) covers the feature you bought; Art. 6(1)(c) covers the tax and accounting side, which section 24 holds for six years.

Subscriptions are managed and cancelled in the store, not the app: on iOS, Settings → your name → Subscriptions; on Android, Play Store → Payments & subscriptions. Cancellation and refund terms are in our Terms.

If a future service were billed by us directly rather than through a store, a payment processor would handle card details and be named in section 22 first. We do not store card numbers in any scenario.

36. Closing an account and clearing it out

Role: controller

Both stores require a working deletion route, and so does Article 17 UK GDPR. Ours works two ways.

In the app. Every app of ours with an account has a deletion path at Settings → Account → Delete account, reachable without contacting us and not hidden behind a support conversation. It asks you to confirm once, because it cannot be undone, and offers to export your content first. Deleting the account deletes its synced content with it.

By email. Mail studio@thinkpodstudios.co.uk under the heading "Account deletion request", writing from the address the account itself runs on, and name the app it concerns. Where writing from that address is impossible, some other proportionate check gets worked out between us.

What happens. Live account records and synced content are erased within 30 days, normally within days. Sessions are invalidated and push tokens deleted immediately. Backups are purged on a rolling cycle so deleted data leaves them within 30 days, and a restored backup has the deletion re-applied. We confirm in writing if you asked by email. Content held only on your device goes when you delete the app — we cannot remove it for you because we never had it — and removing the app does not by itself delete a server-side account, because the store does not tell us you removed it.

Nothing else is kept: no shadow copy of your content, no retained email address for marketing, no "deactivated" account waiting to be restored.

37. Mail you asked us to send

Role: controller

We do not send marketing emails, operate a mailing list, or add people who contact us to one. If you email us about a project you will get a reply about your project and nothing else. We do not buy contact lists and do not use enquiry data for prospecting.

If we introduce a newsletter or product announcements it will be genuinely opt-in: a positive action by you, never a pre-ticked box, never bundled into an unrelated agreement. Every message will carry a working one-click unsubscribe taking effect immediately, honoured permanently through a minimal suppression record — your email address and the fact you opted out — held under Art. 6(1)(f) in the interest of respecting your objection. Even where PECR's "soft opt-in" for similar services to existing customers would be available, we will offer an opt-out at collection and in every message.

Transactional messages — a reply to an enquiry, an invoice, a security notice, a change to these terms, an outage notification — are not marketing and continue regardless.

38. If your data reached us through a client

Role: processor

What follows is written for someone who has never encountered this studio at all, yet whose records happen to live inside a system we built, or look after, on behalf of an organisation they genuinely do deal with.

That organisation is the controller, not us. They decided to collect your data, they decide what happens to it, and their privacy notice governs. We are a technical supplier acting on their instructions: your data is used for nothing of our own, we do not market to you, and we do not retain it after our work ends. Your rights are exercised against them, because we cannot lawfully answer a request outside our instructions — and doing so could mean disclosing data to the wrong person.

Come to us regardless and the request goes on to the controller without undue delay, with confirmation back to you that it has, the organisation named wherever we are free to name it, and whatever help they need from us in finding your records and acting on them. If you are unsure which organisation to approach and think we might know, ask and we will help you work it out. If an organisation is ignoring you, your route is to them and then to the ICO (section 28). If you believe we have mishandled data, tell us — we will investigate and notify the controller, whether or not you are our customer.

39. Revisions to this page

We review this policy at least annually, and whenever we change what we do — a new provider, a new app, a new type of engagement, a change in the law.

• Every change updates the "last updated" date and version marker at the top.
• Substantive changes — a new data category, purpose, lawful basis, sub-processor, longer retention period or new international transfer — also update the effective date and take effect only from it.
• Material changes affecting app users are notified in advance by an in-app notice on next launch and by email where we hold an address. Where a change requires consent we ask for it, and the processing does not start until you give it.
• Material changes affecting clients where we act as processor follow the sub-processor notice process in section 22, with an opportunity to object.
• Previous versions are kept and available on request.

We will not make a change quietly and rely on you re-reading the page.

40. How to contact us

For anything in this policy — a question, a rights request, a breach report, a request for the current sub-processor list, or a complaint:

Email: studio@thinkpodstudios.co.uk
Post:
Company number: NI737566, registered in Northern Ireland

The registered office is an administrative address, not a walk-in office — email first, or write and allow time for post to be forwarded.

We aim to acknowledge within two working days and to answer substantively within one month at the outside. See also: Terms · Cookie Policy