What I collect, and why.

I'm Damian Sémonin, an artist and tutor working from a studio at Wheal Rose, near St Agnes, Cornwall TR5. I trade as a sole trader, and for anything on damiansemonin.art I am the data controller — meaning I'm the one responsible for your information and the one you hold to account for it.

Write to me at hello@damiansemonin.art. A person reads it.

If you book a workshop I keep your name, email and mobile number, and the answers to any questions that workshop asks. If you subscribe I keep your email. If you ask for help I keep what you wrote. That's it.

This site sets no cookies and runs no analytics. There is no Google Analytics, no Meta pixel, no Plausible, no Hotjar, nothing. I don't know who visits, and I've not built anything to find out. The web server doesn't even keep a log of visitors' IP addresses.

I don't sell anything about you to anybody, and I never will.

The booking form asks for your name, email address and mobile number. If you book more than one seat it asks for the name of each person coming. Some workshops add a question or two of their own — materials you'd like, experience level, anything I need to know to run the day properly. Whatever a particular workshop asks is stored alongside your booking.

• Your email is where the confirmation goes, with a calendar file attached so the date lands in your diary. I generate that file myself — no calendar service is involved and nothing is shared with Google or anyone else to make it.
• Your mobile is so I can reach you if something changes on the day — a venue problem, weather, illness. I don't send marketing texts. There is no SMS sending set up on this site at all.
• The names of the people you're booking for are used to make the register and name the places. If you're booking for someone else, please make sure they're happy for you to give me their name.
• The workshop's own questions are used to prepare the session and nothing else.

Why I'm allowed to hold it: performance of a contract — you've booked a place and I can't deliver it otherwise.

One thing I want to be straight about. When a workshop booking is paid for, my system automatically adds the booking email to a list called Art Workshops — everyone who has ever booked. It's how I let past students know when new dates go up. There's a tick-box on the booking form about hearing from me, but that list is maintained by the system from the booking itself, so ticking or not ticking it is not what decides. No welcome email is sent and nothing is sent to it often, but you are on it. Every email from it has an unsubscribe link, and one word to me takes you off. I'd rather tell you than have you find out.

Your booking record lives in a database on my server (see How long I keep things below).

Payments go through Stripe. You're taken to Stripe's own checkout page to enter your card, so your card number never reaches my systems — there is no field for it in my database and nothing to leak. What comes back to me is Stripe's reference for the payment and confirmation that it succeeded.

Stripe holds your card details under its own privacy policy and its own PCI certification. The key my server uses to talk to Stripe is a restricted one, scoped to the few operations bookings actually need.

Why I'm allowed to hold it: performance of a contract, and legal obligation — UK tax law requires me to keep transaction records for six years.

If you put your email into the subscribe box, it's stored in my contact list along with the date and the fact that it came from the website. It's a single opt-in — there's no confirmation email to click, so you're on the list as soon as you submit the form. Every email I send carries a working unsubscribe link, and unsubscribing is honoured everywhere — once you're out, you're out.

If a workshop is full you can join its waiting list, which stores your name and email and how many places you wanted, so I can offer you a seat if one comes free. If I put on a new date for a workshop people were waiting for, the waiting list is carried across to it.

Why I'm allowed to hold it: your consent, which you can withdraw at any time.

One thing worth telling you plainly: the emails I send record whether they were opened and whether a link was clicked, and that record includes the IP address and browser your mail client reported. That's on by default and there is currently no switch to turn it off for an individual subscriber. I'd rather you knew that than found it out. If you don't want it, tell me and I'll remove you from the list.

The contact form doesn't send anything to my server. It opens your own email program with the message ready to go, so the only copy is the one you send from your own account.

The support form is different — it creates a ticket on my system with your name, email, what you wrote, and any file you attach. Attachments are stored as files on the server alongside the ticket. That's used to answer you and to keep a record of what was asked.

Emailing my support address does the same thing: the message is turned into a ticket, and the whole text of what you sent is stored in it, along with your name and address as your mail program gave them.

Email to hello@damiansemonin.art arrives in a Google Workspace mailbox, so Google handles it the same way it handles any business email.

Why I'm allowed to hold it: legitimate interests — answering someone who has asked me a question — or performance of a contract where it concerns a booking you've made.

There's a chat button on this site. What you type into it is sent to an AI model — Anthropic's Claude, reached through a service called OpenRouter — which answers using my help articles.

Before your message leaves my server, email addresses, phone numbers and booking references are stripped out and replaced with placeholders; the answer is reassembled on my side. So the model doesn't see those. It does see the rest of what you typed, so please don't type anything into it you wouldn't want a third party to process.

I don't store the conversation. If you ask to be put through to a human, that step creates a support ticket and then your name, email and the conversation are kept — as a ticket, as above.

If you sign in to see your own bookings or orders, you do it with your email address and a six-digit code I email you. There is no password — I don't ask you to make one and I don't store one, so there's no password of yours here to be stolen. The code can be used once, expires quickly, and is held only in the server's memory in a scrambled form while it waits for you.

The verified email address is the identity; no separate account record is created. What keeps you signed in afterwards is a token in your browser's own storage, not a cookie, and clearing your browser data removes it.

That page also loads a script from a service called LearnSell, which is the courses system this site is wired to.

Why I'm allowed to do it: performance of a contract.

This site sets no cookies. Not analytics cookies, not advertising cookies, not preference cookies. You'll notice there's no cookie banner — that's because there's nothing to consent to, not because one is missing. The only cookie anywhere in the system is a staff one on the shop till, which you will never see.

There is no analytics or tracking software of any kind on this site, and no advertising network. Nothing counts you, profiles you or follows you.

The site does use your browser's own local storage for a few small things — keeping you signed in if you sign in, remembering what's in your basket, and not showing you the same pop-up twice in one visit. That stays on your device and never reaches me.

Some pages load things from other companies' servers, and each of those sees your IP address when the page loads. Being exact about it:

• Google Fonts, on every page — the site's typefaces come from Google. No cookie is set and you aren't identified by name, but it is a request to Google that I could avoid by hosting the fonts myself. I intend to. Until I have, you should know it happens.
• Bunny Stream, on the couple of pages with video in them.
• Bookshop.org, for the book covers on my reading pages, and Substack's image service on one blog post.

A small number of older event listing pages at damiansemonin.art/event/ are still served by a legacy WordPress installation rather than the current site. If you interact with those, WordPress may set its own functional cookies. Bookings are taken through the system described above, not there.

• Hostinger — the virtual server this site, its database and its backups run on, in Manchester, England. They host it; they don't use it. Hostinger also still runs the old WordPress behind those legacy event pages.
• Stripe — payments. Receives your card details directly from you, plus your email and the amount. I never see the card.
• Amazon Web Services — sends the email I send you (booking confirmations, newsletters, replies) and receives email sent to my support address. Receives your email address and the content of the message. Runs in Amazon's London region.
• Google Workspace — the mailbox behind hello@damiansemonin.art. Receives email you send me and email I send from that address.
• OpenRouter and Anthropic — only for the chat assistant, and only the text you type into it, with emails, phone numbers and booking references already removed.
• Google Fonts, Bunny Stream, Bookshop.org and Substack's image service — receive your IP address when a page that uses them loads, as described above.
• LearnSell — the courses platform the account page is wired to.

That's the whole list. In particular: no advertising network, no data broker, no analytics company, and no email marketing platform beyond the one above. My bookkeeping software is not connected to this website and receives nothing from it.

Where in the world: the server and the email are both in the UK. Stripe, Google, OpenRouter and Anthropic are headquartered outside the UK and may process data abroad under the safeguards their own terms set out. I have not independently verified each of those transfer mechanisms, and I'd rather say so than assert something I haven't checked.

I'm going to be straight with you here, because this is the part most privacy policies quietly invent.

There is currently no automatic deletion. No part of my system goes round removing old records on a schedule. Bookings, waiting-list entries, subscribers and support tickets stay in the database until I remove them by hand.

The database is backed up every night and the last fourteen nights are kept, so a record can live on in a backup for a couple of weeks after I've deleted the live one. There are also some older one-off snapshots taken before big changes, which I have not been clearing out.

What I can tell you for certain:

• Transaction records I am legally required to keep for six years for tax.
• Newsletter — if you unsubscribe you come off the sending list immediately. Your email stays on a do-not-contact list so that a later import can't accidentally add you back. That one entry stays even if you ask me to erase everything else, because deleting it would make you mailable again — which is the opposite of what you asked for.
• Anything else — I delete it when you ask me to. See below.

Proper retention periods, and the code to enforce them, are work I have not yet done. I'd rather publish that sentence than publish a schedule that nothing keeps.

Under UK GDPR you can ask me to:

• Show you everything I hold about you, and give you a copy.
• Correct anything that's wrong.
• Delete it — except the transaction records tax law makes me keep.
• Stop or limit what I do with it, including objecting to my use of it.
• Take it elsewhere, in a portable form.
• Withdraw consent for the newsletter at any time, without it affecting anything before that.

Email hello@damiansemonin.art and I'll deal with it within one month. There is no charge and you don't have to give a reason.

Being honest about the mechanics: I don't yet have a self-service button that exports or erases your data. I do it by hand, from the database, when you ask. That's slower than a button but it does get done.

If you're unhappy with how I've handled it, you can complain to the Information Commissioner's Office — ico.org.uk, or 0303 123 1113. You can go to them directly; you don't need my permission and you don't have to come to me first.

What I can evidence: the whole site is served over HTTPS and nothing is accepted over an unencrypted connection. Card details never reach my server. Administrative areas need a login, and repeated failed login attempts are rate-limited. Passwords, where they exist, are stored only as hashes. Keys and secrets are kept off the site and out of version control.

What I am not going to claim: I have no security certification, I have not had a third-party audit or penetration test, and I don't employ a data protection officer — a business my size isn't required to, and pretending otherwise would be worse than saying it plainly. If something ever went wrong in a way that put your rights at risk, I would tell you and I would tell the ICO, as the law requires.

If I change anything that matters, I'll update this page and the date below. If a change means I need your consent again, I'll ask for it rather than assume it.

Last updated: 31 August 2026.

This policy was written by me, from what the site actually does, and it has not been reviewed by a solicitor. Everything in it is true to the best of my knowledge; if you spot something that isn't, please tell me and I'll fix it.