Privacy Policy

How ChooseOut LTD handles your personal data.

Last updated 10 November 2026. Operator: ChooseOut LTD. Replaces the 5 November 2026 version — see §15 for what changed.

This policy explains how the ChooseOut website (chooseout.ai), iOS app, Android app, and Chrome extension collect, use, store, and delete personal data. It applies to users in the United Kingdom and the European Economic Area.

Companion documents: Cookie policy · Sub-processor list · Account deletion guide · Terms of Service.

1. Who we are

ChooseOut is operated by ChooseOut LTD, registered in England and Wales (company number 16878082), with a registered office at Mallards, 1 The Street, Braughing, Ware, England, SG11 2QE. ChooseOut LTD is the data controller for personal data processed through ChooseOut.

Designated privacy lead: Archie William Dyer (Chairman). We have not appointed a formal Data Protection Officer; if and when our processing scale requires one under UK GDPR Article 37, we will update this notice and name the DPO here.

For privacy questions, to exercise any of the rights in §8, or to file a complaint, email [email protected].

2. Data we collect

We collect the following categories of personal data. Each category is tied to a purpose in §3.

• Identifiers. Name, email address, profile picture (provided by Google or Apple at sign-in); Firebase / Apple sign-in tokens; a keyed hash (HMAC) of your email, held so other members’ contact lists can be matched against it.
• Account preferences. Postcode, dietary preferences (vegan / vegetarian / halal / kosher / gluten-free etc — treated as “special-category data”), saved postcode shortcuts, notification preferences.
• Approximate location (only if you tap “Use current location”). We ask the device for a coarse position, use it once to work out which postcode you are in, and discard the coordinates. We never store latitude and longitude, and the feature is never used in the background — typing your postcode instead is always available.
• Contacts (only if you tap “Find friends from contacts”). The email addresses in your contacts are normalised and sent to us securely over HTTPS, matched in memory against the keyed hashes of our members’ emails, and the matches returned to you. We do not store your contacts — neither the addresses nor the hashes of them — and we do not use them for anything other than showing you which of your contacts already use ChooseOut.
• Usage data. Search queries, restaurants viewed, basket history, savings recorded, swipe-deck activity. Your recent searches are kept so the app can offer them back to you.
• Content you create. Restaurant reviews (star rating and comment), and the emoji and GIF messages & reactions you send in group chat. The chat accepts no free text — we store the emoji you picked or a reference to the GIF, never typed words. Also anything you write in the in-app feedback form, plus the screen you sent it from.
• Social data. Friends added, groups joined, shared baskets created.
• Birth year (group chat only). A one-time birth year, asked once before your first chat message or reaction, to apply the 16+ restriction — see §9.
• Device and diagnostics. App version, OS version, device model, anonymised crash and performance data via Apple’s MetricKit. Backend logs IP-address hashes (salted SHA-256) for security and abuse detection — not the raw IP.
• Install token. A random identifier generated by the app on first launch and kept in the device keychain. It is how your free monthly fee-check allowance is counted before you sign in, and how a guest session is merged into your account when you do. It is not an advertising identifier, it is not shared with anyone, and it cannot be used to recognise you in another company’s app.
• Installed-app signal. On each app open, we check on your device whether you have the Uber Eats, Deliveroo, or Just Eat app installed, and send us the result (yes/no per app). This is tied to your device, and to your account once you sign in. We use it to open the right app when you hand off, to recommend installing apps you don’t already have, and to measure how effective that recommendation is.
• Payment metadata. If you subscribe to ChooseOut Gold, we store your subscription state and the identifiers needed to keep it in sync with whoever took the payment. Where you subscribed in the iOS app, that payment is taken by Apple through the App Store, and we store the Apple transaction identifiers (original transaction ID and product ID) that Apple returns to us. Where you subscribed on the web, that payment is taken by Stripe, and we store a Stripe customer ID. In neither case do card details reach our servers — they are handled by Apple or Stripe respectively.

We do not collect any advertising data. The ChooseOut apps contain no advertising identifier of any kind — no Apple Advertising Identifier (IDFA), no Google Advertising ID — and we do not collect ad impressions, ad clicks or ad view duration. See §7.

3. Why we use it, and on what legal basis

Every purpose below relies on one of the UK GDPR Article 6 lawful bases. We do not bundle unrelated processing under a single “you agree to our terms” click.

4. Who we share it with

We do not sell your personal data. The full list of sub-processors — with role, country, transfer mechanism, and a link to their published Data Processing Addendum — lives on its own page so you can read it without scrolling through this notice and so we can keep it up to date independently:

→ Sub-processor list

We share nothing with any advertising company. Meta Platforms (Audience Network) and AppLovin were previously listed here as advertising recipients. Neither receives any data from us, and neither is in either app — the advertising software was removed from the iOS app and was never present in the Android app (§7) — so they have been removed from this notice and from the sub-processor list.

We may also disclose data where required by law, regulation, or a lawful request from a competent authority; to enforce our Terms of Service; or to protect users and the service from abuse or fraud.

5. International transfers

Most of our infrastructure runs in the European Economic Area: Hetzner Online GmbH in Germany hosts our application servers and database. PostHog (our analytics processor) is hosted in the EU. These transfers stay within the UK adequacy framework and need no additional mechanism.

The following processors are based in the United States. For each we rely on the UK Extension to the EU–US Data Privacy Framework as the transfer mechanism, after verifying the recipient’s active certification:

• Google LLC (Firebase Authentication, Cloud Storage, Gemini)
• Stripe, Inc. (payments)
• Cloudflare, Inc. (R2 storage; CDN)
• Salesforce / Slack Technologies (operational alerting)
• Raintank, Inc. d/b/a Grafana Labs (telemetry)
• Resend, Inc. (transactional email)

For US recipients not on the DPF list (Apple, Inc. for Sign in with Apple; Klipy / KIKLIKO, Inc. for GIF search in group chat; specialist ML vendors we use behind the scenes), we use the UK International Data Transfer Agreement (IDTA) and document a Transfer Risk Assessment per recipient. The full mechanism per processor is shown on the Sub-processor list.

Meta Platforms, Inc. and AppLovin Corporation appeared on these lists as advertising recipients in earlier versions of this notice. Neither receives any data from us and both have been removed — see §4 and §7.

6. How long we keep it

We operate a two-tier retention model. The first tier is identifiable, time-bound. The second tier is anonymised and may be kept indefinitely as aggregate analytics — once anonymised it is no longer personal data under UK GDPR Recital 26.

Identifiable (“live tier”) retention

• Account data (profile, dietary prefs, postcode, friends, basket history, saved baskets, reviews): for as long as your account is active. Cleared immediately on account deletion.
• Group chat messages & reactions (emoji + GIF): 365 days from posting, then automatically deleted. Cleared immediately on account deletion. Reports of harmful content are retained up to 12 months as a moderation audit trail.
• Search history: 183 days (6 months). Used for personalisation, ranking model training, and search-quality work. This cap is set by our external data-processing specification, which limits individual search queries to 6 months; it supersedes the 365-day figure argued in our internal Legitimate Interest Assessment, which predates that requirement and is being reconciled.
• Ranking + suggestion telemetry, swipe events: 365 days.
• Product analytics events (only collected if you accept the Analytics category): 90 days.
• Crash and performance diagnostics: 90 days.
• Error logs: 30 days. Request bodies are PII-scrubbed before persistence — emails, passwords, tokens, postcodes, queries are replaced with [REDACTED] markers.
• Installed-app signal (which delivery apps you have installed, checked on each app open): no retention limit is currently applied, and it is not removed when you delete your account. This is a known gap we are correcting; disclosed here for completeness rather than waiting for the fix.
• Reviews you write: for as long as your account is active, then cleared on account deletion. Reports of harmful content are retained up to 12 months as a moderation audit trail.
• In-app feedback: up to 24 months, so we can come back to you and see whether a problem you reported was fixed.
• Birth year (the 16+ chat check): for as long as your account is active. Included in your data export and deleted with your account.
• Install token: lives in your device keychain until you delete the app. The server-side allowance rows it keys are cleared on account deletion.
• Approximate location: not retained at all. The coordinates are used once to resolve a postcode and discarded; only the resulting postcode is stored, with your account preferences.
• Contacts: not retained at all — matched in memory and discarded with the request.
• Advertising identifiers and ad-interaction data: none. We hold no advertising identifier and no ad-interaction data, so there is nothing to retain — see §7.
• Billing records (Apple transaction identifiers or Stripe customer ID, plus subscription metadata): up to 7 years, to meet HMRC tax-record requirements.
• Backups (pgBackRest → Cloudflare R2): 7-day rolling window of full backups plus 4 incremental snapshots. Erasure requests propagate as the window rolls forward — we do not selectively edit backups (the standard UK GDPR Art. 17(3)(e) backup exception).

Anonymised (“corpus” and “_anon” tier) retention

After the live-tier window closes, telemetry rows pass through an irreversible anonymisation step before either being deleted or copied into “_anon” mirror tables. User identifiers are dropped (replaced by signup-month + days-since-signup so we can still compute cohort retention). Raw search queries become length + token count. Full postcodes become outcodes (e.g. SW1A). A separate aggregate query corpus keeps per-query counters only for queries seen at least five times (k-anonymity floor). These tables are not personal data and have no time limit.

7. Cookies, on-device storage, and analytics

On the website, the cookie banner asks for your consent before placing anything non-essential. Strictly necessary storage (the session cookie that keeps you signed in, your postcode for finding nearby restaurants, your in-progress basket) does not require consent because it is part of the service you have asked for. Everything else (functional preferences, product analytics, advertising) is off by default and lights up only when you accept it.

The full table of cookies and similar storage — with names, purposes, lifetimes, and which category each falls under — lives on the Cookie policy page.

Advertising and tracking

In plain terms: the ChooseOut apps do not show third-party advertising, do not use any advertising identifier — Apple’s IDFA or Google’s Advertising ID — and do not track you across other companies’ apps or websites.

The advertising software is gone, not switched off. Neither app contains any advertising SDK — the Google, Meta Audience Network and AppLovin components that earlier versions of this notice described were removed from the iOS build and never shipped in the Android one. There is no code left that could request an ad, read an advertising identifier, or show Apple’s App Tracking Transparency prompt, so you will never see that prompt from us. We collect no ad impressions, no ad clicks and no ad view duration, and we do no personalised (targeted) advertising of any kind.

The only promotional content in the apps is our own: a panel offering ChooseOut Gold. It involves no third party and no identifier.

Restaurant results are never paid placements. Nobody can pay to rank higher in ChooseOut, and nothing in a list of restaurants is an advert.

On the website, the ad slots in the page layout are only ever filled if we switch on Google AdSense. While it is off — which is the case today — no AdSense script is loaded and no advertising cookie is set. Were we to switch it on, nothing would load before you accepted the Advertising category in the consent banner, the ads would be non-personalised and use no advertising identifier, and we would update this notice first under §14. We do not combine any advertising data with your ChooseOut account, your search history, your dietary preferences, or your basket contents.

If we ever reintroduce advertising to the apps, we will say so here at least 30 days beforehand (§14), put a consent gate in front of it, and update our App Store privacy declaration to match. Until then, treat any older copy of this notice that describes IDFA collection, App Tracking Transparency, personalised advertising, Meta Audience Network or AppLovin as superseded.

8. Your rights

Under UK GDPR (and EU GDPR for EEA users), you have the right to:

• Access — receive a copy of the personal data we hold about you. Use the Data export button in your profile on the ChooseOut website, or email [email protected] from any platform. (A data-export control is not yet available inside the iOS app; until it ships, iOS users should use the website or email us.) We respond within 30 days as required by Art. 12(3).
• Rectification — ask us to correct inaccurate data. You can edit most fields directly in the app; for anything else, email us.
• Erasure (the “right to be forgotten”) — delete your account and all associated personal data, entirely inside the app. Open the Profile tab, then Settings, and use Delete account (in the Danger zone section on iOS). You confirm twice, and re-enter your password or re-authenticate with Google or Apple, before anything is deleted. The account deletion guide has the steps for each app and what to do if you cannot sign in.
• Restriction — ask us to pause processing while a dispute is resolved.
• Portability — receive your data in a machine-readable JSON format (the Data-export download is structured for this).
• Objection — specifically object to processing based on legitimate interest, or to direct marketing (absolute right; we will stop immediately).
• Withdraw consent at any time for processing where consent is the lawful basis — cookies and website advertising via the banner’s “Cookie settings” link, marketing via the unsubscribe path in each message, dietary prefs by clearing them in your profile. There is no in-app advertising consent to withdraw, because the apps serve no advertising (§7).
• Complain — to ChooseOut directly via our complaints procedure (Data & Use Act 2025 right, live 19 June 2026; submit one via the API endpoint POST /api/user/data/complaint exposed in the app or by emailing us), and / or to the UK Information Commissioner’s Office (ico.org.uk).

We acknowledge complaints within 72 hours and aim to resolve them within 30 days.

9. Children

ChooseOut is for users aged 16 and over — this is a binding clause of our Terms of Service.

We have completed and maintain a documented assessment of whether ChooseOut is “likely to be accessed by children” under the ICO’s Age-Appropriate Design Code. Our conclusion, reviewed annually, is that ChooseOut is not likely to be accessed by under-16s as a population: the product requires you to have your own delivery postcode, your own payment method (for Gold), and routinely complete adult-style ordering flows on the delivery platforms we redirect to. The full assessment lives in our internal compliance repository.

The ICO identifies self-declared age gates as “unlikely to be effective” age assurance, so we do not rely on one as our population-level assessment — the conclusion above rests on the nature of the service, not on asking users their age at the door. There is no age gate on signing up to ChooseOut or on the price-comparison features.

We do, however, apply a one-time birth-year check on group chat and reactions specifically. Chat is the highest-risk surface we operate, it is the one feature restricted to 16+ under our Terms of Service, and the Online Safety Act expects a proportionate measure there. Before you can send your first message or reaction, we ask for your birth year once and store it against your account. If it indicates you are under 16, chat stays blocked; the stored year cannot be overwritten by submitting a different one. We recognise self-declaration is a floor rather than robust assurance, and we treat it as a proportionate measure for this feature rather than as a substitute for the assessment above. Your birth year is included in your data export and is deleted with your account.

We apply child-friendly defaults to everyone regardless: geolocation is captured at postcode resolution only (never lat/lng), and our automated ranking has no legal or similarly significant effect under Art. 22A. The apps run no advertising software and read no advertising identifier (§7), so there is no ad profiling of anyone, child or adult.

If you have reason to believe a child under 16 has registered, email [email protected] and we will remove the account.

10. Automated decision-making

ChooseOut ranks search results, suggestions, and the swipe deck using machine-learning models trained on aggregate user behaviour. These rankings influence the order in which restaurants appear; they do not gate your access to anything — you can manually search, browse, and order any restaurant. Accordingly we do not consider this “solely automated decision-making with legal or similarly significant effect” under UK GDPR Art. 22A. If you believe a ranking decision treated you unfairly, email [email protected] and a human will review.

11. Security

We use HTTPS for all public traffic; passwords are handled by Firebase Authentication and never reach our servers; sensitive on-device data is stored in the iOS Keychain (WhenUnlockedThisDeviceOnly); backend logs are PII-scrubbed at write time; service-account keys live in restricted-permission filesystem locations outside the source tree. We rotate keys after staff changes and run annual external security reviews. No system is perfect; if you suspect a security issue, please email [email protected] with the subject line “security disclosure”.

12. Data breach notification

If we suffer a personal-data breach that poses a risk to your rights and freedoms, we will notify the UK ICO within 72 hours of becoming aware (Art. 33). Where the breach is likely to result in a high risk to you specifically, we will also notify you directly without undue delay (Art. 34), unless the data was strongly encrypted at rest or we have applied measures that remove the high risk.

13. The ChooseOut browser extension

The ChooseOut browser extension is optional, and separate from the website and the mobile apps. It does one thing: when you send a basket from chooseout.ai to Uber Eats, Deliveroo or Just Eat, it re-creates that basket on the delivery site so you do not have to add every dish again by hand. It does nothing until you send a basket, and it stops at the basket — it never reaches checkout, and never submits an order or a payment.

It runs only on ubereats.com, deliveroo.co.uk and just-eat.co.uk, and only after a basket is sent from chooseout.ai. It does not read, monitor or act on any other site you visit.

What it handles while a transfer runs

• Your basket. The dishes, quantities and options you chose on ChooseOut are put into the delivery site’s basket, and the extension reads that site’s menu and basket to check what actually landed.
• Your delivery postcode. Taken from your ChooseOut basket and used to set the delivery site’s location. For Deliveroo only, the postcode is sent to api.postcodes.io (a UK public postcode lookup) to obtain map coordinates, because Deliveroo sets its delivery location by coordinates rather than by postcode.
• A 30-minute hold. The basket you sent is held in the extension for 30 minutes so the transfer can be retried or resumed, then discarded automatically.

The run report

When a transfer finishes, the extension sends us a short report so we can tell which dishes the automation fails on and fix it. You are asked for consent before anything is stored or sent, and nothing is sent if you decline.

A report contains: which delivery site was used, the ChooseOut restaurant and item identifiers, quantities, how many options each item had, whether each item was added, how long the run took, the extension version, your browser type, and a random install id. It is sent to chooseout.ai and on to PostHog, our product-analytics processor (see §4 and §5).

It contains no name, email address, account, delivery address, item names, prices or login details, and it is sent without cookies. The extension reads the address of the delivery-site tab in order to work, but never stores or transmits it.

The install id, and why we call these reports pseudonymous

The install id is a random identifier the extension generates on first use. It is not an advertising identifier, it is not shared with anyone, and it cannot be used to recognise you in another company’s product. It exists so that several reports from the same browser can be recognised as one sequence.

Because a report carries that id alongside restaurant and item identifiers and times, it could in principle be joined to your ChooseOut account activity. We therefore call these reports pseudonymous rather than anonymous, and two limits apply:

• You can switch them off. The extension’s Settings page (the Settings link at the bottom of its popup, or Options on its toolbar icon) has “Send run reports to ChooseOut”. Switching it off stops any further reports and deletes both the queued reports and the install id. Switching it back on mints a new install id, so reports from before and after cannot be linked through it. Removing the extension withdraws consent entirely.
• They are deleted after 90 days. Extension run reports older than 90 days are deleted by our nightly retention process (see §6).

Limited Use

The ChooseOut browser extension’s use of information received from your browser adheres to the Chrome Web Store User Data Policy, including the Limited Use requirements. It uses that information only to move your ChooseOut basket into your chosen delivery site, and to tell ChooseOut whether each item was added.

ChooseOut is not affiliated with, endorsed by, or partnered with Uber Eats, Deliveroo or Just Eat.

14. Changes to this policy

We may update this policy from time to time. Material changes will be announced in the app or by email at least 30 days before they take effect, and the “Last updated” date at the top will move accordingly. Minor non-material edits (typos, link fixes) may land without prior notice.

15. What changed

10 November 2026

Adds §13, covering the ChooseOut browser extension. The extension was already named in this policy’s scope, but what it does with your data was not described. The new section discloses the run report and the consent gate in front of it, the random install id and how to clear it, the delivery postcode sent to api.postcodes.io for Deliveroo, the 30-minute hold on a sent basket, 90-day deletion of run reports, and the Chrome Web Store Limited Use commitment. No processing changed; this is disclosure of behaviour already shipped. Sections 13–15 of the previous version are renumbered 14–16.

5 November 2026

This revision brings the notice back in line with the software. Everything below is a correction of fact or a disclosure that should already have been here — no new processing is introduced, and in the biggest change we are removing the description of something we no longer do:

• §2, §3, §4, §6, §7, §9 — advertising and tracking removed throughout. This notice described collecting Apple’s Advertising Identifier (IDFA) behind an App Tracking Transparency prompt, serving personalised advertising, collecting ad impressions and clicks, and disclosing advertising data to Meta Platforms (Audience Network) and AppLovin. None of that is true of the app. The advertising software has been removed from the build entirely — there is no advertising SDK, no advertising identifier, no ATT prompt and no personalised advertising — so the descriptions, the lawful-basis rows, the two named recipients and the advertising-retention entry are all gone, replaced by a plain statement of what the app actually does. §7 now says so in one sentence at the top.
• §2 and §3 — contacts matching corrected. This notice said contact addresses are “SHA-256 hashed on-device” and that we “only ever receive hashes, never plaintext”. That is not what the app does: the addresses are normalised and sent to us over HTTPS, matched in memory against the keyed hashes of our members’ emails, and discarded. The matching is still only ever triggered by you tapping “Find friends from contacts”, and we still do not store your contacts — but the notice now describes the real mechanism.
• §2, §3 and §6 — five categories added that were already being collected: the coarse location used once to resolve a postcode (coordinates discarded), the keychain install token that counts your free fee-check allowance and merges a guest session into your account, in-app feedback, restaurant reviews as their own entry, and the one-time birth year behind the 16+ chat check, which was described in §9 but missing from the data table.
• §2 — the install token is now stated explicitly not to be an advertising identifier, because it is the only persistent device identifier we hold and the distinction matters.
• §4, §7 — “removed” corrected to say which app. The sentences above said the advertising components “have been removed from the apps”, which implied they had once been in both. They were removed from the iOS app and were never present in the Android app. Same correction on the Cookie policy and the Sub-processor list. The outcome is unchanged — neither app has any advertising software — but the history was wrong.
• §7 — the opening sentence said “the ChooseOut app” and named only Apple’s Advertising Identifier, which read as covering iOS alone while the paragraphs around it covered both. It now names both apps and both identifiers (IDFA and Google’s Advertising ID), which is what we can actually stand behind.
• §9 — “your own payment method (for Pro)” now reads “(for Gold)”. The tier was renamed in the 29 August revision and this one mention was missed, which left §9 contradicting §15’s own statement that the tier is named Gold throughout.
• §8 — the account-deletion path was wrong. This notice said “Settings → Account → Delete account”. There is no “Account” submenu in either app: deletion is under Profile → Settings, in the Danger zone section on iOS. The right to erasure and the 30-day response time are unchanged — only the route described was inaccurate, and it now matches the account deletion guide. The re-authentication step is also described, since it is part of what happens.
• §8 — “cookies and advertising via the banner’s Cookie settings link” now reads “cookies and website advertising”, and says plainly that there is no in-app advertising consent to withdraw. The unqualified wording implied an in-app advertising consent that does not exist.

12 September 2026

This revision publishes together with the 3 September changes below, which had been prepared but not yet released. It corrects four places where this notice described the product inaccurately. All four are corrections of fact, not new processing — in each case we are describing what the software already does, or removing a description of something it does not do:

• §2 and §6 payment metadata: this notice previously described Stripe as the only payment path. Subscriptions bought in the iOS app are taken by Apple through the App Store, and we store the Apple transaction identifiers Apple returns. Both paths are now described, and the billing-retention entry covers both.
• §2 and §4 connected delivery-platform data removed: this notice described capturing Uber Eats, Deliveroo, and Just Eat session cookies on-device to fetch live checkout totals. That feature is not implemented and no such data is collected. The description has been removed rather than left standing as an inaccurate disclosure. If we build it, it will be disclosed here in advance under §14.
• §8 data export: the export control exists on the website, not yet in the iOS app. The right and the 30-day response time are unchanged; the route described is now the one that actually works for iOS users.
• §7 advertising labelling and restaurant exclusion: this notice said the results-feed ad slot “carries non-restaurant brands only, and is labelled Sponsored”. A visible “Sponsored” label is now rendered on every ad slot, and the app now enforces the restaurant exclusion itself in addition to the category blocks held with each advertising partner. §7 now states precisely where that exclusion is enforced rather than asserting the outcome.
• §9 children: this notice previously said we do not rely on a self-declared age gate. That is true of our population-level assessment, but incomplete — we do apply a one-time birth-year check on group chat and reactions specifically. §9 now describes that check, what it stores, and why we consider it proportionate for that feature.

3 September 2026

This revision corrects two figures against what we actually run, adds a data-collection disclosure that should have been here already, sharpens how we describe personalised advertising, and confirms two outstanding sub-processor/personnel items:

• §6 search-history retention corrected from 365 days to 183 days (6 months), matching what our retention job has actually enforced; the entry now cites the external cap that set that figure instead of the superseded 365-day internal assessment.
• New Installed-app signal disclosure: §2 describes the on-device check for Uber Eats, Deliveroo, and Just Eat and the fact that the result is sent to us; §3 adds its lawful basis; §6 states plainly that no retention limit is applied to it yet. This processing already runs in production and was not previously disclosed — this revision closes that gap rather than announcing a new feature.
• §2 and §7 now state explicitly that Advertising Identifiers (IDFA/GAID) are used specifically to serve personalised (targeted) advertising, rather than describing that purpose only implicitly; the Cookie policy is updated to match.
• §5 sub-processor list: Mint Data’s country is confirmed as the United States, its transfer mechanism is now confirmed as the UK Extension to the EU–US Data Privacy Framework, and its Data Processing Agreement is confirmed signed.
• §1 privacy-lead name updated to Archie William Dyer (Chairman) following a personnel change.

29 August 2026

This revision introduces advertising to ChooseOut. In line with §14, it is published at least 30 days before any advertising is served. The notable changes vs the 23 May 2026 version:

• New Advertising data category in §2, covering advertising identifiers and ad-interaction data.
• Three new rows in the §3 lawful-basis table, separating non-personalised advertising, personalised advertising, and ad measurement.
• §4 clarifies that advertising partners act as independent controllers rather than sub-processors, and states what is never shared with them.
• §5 adds Meta Platforms to the Data Privacy Framework list and AppLovin to the IDTA paragraph, and names AdMob and AdSense under Google LLC.
• §6 states the retention position for advertising data.
• §7 gains an Advertising subsection describing the SDKs now in use and the consent gate in front of them, replacing the previous statement that we ran no advertising SDKs. It also records that ChooseOut Gold subscribers see no ads at all.
• The subscription tier is named ChooseOut Gold throughout (§2 and the Sub-processor list previously said “ChooseOut Pro”).
• §9 restates the Children’s-Code position now that advertising SDKs are present.
• The Cookie policy gains a populated Advertising category; the Sub-processor list gains an advertising-partner section.

23 May 2026

This revision was prompted by a full internal compliance audit and the May-2026 commencement of the Data & Use Act 2025. The notable changes vs the 12 May 2026 version:

• Per-purpose table of lawful bases (§3) replaces the previous one-paragraph summary.
• Explicit consent flagged for dietary preferences (Art. 9 special-category data).
• Full sub-processor list moved to its own page with country + transfer mechanism for each, replacing the “hosting and infrastructure providers” generic line.
• International-transfer mechanism made specific: UK Extension to the EU–US Data Privacy Framework for the named US processors, UK IDTA for non-DPF US processors.
• Retention periods made specific (no more “typically”), with the new two-tier model documented.
• Children’s-Code stance: documented “not likely accessed by children” assessment + child-friendly defaults universally (no per-user age gate, per ICO guidance that self-declaration is ineffective).
• Automated decision-making (Art. 22A) explicitly addressed.
• Right to complain to ChooseOut directly added (DUAA right, live 19 June 2026), with the API/email path.
• Cookie banner gating PostHog + analytics moved from “essential cookies” framing to explicit-consent framing.
• Backup-retention disclosure (Art. 17(3)(e)) made explicit.

16. Contact

Privacy questions or rights requests: [email protected]

Operator: ChooseOut LTD, Mallards, 1 The Street, Braughing, Ware, England, SG11 2QE.