Privacy Notice

How we collect and use personal data, why we are allowed to, and what you can ask us to do about it.

Bidwhistle OÜ · Registry code 17567745 · Sepapaja tn 6, 15551 Tallinn, Estonia Version 1.0 · Effective 3 September 2026

1. About this notice

1.1 The short version

A summary, not a substitute for the rest.

  • Who we are Bidwhistle OÜ, an Estonian company running Bidwhistle, a procurement intelligence platform for small and medium-sized businesses in the UK and the EU. If you are a customer or user, we use your data to run your account, provide the Service, take payment, keep things secure and improve the product.

  • Public tender notices We collect notices from official government portals, and they often name a person at the buying organisation. We treat that as personal data, explain in section 6 exactly what we do with it, and you can object at privacy@bidwhistle.com — no account needed.

  • Olivia An AI assistant with a synthetic voice and an on-screen avatar. You are told you are speaking to an AI before you start. Where the conversation is processed is our provider’s choice and may be the United States; the session recording and the transcript are kept by that provider for 30 days, then deleted automatically (section 7).

  • The Response Workspace If you upload a tender pack so we can read it, draft an answer, explain a requirement or review a draft bid, the pack is passed to our AI provider and we store none of it. Tender packs often name people who are not our customers — see clause 7.8.

  • AI training We do not train AI models on your data, and we do not sell or share it for anyone else to train on. Our AI providers’ positions differ, and clause 7.3 sets out each one exactly rather than making a single promise we cannot stand behind.

  • Automated decisions None with legal or similarly significant effects made solely by automation. Fit scores help you decide; they decide nothing about you. We do not sell personal data or share it with ad networks.

  • Rights and complaints Access, correction, deletion, objection, portability and more (section 12). Complain to us, to the Estonian Data Protection Inspectorate, or to the ICO if you are in the UK (section 14).

1.2 Who we are

1.2.1 This notice is published by Bidwhistle OÜ, a private limited company (osaühing) registered in Estonia under registry code 17567745, registered office Sepapaja tn 6, Lasnamäe linnaosa, Tallinn 15551, Harju maakond, Estonia. We trade as Bidwhistle; our website is https://www.bidwhistle.com. That registered office is a service address provided by our company administration provider, not premises we occupy; written correspondence sent there reaches us, and the quickest route is always email.

1.2.2 “We”, “us” and “our” mean Bidwhistle OÜ. “You” means the individual whose personal data we handle — a website visitor, customer, Authorised User, person named in a tender notice, person named in a document a customer uploads, or prospect.

1.2.3 We are not required to appoint a Data Protection Officer and have not appointed one. Data protection questions go to privacy@bidwhistle.com, handled by the person responsible for privacy at Bidwhistle.

1.3 What this notice covers

1.3.1 How we handle personal data when we decide why and how it is processed — when we act as a Controller: our website, marketing, customer accounts, the AI Features including Olivia, and the Procurement Data we collect from public sources.

1.3.2 It does not govern personal data a customer puts into the Service for us to process on their instructions — see our Data Processing Agreement (https://www.bidwhistle.com/legal/dpa) — or third-party sites we link to, including the government portals.

1.4 The three roles we play

  • Role: 1. Controller of relationship data When it applies: Visitors, prospects, customers, Authorised Users, people who contact us or speak to Olivia Who decides why the data is used: We do Rules: This notice

  • Role: 2. Processor of Customer Data When it applies: Notes, saved searches, draft bids, tender packs uploaded to the Response Workspace, and anything else created inside a customer’s account Who decides why the data is used: Our customer does; we act on instructions Rules: The Data Processing Agreement, and clause 7.8 for uploads

  • Role: 3. Controller of Procurement Data When it applies: Personal data published inside public tender and award notices — typically a named contact at a public buyer Who decides why the data is used: We do. Nobody instructs us; we chose to collect it Rules: This notice, section 6

1.4.1 Where we act as a Processor and you ask us to exercise a right over data in a customer’s account, we will point you to that customer, who is the Controller, and will not delete or disclose their data without instruction unless the law requires it.

1.5 The law this notice is written to

1.5.1 The GDPR (Regulation (EU) 2016/679), the UK GDPR (read with the Data Protection Act 2018 as amended by the Data (Use and Access) Act 2025, the “DUAA”), the Estonian Personal Data Protection Act, and the ePrivacy Directive as implemented in each country, including the UK Privacy and Electronic Communications Regulations (“PECR”). Article numbers are GDPR numbers; the UK GDPR uses the same numbering, and we flag where the DUAA changes the UK position.

2. The people this notice is about

Find yourself in the table and read the sections listed.

  • Group: (a) Website visitors Who this is: Anyone who visits www.bidwhistle.com, whether or not they sign up Sections that matter most: 3, 4, 5, 8, 9, 11, 12, 15

  • Group: (b) Customers and Authorised Users Who this is: The subscribing business, the person who signs up and pays, and everyone they authorise to use the account Sections that matter most: 3, 4, 5, 7–13

  • Group: (c) People named in public procurement notices Who this is: Usually a procurement officer or named contact at a public buyer, whose name and work contact details appear in a published notice Sections that matter most: 6, and 9–12, 14

  • Group: (d) People who speak to Olivia Who this is: Any user in a voice or text conversation with our AI assistant Sections that matter most: 7, and 3, 5, 8–10, 12

  • Group: (e) Prospects and marketing contacts Who this is: People at businesses who asked to hear from us, started a trial, or who we contact about the Service Sections that matter most: 3, 4, 5, 12, 13

  • Group: (f) People named in documents a customer uploads Who this is: Anyone whose personal data appears inside a tender pack or other document a customer uploads to the Response Workspace — most often the incumbent supplier’s employees listed in a staffing or TUPE schedule Sections that matter most: 7.8, and 1.4, 3, 10, 12, 14

2.1 You can be in more than one group, and each set of rules applies to that part of the data separately.

3. What personal data we collect

3.1 We collect the categories below. Several exist only if you use the relevant feature.

  • #: 1 Category: Identity and account data What it includes: Name, username, job title, employer, account ID, password (a salted hash — we never see it), authentication tokens, role and permissions Groups: (b), (e)

  • #: 2 Category: Contact data What it includes: Work email address, work telephone number, business address Groups: (b), (c), (e)

  • #: 3 Category: Subscription and billing data What it includes: Plan, Subscription Period, orders and invoices, billing name and address, VAT number, partial card details (last four digits, brand, expiry), payment reference. We never receive or store your full card number Groups: (b)

  • #: 4 Category: Business profile data What it includes: Sector, CPV or category interests, regions, company size and other preferences you give us so we can match you to tenders Groups: (b), (e)

  • #: 5 Category: Customer Data What it includes: Saved searches, tracked tenders, notes, tags, comments, draft bid text and uploaded files — which may contain personal data about colleagues or contacts, controlled by you. Uploads to the Response Workspace are category 12 Groups: (b)

  • #: 6 Category: Usage Data and technical data What it includes: IP address, approximate location from IP, device, browser, operating system, language, referring page, pages viewed, features used, searches run, timestamps, error logs Groups: (a), (b)

  • #: 7 Category: Communications data What it includes: Emails, support tickets, form submissions, and our notes of what was asked and done Groups: (a), (b), (e)

  • #: 8 Category: AI interaction data What it includes: What you type into AI Features; what you say to Olivia; the session recording — your audio and the avatar video — and the transcript, both held by our voice provider for 30 days; session metadata such as time, duration and which model answered; the questions you put to the knowledge base Groups: (b), (d)

  • #: 9 Category: Procurement contact data What it includes: Name, job title, employing organisation, published work email and telephone number of a contact named in a public notice, plus the notice reference, publication date and closing date Groups: (c)

  • #: 10 Category: Marketing data What it includes: Preferences, whether an email was opened or clicked, the source of a subscription, and our record of consent or objection Groups: (b), (e)

  • #: 11 Category: Cookie and similar data What it includes: Identifiers set by cookies, local storage and similar technologies, and your cookie choices — see the Cookie Notice Groups: (a), (b)

  • #: 12 Category: Uploaded tender packs and their contents What it includes: Tender documents you upload to the Response Workspace and everything inside them: specifications, pricing schedules, question sets, and any personal data the buyer or the incumbent supplier put in the pack — commonly a staffing or TUPE schedule naming employees with their roles, salaries and length of service. We read the pack to answer your instruction; we do not store it (clause 7.8) Groups: (b), (f)

3.2 Special category data. We do not ask for, or want, data under Article 9 (health, race or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetics, biometrics used for identification, sex life or sexual orientation) or Article 10 (criminal convictions). Please keep it out of notes, uploads and conversations with Olivia. We do not infer it from Procurement Data (clause 6.6).

3.3 Voice data. Olivia listens to your microphone while you speak. We do not use your camera: the moving image in a session is a rendering of Olivia’s avatar, not video of you. The session recording our provider keeps for 30 days is your audio together with that avatar video (clause 7.4). We create no voice embeddings or voiceprints.

4. Where we get personal data from

4.1 From you — when you fill in a form, create an account, subscribe, contact support, book a demo, or type or speak to the Service.

4.2 From your organisation — if your employer subscribes and adds you as an Authorised User, we receive your name, work email and role from the account administrator. This notice is how we tell you.

4.3 Automatically — Usage Data, technical data and cookie data are generated as you use the Service. Non-essential cookies are set only with your consent.

4.4 From public procurement sources — section 6 is about this. We collect tender notices, award notices, buyer information and related procurement information — Procurement Data — from these official sources:

  • Source: Find a Tender Service (FTS) Territory: UK Licence we rely on: Open Government Licence v3.0, © Crown copyright

  • Source: Contracts Finder Territory: England and UK-wide notices Licence we rely on: Open Government Licence v3.0, © Crown copyright

  • Source: Public Contracts Scotland Territory: Scotland Licence we rely on: Open Government Licence v3.0, © Crown copyright

  • Source: Sell2Wales Territory: Wales Licence we rely on: Open Government Licence v3.0, © Crown copyright

  • Source: eTendersNI Territory: Northern Ireland Licence we rely on: Open Government Licence v3.0, © Crown copyright

  • Source: Tenders Electronic Daily (TED) / SIMAP Territory: EU and EEA Licence we rely on: © European Union, 1998–2026, reused under Commission Decision 2011/833/EU; SIMAP system metadata CC0 1.0; SIMAP editorial content CC BY 4.0

4.4.1 If we add sources we will update this notice first. Candidates are the TenderNed open dataset via data.overheid.nl (Netherlands, CC0 1.0 — the dataset and API only, never scraping the website) and Doffin (Norway, NLOD 2.0, with the required attribution). Reuse does not imply endorsement by the Publications Office of the European Union, the European Commission or any UK public body, and we do not use their logos or trade marks.

4.5 From service providers — Stripe, our payments provider, tells us whether a payment succeeded; Resend, our transactional email provider, tells us whether a message was delivered, opened or clicked; our monitoring tells us about faults and suspicious traffic.

4.6 From publicly available business information — such as a company register entry, used to keep buyer profiles accurate. We do not build profiles of individuals from social media.

4.7 From documents you upload — when you upload a tender pack to the Response Workspace, we receive whatever is in it. That regularly includes personal data about people who are not our customers and who have no relationship with us: the buyer’s named contacts, and the incumbent supplier’s employees where the pack contains a staffing or TUPE schedule. We did not ask for that data and we do not store it; the customer who uploads the pack decides what is in it and is the Controller of it. Clause 7.8 explains what happens to an uploaded pack, and what you can do if your details are in one.

5. Why we process personal data, and our legal bases

5.1 Every use of personal data needs a lawful basis. The retention column summarises section 10; read the two together.

  • #: 1 Purpose: Creating your account, authenticating you and providing the Service — search, alerts, saved searches, tracking, profiles, AI Features Data used: 1, 2, 4, 5, 6, 8 Lawful basis: Art. 6(1)(b) contract, or steps before it. For an Authorised User who is not the contracting party, Art. 6(1)(f) — providing the Service their employer contracted for Retention: Life of the account, then deleted within 30 days

  • #: 2 Purpose: Taking payment; managing subscriptions, renewals and refunds; preventing payment fraud Data used: 1, 2, 3, 6 Lawful basis: Art. 6(1)(b); Art. 6(1)(f) for fraud prevention Retention: Life of the account; invoices 7 years

  • #: 3 Purpose: Accounting and tax records Data used: 1, 2, 3 Lawful basis: Art. 6(1)(c) — Estonian Accounting Act § 12 and tax law Retention: 7 years from the end of the financial year

  • #: 4 Purpose: Service messages: your alerts, renewal reminders, billing failures, security notices, changes to these documents Data used: 1, 2, 4 Lawful basis: Art. 6(1)(b) Retention: Life of the account

  • #: 5 Purpose: Support and answering your questions Data used: 1, 2, 7 Lawful basis: Art. 6(1)(b); Art. 6(1)(f) for keeping a record Retention: 3 years

  • #: 6 Purpose: Security of the Service and our users; investigating abuse and breaches of the Acceptable Use Policy Data used: 1, 6, 7 Lawful basis: Art. 6(1)(f) — network and information security (see 5.3) Retention: Security and access logs 12 months

  • #: 7 Purpose: Understanding use, fixing faults, improving features Data used: 6, and 8 in aggregate Lawful basis: Art. 6(1)(f) — improving a paid product Retention: Product and usage logs 12 months

  • #: 8 Purpose: Running Olivia and the other AI Features — answers, summaries, fit scores, knowledge search Data used: 4, 5, 6, 8 Lawful basis: Art. 6(1)(b) Retention: Session recording and transcript held by our voice provider for 30 days, then deleted automatically (clause 7.4)

  • #: 9 Purpose: Running the Response Workspace — reading a tender pack you upload, drafting an answer, explaining a requirement, reviewing a draft bid Data used: 5, 12 Lawful basis: Art. 6(1)(b) as between you and us. For personal data about other people inside the pack we act as processor on your instructions, and you are the Controller Retention: The pack is not stored by us; only a usage row with no content is written (clauses 7.8 and 10.1)

  • #: 10 Purpose: Aggregated, de-identified insight and benchmarks Data used: 5, 6, 8, aggregated so nobody is identifiable Lawful basis: Art. 6(1)(f) — market insight and product development. We covenant not to re-identify Retention: Kept once no longer personal data

  • #: 11 Purpose: Marketing our own similar products to existing customers by email Data used: 1, 2, 10 Lawful basis: Art. 6(1)(f) with the PECR soft opt-in (see 5.3) Retention: Until you object; consent evidence 5 years

  • #: 12 Purpose: Marketing to prospects Data used: 1, 2, 10 Lawful basis: Art. 6(1)(a) consent where required, or Art. 6(1)(f) for corporate subscribers where electronic marketing law allows Retention: Until withdrawn; consent evidence 5 years

  • #: 13 Purpose: Non-essential cookies and similar technologies Data used: 11 Lawful basis: Art. 6(1)(a) consent, plus the PECR / ePrivacy consent requirement Retention: Consent record 12 months; the choice stored on your device expires after 6 months, then we ask again

  • #: 14 Purpose: Collecting, structuring, enriching and making searchable public procurement notices, including named contact details published in them Data used: 9 Lawful basis: Art. 6(1)(f) — Legitimate Interests Assessment on file, summarised in section 6 Retention: Notice content while it has value; contact details removed 24 months after the tender’s closing date unless still needed

  • #: 15 Purpose: Running a free trial and its conversion Data used: 1, 2, 4, 6 Lawful basis: Art. 6(1)(b); Art. 6(1)(f) Retention: Trials that never convert deleted 60 days after the trial ends

  • #: 16 Purpose: Handling rights requests and complaints Data used: 1, 2, 7 and the data concerned Lawful basis: Art. 6(1)(c) Retention: 3 years

  • #: 17 Purpose: Legal claims, lawful requests from authorities, and a merger, financing or sale of the business Data used: Any, as relevant Lawful basis: Art. 6(1)(f); Art. 6(1)(c) where a law compels disclosure; Art. 9(2)(f) if special category data is unavoidably involved Retention: Until the claim, or the transaction, ends

Where an activity in this table touches Customer Data, we carry it out as processor, on the customer’s instructions under our Data Processing Agreement, not on the lawful basis stated for our own controller processing.

5.2 Legitimate interests. Where we rely on Article 6(1)(f) we ask what the interest is, whether the processing is really necessary for it, and whether it is fair to you. If it is not fair, we do not do it. Ask at privacy@bidwhistle.com for a summary of any assessment.

5.3 UK data subjects — the DUAA. The DUAA created a short list of recognised legitimate interests needing no balancing test: national security, public security, emergencies, safeguarding, detecting or preventing crime, and disclosures to a public authority for a public interest task. None of our commercial processing is on that list — we would rely on it only to disclose data to a public authority for a public task or to help detect crime. The DUAA separately confirms that direct marketing, and network and information security, may be legitimate interests; both still need the balancing test, which we run for UK and EU data subjects alike.

6. Public procurement notices and the people named in them

This section is for group (c). If your name appears in a tender notice and you have found your way here, it is written for you.

6.1 What is going on

6.1.1 Public buyers must publish tender notices, and those notices often name a person — a procurement officer, category manager or contract administrator — with a work email address and sometimes a telephone number, so suppliers can ask questions about the tender.

6.1.2 That is personal data, and it does not stop being personal data because it has been published. This section is therefore our Article 14 notice: what we must tell you when we obtain your personal data from somewhere other than you.

6.1.3 This section is about notices published by public buyers, which we collect ourselves and are Controller of. It is not about personal data inside a document a customer uploaded to us — for example a staffing schedule inside a tender pack. There we act as processor for that customer, and clause 7.8 explains what happens and what you can do.

6.2 Exactly what we take

  • Field: Name, as printed in the notice as the contact point Why we keep it: So a supplier can put a clarification question to the right person

  • Field: Job title Why we keep it: To show the person’s role in the procurement

  • Field: Employing organisation (the contracting authority) Why we keep it: To build accurate buyer profiles

  • Field: Published work email address and telephone number Why we keep it: So a supplier can ask about that tender

  • Field: Notice metadata — reference, publication and closing dates, procedure type Why we keep it: To manage the record and run the 24-month clock in clause 6.7

6.2.1 We take those fields as published, and only as published: no enrichment, no appending from other sources, no guessing email formats.

6.3 Where it comes from

6.3.1 The official portals in clause 4.4: Find a Tender Service, Contracts Finder, Public Contracts Scotland, Sell2Wales, eTendersNI, and TED/SIMAP. Every record carries its source, so you can see which notice your details came from.

6.4 Our lawful basis

6.4.1 Article 6(1)(f) — legitimate interests. Not consent, because you did not give us the data and asking every named contact is not workable; not contract, because we have no contract with you.

6.5 Our Legitimate Interests Assessment, in summary

A full assessment is on file. This is its substance.

6.5.1 Purpose. Public procurement only works if suppliers can find opportunities and ask questions about them, and smaller businesses are structurally disadvantaged: notices sit across at least six portals, in inconsistent formats, with short deadlines. Our interest is in making published opportunities findable and usable. Suppliers share it, and so — through more competition and better bids — do buyers and taxpayers. The buyer published the contact details precisely so that suppliers would use them for that tender.

6.5.2 Necessity. A notice without its contact point is much less useful: a supplier with a clarification question must reach the person the buyer nominated. Stripping names at ingestion and sending users back to the source portal would move the same processing onto every user and reduce nothing. Where a notice gives a role mailbox rather than a person, we keep the mailbox and no name.

6.5.3 Balance. Against the processing: you did not choose to be listed, you may have moved job, and being contactable about one tender is not the same as being contactable forever or about anything else. In favour: the data is professional, not private; your employer published it in an official register expressly so you could be contacted about that procurement; we use it for that purpose and no other; and there is no special category data. The safeguards that settle the balance are the 24-month limit (6.7), no personal contact details and no marketing to you as an individual (6.6), an objection route needing no account (6.8), suppression so an objection sticks (6.9), and this published section. On that basis we consider the processing fair and keep the assessment under review — and under Article 21 you do not have to justify an objection.

6.6 What we do not do with it

6.6.1 We do not infer, derive or record special category data about you — nothing about health, beliefs, politics, union membership, ethnicity or anything else in Article 9.

6.6.2 We do not hold your personal contact details: no personal email, mobile number, home address or social media profile. Only what the notice published.

6.6.3 We do not send you consumer marketing, and we do not sell, rent or licence your details as a marketing list.

6.6.4 We do not profile you, score you, rank you, or make any automated decision about you (clause 7.6), and we do not enrich your record from data brokers or scraped sources.

6.6.5 We do not publish your details openly on the internet. They are visible to subscribers inside the Service, in the context of the notice they came from.

6.7 How long we keep it

6.7.1 The notice itself — tender text, values, dates, CPV codes, the buying organisation — is Procurement Data with lasting research and commercial value, and we keep it.

6.7.2 Your contact details are different. We remove named contact details 24 months after that tender’s closing date, unless they are still needed — for example where the contract is live and the same person is named as contract manager in a later award notice. We review the personal data inside Procurement Data at least annually.

6.7.3 If you object under clause 6.8 we act straight away and do not wait for the 24 months to run.

6.8 Your right to object — and how to use it in about a minute

6.8.1 Because we rely on legitimate interests, Article 21(1) lets you object at any time on grounds relating to your particular situation. We must then stop unless we can show compelling legitimate grounds overriding your interests, rights and freedoms, or that we need the data for legal claims.

6.8.2 In practice we do not argue. Our default answer to an objection from a named public-sector contact is yes. We would push back only where we are legally required to keep a record, and would then explain why and how to challenge it.

6.8.3 How to object. Email privacy@bidwhistle.com, subject “Procurement contact — objection”, with your name as it appears in the notice, the organisation you work or worked for, and the notice reference if you have one. If you do not, say “all notices” and we will search.

6.8.4 You do not need a Bidwhistle account and we will not ask you to create one. You need not explain why or use any particular form of words. We will not ask you to prove your identity beyond what is needed to be sure we are acting on the right record, and we will not treat your request as a marketing opportunity.

6.8.5 We acknowledge promptly and act without undue delay, within one month at the latest — for an objection of this kind, usually within days. You can also ask for a copy of what we hold (Article 15), correct it (Article 16) or have it erased (Article 17): see section 12.

6.9 Suppression, not just deletion

6.9.1 Suppression means this: instead of only deleting your details, we add the minimum information needed to recognise you to a do-not-ingest list, so that when the same details appear in a future notice our systems strip them out automatically and you never have to ask twice.

6.9.2 That record is deliberately tiny — enough to match, nothing more — and used for no other purpose. Deletion alone would not work: the next time a portal published a notice naming you, we would ingest it again. If you would rather we deleted outright and accepted that risk, say so and we will.

6.10 Why we did not contact you individually

6.10.1 Article 14 normally requires us to contact you within a month of collecting your data. Notices are published in very large numbers, their contact details are frequently out of date, and emailing every named contact would itself be intrusive — generating exactly the unsolicited contact this section exists to prevent.

6.10.2 We therefore rely on Article 14(5)(b), which applies where individual notification would involve disproportionate effort, provided we make the information publicly available instead. This section is that public information: a permanent page at https://www.bidwhistle.com/legal/privacy, linked from every page of our website.

6.11 If the notice itself is wrong

6.11.1 We publish what the buyer published, so the source portal’s record stays wrong after we fix ours — tell the buying organisation too. Tell us anyway: we will correct our copy under Article 16 and suppress the incorrect version so it is not re-ingested.

7. Olivia, AI and automated processing

We run two AI surfaces, and they work differently. Olivia is the assistant with a voice and an avatar: clauses 7.1 to 7.4. The Response Workspace is where you upload a tender pack and have it read, drafted from, explained or reviewed: clause 7.8. Clauses 7.3 and 7.5 to 7.7 apply to both.

7.1 You are talking to an AI, and we say so first

7.1.1 Olivia is our AI assistant, with a synthetic voice and an animated on-screen avatar. She is not a human being and not a person at Bidwhistle.

7.1.2 We tell you clearly and distinguishably that you are interacting with an AI system at the start of every interaction, before you say anything to her. That is our obligation as a provider of an AI system that interacts directly with people under Article 50 of the EU AI Act.

7.2 What happens when you speak to Olivia

  • Step: 1 What happens: You speak into your microphone, or type Provider: You, in your browser Where: Your device

  • Step: 2 What happens: Your audio is turned into text Provider: Anam Where: Our provider’s choice of region, which may be the United States (7.4)

  • Step: 3 What happens: The context of your profile and what you are viewing is added to the text Provider: Bidwhistle Where: Our application backend (section 9)

  • Step: 4 What happens: A large language model reads that and composes an answer Provider: Google, contracted through Anam Where: Reached through Anam

  • Step: 5 What happens: The answer becomes synthetic speech, and the avatar is rendered and lip-synced to it Provider: Anam Where: As step 2

  • Step: 6 What happens: The audio and avatar video are streamed back to you Provider: Anam Where: As step 2

  • Step: 7 What happens: The session recording and the transcript are held by the provider for 30 days, then deleted automatically Provider: Anam Where: As step 2

7.2.1 If you type instead of speaking, step 2 does not happen and there is no audio of you; the rest of the chain is the same. Each provider receives only what it needs for its step: no billing data, and no Customer Data outside the conversation and the profile context.

7.2.2 If you ask Olivia something that needs an answer from our knowledge base, your question — and only your question, with no account identity attached to it — is turned into a mathematical representation by Voyage AI so we can find the right passage to answer from.

7.3 We do not train AI models on your data

7.3.1 We do not use your data to train AI models. We do not train models ourselves, and we do not sell or share your data for anyone else to train on.

7.3.2 Our AI providers are a different question, and we would rather be precise about it than reassuring.

  • Provider: Anam What it does for us: Olivia’s voice, avatar and speech-to-text Its training position: Has confirmed that it does not use conversations for model training

  • Provider: Google What it does for us: The model Olivia reasons on, reached through Anam Its training position: Runs under Google’s standard terms, which do not give us a specific no-training commitment

  • Provider: Anthropic What it does for us: The model behind the Response Workspace (7.8) Its training position: Has not yet confirmed its training position to us in writing

  • Provider: Voyage AI What it does for us: Knowledge-base search (7.2.2) Its training position: Has not yet confirmed its training position to us in writing

7.3.3 We have asked, and we will update this notice and our Sub-processors page when we have the answers. [CONFIRM — written confirmation of training, retention and processing location to be obtained from Google (through Anam), Anthropic and Voyage AI]

7.3.4 The same statement, in the same substance, appears in our Terms of Service, Data Processing Agreement, Sub-processors page and AI Use Disclosure. Retention and model-training terms for each AI sub-processor are in a dedicated table on the Sub-processors page.

7.4 Where Olivia’s conversations are processed, and how long they are kept

7.4.1 Where your conversation with Olivia is processed is determined by our provider and may be the United States. The provider offers an EU region, but that is an account entitlement we do not currently hold, not a setting we have left switched off.

7.4.2 The session recording — your audio and the avatar video — and the transcript are kept by that provider for 30 days and then deleted automatically. They are not used to train models. We do not hold our own copy of the audio. [CONFIRM — whether the platform keeps its own copy of Olivia transcripts and conversation logs, and for how long; to be established and recorded before publication]

7.4.3 We are working to move to a plan that lets us pin the processing region to the EU and switch retention off altogether. [CONFIRM — commercial discussion with the voice provider about region selection and zero data retention]

7.4.4 We create no voice embeddings or voiceprints, and we do not clone anyone’s voice. Olivia’s voice and avatar are supplied by our voice provider.

7.4.5 Because the conversation may be processed outside the EEA and the UK, the transfer safeguards in section 9 apply to it.

7.5 Marking AI-generated content

7.5.1 Article 50 of the EU AI Act requires synthetic audio and AI-generated text to be marked in a machine-readable format and detectable as artificially generated, and we are implementing that marking for what the Service produces. [CONFIRM — machine-readable marking of synthetic audio and AI-generated text to be implemented and evidenced before publication]

7.5.2 If you take Output out of the Service, you must not remove that marking or present the Output as human-generated. That obligation is in our Terms of Service.

7.6 Automated decision-making — Article 22

7.6.1 We do not make decisions about you that produce legal effects concerning you, or similarly significantly affect you, based solely on automated processing, including profiling.

7.6.2 Fit scores are decision support, not decisions. A fit score is our estimate of how well a published tender matches the profile you gave us: it says something about a tender’s relevance to a business, not about a person. It does not decide whether you may bid, whether you will win, or whether you are eligible. You read it, disagree if you like, and decide. The same goes for AI-generated summaries and suggestions.

7.6.3 Decisions that could actually affect someone — suspending an account, refusing a refund, upholding a report under our Acceptable Use Policy — are made by a person who can explain them and change their mind. Automated tooling may flag something for review; it does not conclude the matter.

7.6.4 UK note: the DUAA relaxed the rules on significant automated decisions in the UK, subject to safeguards. We do not rely on that change; our position is the same in the UK and the EU.

7.7 AI output can be wrong

7.7.1 Output can be incomplete, out of date or wrong, and only the notice published by the contracting authority is authoritative — check every material fact against it. Nothing the Service produces is legal, procurement, bid-writing, tax, financial or eligibility advice. Our AI Use Disclosure has more detail.

7.8 The Response Workspace: documents you upload

7.8.1 What it is. The Response Workspace is where you upload a tender pack and ask us to do something with it: read it, draft an answer to a question, explain what a requirement means, or review a draft bid you have written.

7.8.2 What happens to the pack. The document is passed to Anthropic, whose model reads it and produces the answer, draft, explanation or review you asked for. It travels through our systems on the way; we store none of it. When the request is finished, all we write is a usage row — how much was processed and a reference number, with none of the content — so we can meter the feature and find faults. Processing location, retention and training position for that provider are not yet confirmed to us in writing (clause 7.3).

7.8.3 You are the Controller of what you upload. Choosing to put a document into the workspace is a disclosure that you make. We act as your processor for it, under our Data Processing Agreement, and the Acceptable Use Policy and Terms of Service set out what you must do first: have a lawful basis for the personal data in the document, remove or redact personal data we do not need to see, and never upload special category data.

7.8.4 Tender packs routinely contain other people’s personal data. This is not a theoretical point. Public tender packs frequently include a staffing or TUPE schedule listing the incumbent supplier’s employees — names, job titles, salaries, hours and length of service — so that bidders can price the workforce they would take on. Those people are not our customers, have no relationship with us, and will usually have no idea that a bidder has uploaded the schedule to a piece of software.

7.8.5 If you are one of those people. You can contact us at privacy@bidwhistle.com and we will tell you what we can, help you find who uploaded the document, and act on any instruction that customer gives us. Because we are the processor and not the Controller, the organisation that uploaded the pack — usually the bidder, and behind it the buyer that issued the pack — is who decides what happens to that data, and is the right party to ask for access, correction or erasure. We will not delete or disclose a customer’s data without their instruction unless the law requires it (clause 1.4.1). We will also say so plainly to the customer concerned.

7.8.6 The controls on upload, and their limits. Three things happen when a pack is uploaded. A notice before upload explains that packs for staffed contracts usually include a schedule of the people currently doing the work — names, pay and start dates — and that we leave those files out. The customer is then shown a list of every file in the pack, and only the files left ticked are read; anything unticked is never sent to our model provider. And files whose names indicate a staff record are listed unticked by default, so they stay out unless the customer deliberately ticks them.

Three limits, which we would rather state than let be mistaken for a guarantee. The default is not a block — the customer can overrule it, and a staff record they tick is sent. The check reads file names, not file contents — a staff schedule named “Appendix 7” or “Schedule 4” is not recognised as one, and is presented ticked like any other file. And it operates on whole files, so a schedule carried inside a larger invitation to tender — which is how TUPE information often arrives — is not separated out from the document it sits in.

Taken together, these controls reduce the chance of an accidental disclosure. They do not prevent one, and we do not present them as if they did. The customer’s own review of the pack before uploading is what protects the people named in it.

8. Who we share personal data with

8.1 We do not sell personal data or share it with advertising networks or data brokers. We share it only as follows.

  • Who: Sub-processors and service providers Why, and what they get: To run the Service — hosting, the application backend, the tender ingestion pipeline, AI, payments, email and support. Only what they need for their part

  • Who: Your own organisation Why, and what they get: If you use the Service through an employer’s account, the administrator can see that account’s Customer Data and usage

  • Who: Professional advisers Why, and what they get: Lawyers, accountants and auditors, under a duty of confidence, and only what is relevant to the advice

  • Who: Authorities, courts and regulators Why, and what they get: Where the law requires it, or for legal claims — the minimum lawfully required. We check every request and push back on overbroad ones

  • Who: A buyer of the business Why, and what they get: On a merger, acquisition, financing or sale of assets, under confidentiality. We will tell you if control of your data changes

8.2 Our main sub-processors

8.2.1 The live, authoritative list — role, location, and for AI providers their retention and model-training terms — is at https://www.bidwhistle.com/legal/sub-processors, with a change subscription. We give 30 days’ notice before a new sub-processor starts processing personal data, and customers may object on reasonable data protection grounds.

  • Provider: Xano What they do, and what they see: Our system of record: the application backend, authentication and all stored customer data — name, email, company, sector, preferences, saved tenders, bids, alerts, usage and login events Primary location: London, United Kingdom [CONFIRM — written confirmation of the hosting region, including backups, to be obtained from the platform supplier]

  • Provider: Hetzner What they do, and what they see: The tender ingestion and scoring pipeline. Reads customer profiles in order to score tenders against them; holds no customer data at rest beyond logs Primary location: Nuremberg, Germany (EU)

  • Provider: WeWeb What they do, and what they see: Delivers the application interface to your browser. No personal data at rest with them; your session token stays in your own browser Primary location: Served via CloudFront; nothing rests there

  • Provider: Vercel What they do, and what they see: Hosts the Olivia embed. Static delivery; session context passes through your browser rather than through storage Primary location: Vercel edge; nothing rests there

  • Provider: Anam What they do, and what they see: Olivia’s avatar, voice and speech-to-text, and the hosted reasoning session. Sees your voice audio, the conversation transcript and the profile context injected into the session Primary location: Provider’s choice of region, which may be the United States. Recording and transcript kept 30 days, then deleted. Not used for training (clauses 7.3 and 7.4)

  • Provider: Google What they do, and what they see: The reasoning model behind Olivia, contracted through Anam. Sees whatever reaches the model during a conversation Primary location: Reached through Anam, under Google’s standard terms (clause 7.3)

  • Provider: Anthropic What they do, and what they see: The reasoning model behind the Response Workspace. Sees the uploaded document, your bid text and your company name Primary location: [CONFIRM — processing location, retention and training position to be obtained in writing]

  • Provider: Voyage AI What they do, and what they see: Semantic search of our knowledge base — turns your question into a vector. No account identity travels with it Primary location: [CONFIRM — processing location, retention and training position to be obtained in writing]

  • Provider: Resend What they do, and what they see: Alert and transactional email. Sees your email address, your name and the tender content of the message Primary location: Delivered via Amazon SES, eu-west-1 (Ireland) — EU

  • Provider: Stripe What they do, and what they see: Card payments, subscriptions and invoicing. Holds the card; we never do Primary location: Global, under Stripe’s own terms

  • Provider: Telegram What they do, and what they see: Fault alerting to us. No customer personal data — operational messages only; listed for completeness Primary location: Global

  • Provider: GitHub What they do, and what they see: Source control. No customer personal data, provided none reaches the repository Primary location: Global

8.2.2 Public procurement portals are sources, not sub-processors: data flows one way, from them to us.

8.2.3 Every sub-processor is bound by a written contract meeting Article 28: restricted to our instructions, confidentiality and appropriate security. For AI providers, the training and retention position of each is set out in clause 7.3 and on our Sub-processors page — we do not claim a uniform no-training commitment we have not obtained.

8.2.4 We do not currently use a third-party product analytics provider. [CONFIRM — no third-party analytics provider is in use; update if one is introduced]

9. Sending personal data outside the EEA and the UK

9.1 Where your data actually sits

9.1.1 We are an Estonian company, so the EU is our starting point. The picture is this:

  • Where: London, United Kingdom What is there: Our system of record — the application backend, authentication and all stored customer data (Xano) Status: Outside the EU, but covered by an adequacy decision (9.2) [CONFIRM — written confirmation of the hosting region, including backups, to be obtained from the platform supplier]

  • Where: Nuremberg, Germany What is there: The tender ingestion and scoring pipeline (Hetzner) Status: EU — no transfer mechanism needed

  • Where: Ireland (eu-west-1) What is there: Alert and transactional email, delivered through Amazon SES for Resend Status: EU — no transfer mechanism needed

  • Where: Our voice provider’s chosen region, which may be the United States What is there: Olivia conversations: your audio, the transcript and the profile context (Anam, and the Google model reached through it) Status: Outside the EEA and the UK — safeguards in 9.4

  • Where: Not confirmed to us in writing What is there: The Response Workspace (Anthropic) and knowledge-base search (Voyage AI) Status: Treated as outside the EEA and the UK — safeguards in 9.4

  • Where: Global What is there: Card payments (Stripe) Status: Outside the EEA and the UK — safeguards in 9.4

9.2 The EU-to-UK transfer, and the UK-to-EU one

9.2.1 Because our system of record is in London and we are established in Estonia, storing your data there is an EU-to-UK transfer. The European Commission renewed its adequacy decisions for the United Kingdom on 19 December 2025. They are valid until 27 December 2031, with a review at the mid-point, after four years. An adequacy decision means the transfer needs no Standard Contractual Clauses: the Commission has decided UK law protects the data properly.

9.2.2 The reverse direction is covered too. If you are in the United Kingdom and you send us data in Estonia, that is a UK-to-EEA transfer, and the UK’s own adequacy regulations for the EEA cover it. You need no transfer mechanism for it and neither do we.

9.2.3 If either adequacy decision is revoked, suspended or allowed to lapse, we will put Standard Contractual Clauses in place for the affected transfers and update this notice.

9.3 Transfers that need no mechanism

9.3.1 Hetzner (Germany) and Resend’s delivery through Amazon SES in Ireland are inside the EU. Nothing extra is needed for them.

9.4 Transfers that do need a mechanism

9.4.1 The onward transfers to providers outside the EEA and the UK are Anam, the Google model reached through Anam, Anthropic, Voyage AI and Stripe. For those we use the safeguards below.

9.4.2 Standard Contractual Clauses. Our default is the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914): Module Two where we are a controller sending data to a processor, and Module Three where we are ourselves a processor passing data to a sub-processor. The Estonian Data Protection Inspectorate is recorded as the competent supervisory authority in Annex I(C) of our Data Processing Agreement.

9.4.3 UK transfers. For transfers under the UK GDPR we add the UK International Data Transfer Addendum (Addendum B.1.0), with “Importer” selected in Table 4.

9.4.4 Switzerland. Where Swiss law applies we add the Swiss overlay: the Federal Data Protection and Information Commissioner as supervisory authority, references read as references to Swiss law, and protection extended to legal entities where Swiss law requires it.

9.4.5 EU–US Data Privacy Framework. Where a US provider is certified under the Framework (and its UK Extension) we may rely on that certification, keeping the clauses in place as a fallback if the Framework is invalidated.

9.4.6 Transfer risk assessments. Before relying on the clauses we assess the law and practice of the destination country and whether extra measures are needed — encryption, pseudonymisation, or sending less. Ask at privacy@bidwhistle.com for the safeguards used for a particular transfer; we may redact commercial terms.

9.4.7 Where a provider has not yet confirmed its processing location to us in writing, we treat the transfer as one needing a mechanism until it does.

10. How long we keep personal data

10.1 We keep personal data only as long as we need it, plus any period the law requires.

  • Data: Account and profile data Retention: For the life of the account, then deleted within 30 days of account closure

  • Data: Customer Data (saved searches, notes, tracked tenders) Retention: For the life of the account, then deleted within 30 days of account closure

  • Data: Data deleted on request during the subscription Retention: Removed from live systems within 30 days

  • Data: Encrypted backups Retention: Purged within 30 days of deletion from live systems

  • Data: Olivia session recordings — your audio and the avatar video Retention: Held by our voice provider for 30 days, then deleted automatically. Not stored by us (clause 7.4)

  • Data: Olivia transcripts Retention: Held by our voice provider for 30 days, then deleted automatically [CONFIRM — whether the platform keeps its own copy of Olivia transcripts and conversation logs, and for how long; to be established and recorded before publication]

  • Data: Voice embeddings and voiceprints Retention: We create and store none. The session audio our voice provider holds is covered by the row above

  • Data: Tender packs uploaded to the Response Workspace Retention: Passed through and not stored by us. Only a usage row — how much was processed and a reference, with no content — is written, and kept with our product and usage logs (clause 7.8)

  • Data: Product and usage logs Retention: 12 months

  • Data: Platform request history — the request and response bodies of calls to our backend, where the value stays under about 10 KB Retention: Approximately 1 day (see 10.3)

  • Data: Security and access logs Retention: 12 months

  • Data: Free trial accounts that never convert Retention: Deleted 60 days after the trial ends

  • Data: Marketing contact data and consent evidence Retention: Until consent is withdrawn, then consent evidence kept for 5 years as proof

  • Data: Invoices and accounting records Retention: 7 years from the end of the financial year (Estonian Accounting Act § 12)

  • Data: Support correspondence Retention: 3 years

  • Data: Data protection complaints and DSAR records Retention: 3 years

  • Data: Procurement Data (public tender information) Retention: For as long as it has research or commercial value; personal data within it reviewed annually, and contact details removed 24 months after the relevant tender’s closing date unless still needed

10.2 Deletion from live systems comes first; the backup copy is purged within 30 days and is not used meanwhile except to restore a failure. Where anonymising achieves the same result we may do that instead. Our internal Data Retention Policy holds the detail — ask at privacy@bidwhistle.com for a copy.

10.3 Request history — a retention fact we would rather tell you than hide

10.3.1 Our application backend keeps a short-lived request history for fault-finding. It records, word for word, the data sent to an endpoint and the data sent back, whenever that data stays under roughly 10 KB; anything larger is discarded whole and never recorded. At our current traffic the history holds about the last day of requests before older entries are overwritten.

10.3.2 Being straight about what that means: the history is switched on for 110 of our 178 endpoints, and some of those endpoints carry your actual bid text — saving an answer, saving a response, saving requirements, saving price lines, saving a bid assessment, and the calls that reach the AI models. For about a day, that text can sit in the request history as well as in your account.

10.3.3 Uploaded tender packs are not affected: a pack is far larger than the 10 KB threshold, so it is discarded rather than recorded.

10.3.4 We are switching this off where it is not needed. [PLANNED — request-history logging to be disabled on the endpoints carrying customer bid text]

11. How we protect personal data

11.1 We are a small company and would rather tell you honestly what we do than impress you with a list.

  • Encryption — everything travels over TLS, and data held by our infrastructure providers is encrypted at rest.

  • Access control — production access is limited to those who need it, which at our size is a very short list; accounts use multi-factor authentication and are reviewed when roles change.

  • Passwords stored as salted hashes. We cannot see your password and will never ask for it.

  • Payment data — full card numbers never reach our systems; they go directly to Stripe, our PCI DSS compliant payments provider, which holds the card details.

  • Backups encrypted, regular and tested; access and security events logged for 12 months. We assess a provider’s security posture before sending it personal data.

  • Incident response — a documented process. Where a personal data breach is likely to result in a risk to people’s rights and freedoms we notify the competent supervisory authority within 72 hours of becoming aware of it, and tell affected individuals without undue delay where the risk is high. As a processor we notify the affected customer without undue delay and in any event within 48 hours.

  • Reporting problems — security@bidwhistle.com. We will not take legal action against anyone who reports a vulnerability in good faith and gives us a reasonable chance to fix it.

11.2 What we do not claim: we hold no security certifications — not ISO/IEC 27001, no SOC 2 report, not Cyber Essentials. We have no dedicated security team, no 24/7 operations centre and no programme of external penetration tests at launch; one person is responsible for security, supported by our providers’ controls. When we obtain a certification we will say so and show the evidence. No system is completely secure; what we can promise is not to misrepresent ours.

11.3 Our internal Information Security Policy describes our controls in more detail, including which are in place and which are planned. Customers and prospective customers can request a copy at security@bidwhistle.com; we may ask for a confidentiality undertaking first.

12. Your rights

12.1 You have the rights below, whether you are a customer, visitor, prospect or a person named in a tender notice. Some apply only to some processing; if one does not apply to you, we will say so and why.

  • Right: Access What it means: Ask whether we hold data about you, get a copy, and be told how we use it Article: 15

  • Right: Rectification What it means: Have inaccurate data corrected and incomplete data completed Article: 16

  • Right: Erasure What it means: Have data deleted where we no longer have a good reason to keep it Article: 17

  • Right: Restriction What it means: Pause processing while a dispute, such as about accuracy, is resolved Article: 18

  • Right: Portability What it means: Receive the data you gave us in a structured, commonly used, machine-readable format, and have it sent elsewhere where technically feasible Article: 20

  • Right: Objection What it means: Object to processing based on legitimate interests, on grounds relating to your situation — the key right for group (c); see 6.8 Article: 21(1)

  • Right: Objection to direct marketing What it means: Absolute: we must stop immediately, with no balancing Article: 21(2)

  • Right: Withdraw consent What it means: Where we rely on consent, withdraw at any time; this does not affect what we did lawfully before Article: 7(3)

  • Right: Automated decisions What it means: Not to be subject to a solely automated decision with legal or similarly significant effects. We make none (7.6) Article: 22

  • Right: Complain What it means: To us, and to a supervisory authority (section 14) Article: 77

12.2 How to exercise a right. Email privacy@bidwhistle.com or write to the address in section 18, saying what you want and, if you can, which data it concerns. No particular form of words is needed. Customers and Authorised Users can also edit profile data, export saved searches and notes, and close the account from within the account. [CONFIRM — self-service access, correction, export and deletion tools in the account to be built and verified before publication] If your data sits in a customer’s account and we act as a Processor, we will point you to that customer.

12.3 We respond within one month, extendable by up to two further months for a complex request or several requests — we will tell you within the first month if we extend, and why. If we cannot act, we will say why within one month and explain your right to complain to a supervisory authority and to a court.

12.4 Free of charge. Only where a request is manifestly unfounded or excessive — for instance repetitive — may we charge a reasonable fee based on our administrative costs, or refuse it; we would explain why and how to challenge that. We expect this to be rare.

12.5 Identity. If we have reasonable doubts about who is making a request we will ask for enough information to be satisfied and no more — not a passport scan for a request we can verify from the email address on the account.

12.6 UK data subjects — DUAA changes to access requests. First, we must carry out a reasonable and proportionate search, not an unlimited one: we search where your data would sensibly be, using sensible search terms, and will tell you what we searched if you ask. Second, where we genuinely need to verify your identity or ask what your request covers, the response clock can pause until you reply — we will not use that to delay you.

13. Marketing

13.1 What we send. Product news, feature announcements, procurement insight, and occasional invitations to try something. Useful and infrequent is the aim.

13.2 Service messages are different. Alerts you set up, renewal reminders, billing notices, security notices and changes to our legal documents are part of the Service; you cannot unsubscribe while you have an account, because they are how we keep our side of the contract.

13.3 Existing customers — the soft opt-in. If you have bought from us, or negotiated to, we may email you about our own similar products and services, relying on the soft opt-in in electronic marketing law with Article 6(1)(f). You were given the chance to refuse when we collected your address, and every message gives you an easy way to stop.

13.4 Prospects. Where you are not an existing customer and the law requires consent, we ask for it and keep the evidence. We never buy marketing lists. Where the recipient is a corporate subscriber and electronic marketing law allows business-to-business email without consent, we may rely on legitimate interests — and the right to object still applies in full.

13.5 People named in tender notices are not a marketing list (clause 6.6.3).

13.6 How to stop. Use the unsubscribe link in any marketing email, change your preferences in the account, or email privacy@bidwhistle.com. We act straight away, and objecting to marketing is absolute. We keep a record of your objection so we do not contact you again by mistake, used for nothing else.

14. Complaints

14.1 Come to us first — we would rather fix it. Email privacy@bidwhistle.com, or use the complaint form and the other routes in our Complaints Policy at https://www.bidwhistle.com/legal/complaints.

14.2 What we commit to. We will acknowledge your complaint within 30 days, investigate without undue delay, and aim to give you an outcome within three months, in plain language. These commitments meet section 103 of the UK Data (Use and Access) Act 2025 and we apply them to everyone, wherever you are.

14.3 You do not have to come to us first. You can go straight to a supervisory authority.

Estonian Data Protection Inspectorate (Andmekaitse Inspektsioon) — our lead supervisory authority Tatari 39, 10134 Tallinn, Estonia Telephone: +372 627 4135 · Email: info@aki.ee · Website: www.aki.ee

Information Commissioner’s Office (ICO) — if you are in the UK Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF, United Kingdom Telephone: 0303 123 1113 · Website: www.ico.org.uk

14.4 You may also complain to the supervisory authority in the EU country where you live or work, or where you think the problem happened, and you have the right to an effective judicial remedy.

15. Cookies and similar technologies

15.1 We use a small number of cookies and similar technologies — including local storage — to keep you signed in, keep your session secure, prevent fraud on payment pages and remember your cookie choices. We set no marketing or advertising cookies, and we use no third-party product analytics at present. We ask for consent before setting anything that is not strictly necessary, we never use a cookie wall, and you can change your mind at any time from the “Cookie settings” link in our website footer. The full list is in our Cookie Notice at https://www.bidwhistle.com/legal/cookies.

16. Children

16.1 The Service is for business use and is not intended for anyone under 18. We do not knowingly collect personal data from children and do not offer any service directly to a child. If you believe a child has given us personal data, email privacy@bidwhistle.com and we will delete it.

17. Changes to this Privacy Notice

17.1 We update this notice when what we do changes — for example if we add a public data source, change a sub-processor, or add a feature that uses personal data in a new way. The version number and issue date at the top tell you which version you are reading; we keep previous versions and will send you one on request.

17.2 If a change is significant — a new purpose, a new lawful basis, a materially different category of data, or a new recipient — we will tell customers and Authorised Users by email or in the Service at least 30 days before it takes effect, unless it must be made sooner for legal reasons. Minor corrections are made without notice. If a change requires your consent, we will ask for it rather than assume it.

18. How to contact us

Bidwhistle OÜ · Registry code 17567745 · Sepapaja tn 6, 15551 Tallinn, Estonia

  • What you need: Privacy questions, rights requests, objections under section 6 Where to send it: privacy@bidwhistle.com

  • What you need: Complaints about how we handled your data Where to send it: privacy@bidwhistle.com — see our Complaints Policy

  • What you need: Help with the Service Where to send it: support@bidwhistle.com

  • What you need: Formal legal notices Where to send it: legal@bidwhistle.com

  • What you need: Security issues and vulnerability reports Where to send it: security@bidwhistle.com

  • What you need: Reports of misuse of the Service Where to send it: abuse@bidwhistle.com

  • What you need: Invoices, billing and refunds Where to send it: billing@bidwhistle.com

18.1 Our UK representative

18.1.1 We have no establishment in the United Kingdom but we offer the Service to people there, so Article 27 of the UK GDPR requires us to appoint a representative in the United Kingdom — someone with a UK address whom UK individuals and the ICO can contact about data protection instead of writing to Estonia.

[UK ARTICLE 27 REPRESENTATIVE — to be appointed; name, address and contact email to be inserted]

18.1.2 Contacting them does not stop you contacting us directly at privacy@bidwhistle.com, and does not affect your right to complain to the ICO.

18.2 Related documents

18.2.1 Our Terms of Service (https://www.bidwhistle.com/legal/terms), Cookie Notice (https://www.bidwhistle.com/legal/cookies), Data Processing Agreement (https://www.bidwhistle.com/legal/dpa), Sub-processors page (https://www.bidwhistle.com/legal/sub-processors), AI Use Disclosure (https://www.bidwhistle.com/legal/ai), Complaints Policy (https://www.bidwhistle.com/legal/complaints), Website Terms of Use (https://www.bidwhistle.com/legal/website-terms), Service Level Agreement (https://www.bidwhistle.com/legal/sla) and Refund and Cancellation Policy (https://www.bidwhistle.com/legal/refunds).