Privacy

What we hold, and why.

Almost everything on this site is built from public records, and most of it is about government rather than about anybody in particular. Three things here are personal data. There is what we hold about you — your address, what you told us to watch for, and whatever you make inside the platform. There is what you tell us about other people when you ask for a briefing on a meeting or map out who decides your issue. And there are the people named in our registers: officials, ministers and elected members whose work their own organisations published. This page covers all three, in that order. Last updated 17 September 2026.

On this page: Who is responsible · What we hold about you · What you tell us about other people · Why we are allowed to · Who else sees it · Where it is held · How long · Cookies · What we never do · People named in our registers · Stopping it · Your rights

Who is responsible

Seam is a trading name of Futureworks Intelligence Ltd, a company registered in England and Wales, company number 17458346, whose registered office is 71–75 Shelton Street, Covent Garden, London WC2H 9JQ. The company is the data controller: the party answerable for everything on this page. Questions, corrections and requests go to [email protected] and are answered within one month.

What we hold about you

If you sign up or subscribe: your email address; your name and organisation if you give them; the description of your mission that you type; the answers you give about what the briefing should watch — the subjects you pick, what you want it to favour, which nation you care about, and any names you ask us to keep an eye on; identifiers from Stripe for your customer record and your subscription; the date each briefing was sent to you; and a token that makes the unsubscribe link in every email work. After your first briefing we also keep a numeric summary of your description — a row of numbers standing for its meaning, used to match it against what government publishes. It is not readable as text and it is not shown to anyone.

The form also reaches us as an ordinary email, which is how we read it. One thing you type there is only in that email and is never written to the database: the stage your organisation is at.

If you only try the free preview: your email address once you verify it, and a count of how many preview briefings you have built. That count is the only reason the address is asked for.

Signing in. There are no passwords here. You ask for a link, we email it, and opening it signs you in on that device. The link is a random 32-character token that lives for one hour and is spent the first time it is used, so a forwarded email is not a standing key. Signing in sets one cookie — the only cookie this site sets, described under Cookies below.

If you pay. Checkout happens on Stripe’s own pages, not ours. No card number, expiry date or security code ever reaches this site, and we could not store one if we wanted to. What comes back to us is your email address, the name you gave Stripe, which plan you bought, whether the subscription is live, and two Stripe identifiers so that a renewal or a cancellation can be matched to the right person. Your description travels with the checkout so that the briefing can be built the moment the payment clears, and it comes back with it.

What you make inside the platform stays yours and is kept until you delete it. The platform is a place to do work, not a place to look things up, so most of what it holds is what you wrote:

  • Consultation responses. Your draft as it stands, every answer in it, and for anything you send: the department it went to, the mailbox it arrived at, the subject and the body. A sent response is a record of something you did, which is the point of keeping it.
  • Priority maps. The issue you described, the map drawn for it, and the moves you have logged against it.
  • Your writing. If you paste in things your organisation has published so that drafts sound like you, we keep those documents, their titles and where you said they appeared. Up to twelve of them, and you can remove any of them at any time. Nothing is fetched from the web on your behalf — the text is pasted in.
  • Meeting briefings and the answers behind them, covered in full below.
  • Alerts to Slack or Teams. If you point the briefing at a channel we keep the address your workspace gave us for it, the label you typed, and when we last posted. That address is a key to the channel: anybody holding it could post there, which is why it is never shown back to a browser once saved.
  • AI assistants you connect. If you add Seam to Claude, ChatGPT or another assistant, we keep the assistant’s name, the addresses it asked to be sent back to, when it was last used, and the keys we issued it — stored only as scrambled fingerprints that cannot be used as keys themselves. We do not keep what it searched for. Disconnect it on the platform and its keys stop working at once.
  • Emails you forward to us. If you forward an email to our forwarding address, we read it once to work out what to search for and reply to you. If it carries a meeting invitation file, we read from that who the meeting is with, their organisation, the date, the time and the agenda — never the location. To write the few sentences at the top of the reply, a model is shown the subject, up to a page of the email’s text with every email address, link and dial-in detail taken out, the organisations in the meeting, and the titles of the records we found (see Anthropic and Cloudflare Workers AI below). We keep only a note that a message arrived, from whom, when and whether we replied — not its subject, its text or our reply. Our email provider, Resend, receives the message on our behalf and holds it for its own short retention period. We never reply to anybody who is not already signed up with that address.
  • Meeting notes you send us. If you paste a note into the meeting notes page, or post one to the address we give you for your notetaker, we do not keep the note. We read it once to list the organisations, people and subjects it names, and the text is dropped before anything is written down. What we keep is those names, the briefing built from them — which is made up of records from the public registers — and a line saying that a note arrived at your address, when, and what happened to it. Nothing you send is used to train anything. If you would rather nothing at all were kept, use the box on the page rather than the address: the box stores nothing, and the address stores a result so that you can open it later.
  • A Notion connection. If you connect Notion, we keep a key to it (encrypted), which workspace it is, and which database you chose for the pages. Notion decides what that key can reach: its own screen asks which pages to share with Seam. We read nothing from your Notion beyond that database’s layout, which is how a page is written into the columns you already have. When a letter you sent gets a reply — because you marked it, or because the reply was forwarded to the letter’s own copy address — we add a note to that letter’s page saying so, with the reply’s subject line, and fill in a Replied column if your database has one. For that we keep which page each letter went to, and nothing the letter or the reply said.
  • A HubSpot connection. If you connect HubSpot, we keep a key to your HubSpot account (encrypted, and never shown back to a browser), its account number, how many notes we have written and when the last one was. We also remember which HubSpot company record stands for which government body, so that two letters to the same department land on the same record. We read nothing else from your HubSpot.
  • Drafts you share for comment. Sending a draft to a colleague creates a link, and we hold the address you sent it to, whether it has been opened, and whatever they write back, under the name they type. Revoke the link and it stops working.
  • Support conversations. If you ask the support panel something and it cannot answer, the conversation is saved as a ticket with your address, the page you were on, and a reference number, so that a person can pick it up. If it can answer, nothing is kept.

Everything in that list is visible to other people on the same account. An account is a company, not a person — that is what buying seats means — and a colleague opening the platform sees the work rather than a blank screen. If that is not what you want, the answer is a separate account rather than a setting.

Searching and asking questions. What you type into the search box or ask the platform is not written down. There is no query history, no log of what you searched for, and nothing attached to your account. Two things do happen to it and neither is a record of you: the words go to our embedding provider to be turned into numbers so that the search can find things that do not match word for word, and an answer is held for an hour in the cache at the data centre that served it, under a key made from the question itself, so that the same question asked twice is not paid for twice. Neither holds who asked.

What we deliberately do not hold: no analytics, no advertising identifiers, no cross-site tracking, no browser fingerprinting, no session recording, and no payment card details. There is no third-party script of any kind on this site. If that sounds like a small list, it is meant to: the shortest section of a privacy notice should be the one about what the site does behind your back.

Two things every web server sees, and it would be easy to leave them unsaid. The first is the address your computer connected from. When you send the sign-up form we store a one-way scramble of it with the time; it stops a script posting the form a thousand times a minute, it cannot be turned back into an address, and it is deleted within a day. The endpoints that cost money to answer — asking a question, building a meeting briefing, the support panel, the company and charity lookups — keep a counter against your address for an hour in the cache at the data centre that served you. The counter holds a number and nothing else, it is never joined to your account or to anything you typed, and it disappears on its own. The second is our host: Cloudflare, which delivers every page, keeps its own short-lived records of requests to protect the site from attack. We do not use those records to work out anything about you, and we do not build a profile from them.

One outside company is asked for something on every page: the font. The typeface is served by Google Fonts, which means your browser fetches it from Google and Google sees the address it came from and which page asked. It sets no cookie, it is told nothing else about you, and it is the only request on this site that goes anywhere but our own server. We would rather it did not, and it is on the list to move onto our own server.

What you tell us about other people

Two parts of the platform work by being told about people who are not you: the meeting briefing, and the map of who decides your issue. The rule for both is the same — we hold what you chose to give, we do not go looking for more, and it comes out when you delete it.

If you connect a calendar (Google Calendar or Outlook, to get a briefing before a meeting): a token that lets us read your diary, encrypted before it is stored; the address of the Google or Microsoft account you connected, so you can see which diary is attached; and its domain, which is how we tell an outside attendee from a colleague.

We ask for read-only access to calendar events and nothing else — not your mail, not your contacts, not your files, and no permission to change anything. When you ask the panel to look, we read a window of your diary and nothing outside it. You choose how far that window reaches. We read the window you asked for and no more, and we never widen it on our own. Whatever the window, we take the title of each meeting, when it is, how long it runs, the email addresses of the people invited, and the invitation’s own description — so a longer window means more of other people’s addresses and words passing through, which is worth knowing before you pick one. The events themselves are never stored. They are read, used to fill in the questionnaire in front of you, and gone.

Why we read the description, and what we take out of it. It is usually the agenda, and a tool that made you retype the agenda already sitting in your calendar would be doing half a job. So it is put into the questionnaire’s boxes, on your screen, where you can edit it or delete it before you send anything — it is kept only if you then submit the briefing, exactly like every other answer. Before it reaches your screen at all we strip out every joining link, meeting ID, passcode and dial-in number: those are a key to a room, a briefing has no use for them, and a key we never copy is a key we cannot lose. We take the names of the people invited from outside your own organisation; we do not take their email addresses, their job titles, or your own colleagues. We still never ask your calendar for the location of an event, or for anything attached to it, and Google and Microsoft are told not to send them.

Nothing from your diary is used to train a model, to advertise, or for any purpose other than producing the briefing you asked for, and none of it is sold or shared with anyone for their own purposes. Our use of information received from Google APIs follows Google’s API Services User Data Policy, including its Limited Use requirements.

What you type into a meeting briefing is a different matter, and we keep more of it. The questionnaire asks who you are meeting and their organisation, who the briefing is for, when the meeting is and how long it runs, everyone else who will be in the room, why the meeting is happening and who asked for it, what you want out of it, and the agenda line by line. Only the first of those is required — the name of whoever you are meeting, without which there is nothing to look up. Every other question can be left blank, and the briefing is built from whatever you chose to give it. Your answers are stored as you wrote them, so that the briefing can be reopened and rebuilt later, and they are visible to other people on the same account under Team. Delete the briefing and the answers go with it.

The same is true of anything else you hand over about the meeting. Some people would rather paste or forward the email thread than fill in boxes, and that works: the wording of an invitation, an email about the meeting, or a note you have written yourself all go into the same answers and are kept the same way. Whatever you paste is stored as you gave it, so it is worth a glance before you send a whole thread — anything in it that has nothing to do with the meeting is kept too, and there is no way for us to tell the difference. The same rule covers the invitation wording we fill in for you from a connected calendar: it is on your screen, in a box, and it is stored because you submitted it rather than because it appeared there. A meeting’s location never reaches us by any route.

The map of who matters is drawn from published records — organograms, the parliamentary registers, what bodies have published on your issue — so the people on it are named because their own organisation named them, not because you told us. What you add is yours: the issue in your words, and whatever you log about an approach you have made. If you write something about a named official into that log, it is kept in the same way as everything else on your account and goes when the map goes.

The calendar inside the platform is not your diary. It is built from the deadlines and publication dates in the briefing we made for you — consultation closing dates, statistics due out, bidding deadlines, all of them public records. It is assembled in your browser from your own briefing each time you open it, and it holds no meeting of yours unless you put one there.

If you upload an invitation instead — the .ics file your calendar exports for a single meeting — we hold nothing at all from it. The file is read inside your own browser: it is never uploaded, never reaches our servers and is never written down. What it does is fill in the questionnaire for you, and from that point it is the same as if you had typed the answers yourself, covered by the paragraph above. Nothing is sent anywhere until you submit it. This is the route to use if you would rather not connect a calendar at all.

Why we are allowed to

Your address and your description are held to perform the contract you entered when you subscribed — without them there is no briefing to send and nothing to build it from. The same goes for everything you make inside the platform: you are paying us to keep it and to act on it. The preview count, the rate counters, the one-way scramble of an address on the sign-up form and the error reports described under Who else sees it rest on our legitimate interest in rationing a free demonstration and keeping the site standing, which are narrow purposes and the least intrusive way we could find to serve them. Billing records are kept because tax law requires it. The contact details and named posts in our registers rest on legitimate interests, set out below, where the case for them is made in full because that is the part where nobody chose to be here.

We do not rely on consent for anything on this site, which is why there is no banner asking for it. Where something needs your say-so — connecting a calendar, pointing alerts at a channel, sending a response to a department — the say-so is the act itself, and it can be withdrawn by undoing it.

Who else sees it

These companies process this data on our behalf, each for one job and nothing else. None of them may use it for their own purposes, and each is engaged on terms that say so:

  • Cloudflare hosts the site and the database everything lives in.
  • Sentry is told when a page of this site breaks in your browser, so that it can be fixed. It receives the fault itself — what went wrong, and which line of which of our files caused it — along with the address of the page you were on with anything you typed into it cut off, which browser and version you are using, and the network address the report was sent from. It is told nothing about your account, it is sent nothing at all unless something has actually gone wrong, and it neither sets a cookie nor keeps anything in your browser. It makes no recording of what you did.
  • Stripe takes the payment and holds the card details we never see.
  • Resend delivers the email — your briefing, your sign-in link, and anything the platform sends on your behalf.
  • Google and Microsoft hold the diary itself, and are asked for the window you chose only when you have connected a calendar and a briefing is being built. Neither is told anything about you that they did not already have.
  • Notion, only if you connect it. Each letter, consultation response or piece of evidence you send is added to the database you chose, as a page carrying its text, who it went to and the date. Disconnecting stops it; pages already written stay in your Notion, where you can delete them.
  • HubSpot, only if you connect it. Each time you send a letter, a consultation response or committee evidence from the platform, we write it into your own HubSpot as a note on the government body it went to, creating that body as a company record the first time. HubSpot receives the text you sent, its subject, the post and body it was addressed to and the date. We can read and write company records in your HubSpot and nothing else — not your contacts, deals or email. When a letter gets a reply, a second note on the same company says so, with the reply’s subject line; for that we remember which company each letter went on, and nothing the letter or the reply said. Disconnecting stops it; notes already written stay in your HubSpot, where you can delete them.
  • Google and Microsoft, when you sign in with them. They tell us the email address on the account and whether they have checked it is yours. We ask for nothing else — not your diary, contacts or mail — and keep nothing from them but the address.
  • The AI assistant you connect receives the search results and records it asks for, under that assistant’s own terms. That is the point of connecting it; we send it nothing else about you.
  • Anthropic usually writes the prose. For a weekly briefing it sees the description you typed and the titles of the documents matched to it, and only when model-written summaries are switched on. For a meeting briefing it sees the questionnaire answers you chose to give — which may be no more than a name, and at most who you are meeting and their organisation, the others in the room, why the meeting is happening, what you want from it and the agenda — alongside the public records retrieved for it. For a consultation response or a letter it sees your draft, your instructions and the evidence chosen for it. For an email you forward to us it sees the subject, up to a page of the text with every email address, link and dial-in detail removed, the organisations in the meeting if it is an invitation, and the titles of the records we found — never who forwarded it. It sees nothing you left blank. It never sees your email address, and nothing sent to it is used to train a model.
  • Cloudflare Workers AI writes the prose instead when Anthropic cannot answer — an outage, or the month’s allowance spent. It sees exactly what Anthropic would have seen, and nothing more: the same typed text, the same questionnaire answers, the same public records. The model runs on Cloudflare’s own network rather than being sent anywhere new. It is a smaller model, so the writing is plainer, and wherever it has answered the page says so. Nothing sent to it is used to train a model.
  • Voyage AI turns words into numbers so that the search can find things that do not match word for word. It sees the words you searched for and the description you gave us, and nothing else — no address, no account, no history.

One thing leaves on purpose rather than on our behalf. When you approve a consultation response or a letter, it is sent to the department or committee it is addressed to, from us, with your organisation on it. That is the whole point of pressing the button, and nothing goes without that press. What happens to it afterwards is in the hands of the public body that received it, and most of them publish responses.

Nothing is sold, rented, or shared for anyone else’s marketing. If that ever changes we will ask first — it is not the sort of thing a notice should announce after the fact. If the business is ever sold, the data goes with it and subscribers are told before it does.

We will disclose information if the law obliges us to — a court order, or a statutory request we cannot refuse. If that ever happens and we are permitted to tell you, we will.

Where it is held

The database is Cloudflare’s, and the site runs at whichever of Cloudflare’s data centres is nearest to whoever asked for the page — and that includes Workers AI, which runs on the same network, so nothing extra leaves it. Cloudflare, Stripe, Resend, Anthropic, Voyage AI, Google and Microsoft are all United States companies, so some of this data is processed outside the UK. Each is engaged under data-processing terms carrying the safeguards UK law requires for that — the standard clauses with the UK addendum, or the UK extension to the EU–US Data Privacy Framework where the company is certified under it. Copies are available on request.

Sentry is a United States company, but this site is registered in its European region, so the error reports themselves are held on servers in Germany rather than the United States.

How long

  • Your subscriber record — while you are subscribed, and for a year afterwards, so that a returning reader does not start from nothing.
  • Billing records — six years, because tax law says so.
  • Sign-in links — one hour, and spent on first use.
  • The sign-in cookie — a fortnight at the outside, usually much less.
  • Preview records — deleted after two years of no activity.
  • Saved meeting briefings, consultation drafts, maps and your writing — until you delete them. There is no automatic expiry, because a piece of work you have not touched in a year is not a piece of work you wanted thrown away.
  • Sent responses and letters — kept as a record of what was sent, for as long as your account is open.
  • Meeting notes — the note itself is never kept at all. The names read out of it and the briefing built from them stay until you delete them, like any other saved work.
  • Support tickets — two years, then deleted.
  • A calendar token — until you disconnect, and then deleted outright.
  • The scrambled address from the sign-up form — a day.
  • Rate counters — an hour, and they expire on their own.
  • Records in the contacts register — five years from the date of the document they came from.

Close your account and everything except the billing record goes within thirty days. The billing record stays for the six years tax law requires and holds nothing but what tax law needs it to.

Cookies

This site sets one cookie that lasts, and only once you have signed in. It is called fw_seal. It holds which account you are on, which plan it is, the address you signed in with, and when it expires — all of it signed, so it cannot be edited into somebody else’s account. It cannot be read by any script on the page, it never travels over an unencrypted connection, and it is not sent when another site links to us. It lasts a fortnight at the outside, and signing out or clearing it ends it.

That cookie is strictly necessary: it is the thing that remembers you are signed in, and the law does not require us to ask permission for it.

If you press Sign in with Google or Sign in with Microsoft, a second cookie, fw_login, lives for ten minutes while you are away at Google or Microsoft. It holds a random value and nothing else, is only ever sent back to our sign-in address, and is deleted the moment you return. Its one job is to make sure the sign-in that comes back is the one your browser started, so nobody can sign you in to their account without your knowing. It is strictly necessary for the same reason.

We set no other cookies, for any purpose, which is why this site has no cookie banner. Nothing here tracks you across other websites, because there is nothing here that could.

One small thing is kept by your own browser rather than by us, and never leaves it: a marker noting that the opening animation has already played, so that it does not play again on every page you open. It disappears when you close the tab.

What we never do

No decision about you is made by a machine alone. The platform ranks documents, drafts prose and suggests who to approach, and every one of those is a suggestion put in front of you to accept or throw away. Nothing it produces is sent, filed or acted on without you pressing something.

Nothing you give us trains anybody’s model. Not your description, not your drafts, not your diary, not your meeting answers. The companies above are engaged on terms that forbid it, and we do not train models of our own.

This is a service for organisations, sold to people at work, and it is not aimed at children. We do not knowingly hold data about anyone under 18.

Security. Everything travels over an encrypted connection. Calendar tokens are encrypted before they are stored, with a key held separately from the database. Sign-in links are random, short-lived and single-use. Access to the database is limited to the people who run the service, which today is a small number. If something goes wrong in a way that puts anybody at risk, we will tell the Information Commissioner within 72 hours and tell you without delay.

People named in our registers

Our registers are built from what government publishes, and government publishes the names of the people who do its work. So a register of ministerial meetings names the minister; a register of senior posts names the post-holder; the register of members’ interests names the member. That material is personal data even though every word of it was published by the body the person works for, and this section is about all of it. The contacts register gets the longest answer because it is the only one that holds a way of reaching somebody.

Where it comes from. Everything in these registers comes from an official publication, and every record on every page carries the document it came from and that document’s date. Contact details come from three places, all of them documents the publisher put out for the purpose of being contacted about them: explanatory memoranda laid before Parliament, which name the official to write to about an instrument; procurement notices on Find a Tender, which name the buyer to ask about a live contract; and the contact details the UK and Scottish Parliaments publish for their elected members. We do not buy contact data, we do not take it from anybody’s directory, and we do not add anything to it from another source.

Why we are allowed to. Our legitimate interests in helping people reach the part of government responsible for a document they have found. Our registers already answer “what did government do?”; without this they cannot answer “who do I ask?”, and for a small company with no public affairs team that is usually the only question that matters. The Open Government Licence, which covers most of this site, does not cover personal data, so this is not held under a licence at all.

Elected members are a separate case, and we treat them as one. An official is named in a memorandum incidentally — somebody had to be. A Member’s address is published by their parliament so that people write to them. Being findable is the point of it.

What we leave out on purpose. The organograms government publishes carry a pay band for every named senior post; we drop it, because a searchable national list of named individuals and their salaries is a different thing from a map of who owns which policy area, and only the second is what the page is for. The grade stays, the money does not. The register of members’ interests names companies and organisations but not private individuals — where the source says a payer or donor is a private person, the name comes out before the record is written — and no payer’s address is kept at all. Amounts are shown as bands rather than figures.

What we never publish. Where a body has published enough of its people’s addresses for the shape to be clear, the register can work out what somebody else’s address would probably be. That worked-out address is built in your own browser at the moment you ask for it and is stored nowhere — not in a file, not on our server, not in a list anybody can download. It is labelled as a guess every time it is shown, because that is what it is.

What we do not collect at all. No contact details for defence, intelligence, policing, prisons and probation, enforcement or child protection bodies — 76 organisations, excluded before anything is collected rather than filtered out afterwards.

How long. Five years. A record older than that is not published and is not kept. Every record on the page carries the document it came from and that document’s date, and the page says plainly when a record is old enough that the person has probably moved on. We report what was published and when. We do not claim it is true today.

The contacts register is not indexed by search engines. It is there for somebody who has found a document and needs to ask about it, not to become a directory of officials that anyone can scrape. Neither is our case law register, which holds judgments naming the people who were party to them: the licence it is held under requires it to be kept out of search engines, and it is.

If you are in it and would rather not be. Email [email protected] and we will take you out. You do not have to give a reason. We keep your name on a suppression list so that the same details are not collected again the next time we run the harvest — that list exists only to honour your request, and it is the only thing on it. The same applies to anything else here that names you: tell us and we will look at it, and where what we hold is a faithful copy of something your own organisation published, we will say so and tell you who published it, because that is where it can actually be changed.

Why you are reading this here rather than in an email from us. Data protection law expects us to tell you directly when we hold information about you that we did not get from you. Writing individually to several thousand officials to say that we hold the work address their own department published would be an unwelcome email to every one of them, for no benefit to any of them, and would be the closest thing to the harm the rule exists to prevent. The law allows a public notice instead where contacting people would take disproportionate effort. This is that notice, and it is why it says more than the rest of this page.

Stopping it

Every briefing carries an unsubscribe link, and most mail apps show their own unsubscribe button next to the sender’s name. Either one stops the email immediately.

Unsubscribing stops the email. It does not cancel a paid subscription, because quietly ending someone’s billing on a single click would be a surprise — email [email protected] and we will cancel it and refund the unused part of the month.

A connected calendar is disconnected from the same panel that connected it, on the meeting briefings page. For a Google calendar we do two things: we tell Google to revoke the permission, and then we delete our stored token — in that order, because deleting first would leave you believing you had withdrawn access when you had only stopped using it. Microsoft gives us no way to revoke on your behalf, so there we delete the token and the permission itself stays on your account until you remove it. Either way you can remove it yourself, without asking us, at myaccount.google.com/permissions or myapps.microsoft.com.

A channel, a shared link, a saved briefing, a draft, a map, a document you pasted in — each is removed from the place you made it, and removing it removes it from us. Ask us to close the account altogether and everything goes with it, on the timetable above.

Your rights

Under UK data protection law you can ask for a copy of what we hold about you, ask us to correct it, ask us to delete it, object to us holding it, ask us to stop using it while a dispute is sorted out, or ask for it in a portable form. Where we rely on legitimate interests — which includes everything in the registers — you can object, and we will stop unless we can show a reason that outweighs yours. Ask at [email protected]. There is no charge and we do not ask why.

If you think we have got something wrong you can complain to the Information Commissioner’s Office at ico.org.uk or on 0303 123 1113. We would rather you told us first, but you are not obliged to.

Our registration with the Information Commissioner’s Office is being completed in the company’s name, and the registration number will appear here once it is issued.

Changes

If this notice changes in a way that affects what happens to data we already hold, subscribers are told by email before it takes effect. Wording fixes are made quietly and the date at the top moves.