Privacy Policy

This policy covers two things, and the second one is why it is long. The first is what happens to your details if you use this website. The second is what happens to your systems, and to your customers’ data, if you engage BespokeForge to build or operate something.

Most privacy policies only cover the first. If you are being asked to give an outside engineer access to production, the first is not the part you need.

Who you are dealing with

BespokeForge is the trading name of Christian Kelechukwu, working as an individual. There is no company behind it yet, so this page names no company number, no registered office and no VAT registration, because there is nothing to name. When a company is registered, this page will name it, its number and its country.

For anything to do with this website or your data, write to [email protected]. That address reaches one person, and it is the same person who does the work.

I work remotely, and my base is not always inside the European Economic Area. That matters for your data and it is dealt with plainly further down, under where your data goes.

Part one: this website

What this site collects

The contact form. Your name, your email address and your message. Nothing else. There is no phone field, no company field and no budget dropdown.
The checklist form on the guides page. Your email address only.
The web server’s access log. Your IP address, the page you asked for, the time, and the browser identification string your browser sends. Every web server keeps one of these.
A light and dark mode preference, but only if you click the toggle. It stays in your own browser and is never sent anywhere. The cookie policy names it and explains it.

There are no visitor accounts on this site, so there is nothing to register for and no password to store. There are no comments. There is no analytics of any kind.

Where it goes, exactly

This is the part usually left vague, so here it is in full.

A contact form message is emailed to me, and it is also written to a log inside this site’s own database. That log holds the most recent 200 enquiries and trims each message to its first fifty words. It exists because email delivery fails sometimes and an enquiry that vanishes is worse than one stored.
A checklist request is written to a log of the most recent 500 addresses. Two emails then go out: the checklist to you, and a one-line notice to me.
Both forms are rate limited, so the same person cannot submit fifty times in a minute. That check stores a one way hash of your IP address, for fifteen minutes on the contact form and one hour on the checklist form. The address itself is not stored by this, and a hash cannot be turned back into one.

Why I am allowed to hold it

Your enquiry. To answer you, and to take the steps you asked for towards an engagement. Under the GDPR that is legitimate interests, and steps taken at your request before a contract.
The checklist. Consent, which you give by sending the form, and which you can withdraw at any time.
Logs and rate limiting. A legitimate interest in keeping the site up and not being flooded by bots.

The field notes, stated properly

The checklist email mentions occasional field notes on building and operating production systems. That is a mailing list, so it should be named as one here rather than discovered after the fact. If you ask for the checklist, you may get an occasional note. Reply and say stop, and I take your address off. I do not send anything more often than occasionally, and I do not pass the list to anyone.

How long it is kept

The enquiry log rolls at 200 entries, so older ones drop off on their own. Beyond that, I delete an enquiry thread once it is clear nothing will come of it, and in any case within 24 months.
The checklist log rolls at 500 addresses, and comes off sooner if you ask.
The rate limit hashes expire by themselves, within an hour at most.
The server access log is rotated away on the server’s own schedule. If you need the exact period before you send anything, ask and I will tell you.
Engagement records, meaning invoices and the correspondence around a contract, are kept for as long as accounting and limitation periods require, then deleted.

Who else sees it

Email from this site is delivered by a third party email service. The site itself runs on a single server, and it is backed up.

Which providers those are, and which country the server sits in, is not published here. This site does not publish infrastructure detail about any system, including its own, and that rule exists to protect clients rather than me. It should not cost you an answer, so: ask before you send anything, and I will tell you who they are and where they are.

What does not happen

Nothing here is sold, rented, or handed to anyone for their own marketing.
There is no advertising, no remarketing, no profiling and no automated decision making. Nothing on this site scores you or sorts you.
Nothing you send is used to train a machine learning model, mine or anyone else’s.

Your rights, and how to use them

If you are in the UK or the European Economic Area, the GDPR gives you the right to ask for a copy of what I hold about you, to have it corrected, to have it deleted, to restrict or object to how it is used, to receive it in a portable form, and to withdraw consent you have given.

Ask by writing to [email protected]. You do not need a form or a particular wording. I answer within 30 days, and if something will take longer than that I will tell you why before the 30 days are up rather than after.

If you are unhappy with how a request is handled, you can complain to the data protection authority in the country you live in. There is no registered establishment in the European Union here, so there is no single lead authority to send you to. Your own is the right one.

Part two: your systems, during an engagement

An engagement means access to systems that hold other people’s personal data: your customers, your staff, your enquiries. On that data I act on your instructions and not my own. In the GDPR’s terms you are the controller and I am a processor.

What access I take

The minimum the work requires, scoped to the task, and no standing access to things the task does not touch.
Named individual accounts rather than shared logins, with two factor authentication wherever the system offers it.
The server, the domain, the DNS and the repository sit in accounts you own before the work starts. So the access is yours to grant, yours to watch, and yours to remove without asking me.
Credentials never travel in plain text. They are held in an encrypted password manager, and they are revoked the day an engagement ends.

What I am likely to see

Whatever your systems hold. Customer enquiries and their contents, order and booking records, CRM contacts, staff accounts, and email addresses sitting inside logs, exports and database backups.

I do not go looking beyond the task. But a database backup contains the whole database, and a server log contains everyone who visited, and I am not going to write a policy that pretends otherwise. If there is a table you would rather I never opened, say so at the start and it goes in the engagement agreement.

Copies, staging and backups

Production data is not copied out of your systems except where the work needs it: reproducing a fault, testing a migration, or checking that a backup actually restores.
Where a copy is made, it stays on systems I control, it goes to nobody else, and it is deleted when the task is done.
Where a staging environment would have to hold real customer data for longer than a single task, I tell you first and we agree it. Anonymised or reduced data is used instead wherever the work allows it.

Other services in the chain

Some work needs services underneath it: hosting, offsite backups, monitoring, email delivery. Those are sub-processors, and they are named on request for the same reason and with the same rule as above.

I do not add a new service that touches your data without telling you first.

Where your data goes

Your systems stay where you put them. Moving your data to another country is not something that happens as a side effect of ordinary work, and where a migration would move it, that is part of the scope you agree.

The honest part is about me rather than the servers. I work remotely and my base is not always inside the European Economic Area, so your data may be accessed from outside it. Under the GDPR that is an international transfer, and a transfer needs a written safeguard, usually the European Commission’s standard contractual clauses.

The data processing agreement, and where it stands

There is no standard data processing agreement published here yet. What is written above is how the work is actually done, and it is accurate, but a description on a web page is not a signed contract and you should not treat it as one.

So: if your organisation needs a signed data processing agreement, including the transfer clauses, say so in the first conversation. I will not take access to a system holding personal data before one is agreed, if you need one. Raising it early costs nothing. Raising it in week three costs both of us a fortnight.

If something goes wrong

If I become aware of a breach affecting your data, I tell you without undue delay and in any case within 72 hours, with what I know at that point even when the picture is incomplete. I do not wait until I have a full account, because your own 72 hour clock starts when you are told and not when I finish investigating.

You then get whatever I have that helps you meet your own duties: what happened, when, which systems, which data, what has been done, and what is still unknown.

When the engagement ends

Access is revoked the day it ends, and you can revoke it yourself the same day, because the accounts are yours.
Working copies, exports and staging data are deleted. Backups I hold expire on their own schedule, and I will tell you what that schedule is rather than leave you to assume.
You already hold the credentials, the accounts and the written runbook from the first week, so the exit is a handover meeting and a revocation list. Nothing has to be reconstructed and nothing is held back.
If you want written confirmation of what was deleted and when, ask and you get it.

Part three: the audit

The audit runs across the servers, the site, the data and the automations between them. It needs read access, and read access to a live system means seeing live data. It is worth being clear about that before you grant it rather than after.

The notes, exports and screenshots taken to produce the assessment are kept while the engagement is live and deleted when it ends, or sooner if you ask.
The written assessment is yours, whether or not anything follows.
It names systems, versions and configuration, which is exactly the material an attacker would want. It is not published, not used as an example, and not shown to anyone else without your written agreement.

Which law this is written to

Two regimes apply here and neither is optional. I work from Nigeria, so the Nigeria Data Protection Regulation applies to me. Most of the clients whose systems I hold access to are in Northern Europe, so the General Data Protection Regulation applies to that work. The two are close in substance, and where they differ this policy follows the stricter of the two rather than the more convenient one.

That is also why this site sets no cookies. It is not an oversight and it is not a gap waiting to be filled with a consent banner. A site that collects nothing has nothing to ask consent for, nothing to leak, and nothing to explain when somebody asks what it knows about them. The cookie policy sets out what was checked and what was found.

Changes to this policy

An updated version is posted here with its date. If a change materially affects an engagement that is already running, I tell you directly rather than leave it for you to find.

Contact

Everything on this page goes to [email protected], or through the contact page, which gets an answer the same working day.

See also the cookie policy, which lists what this site stores in your browser, and the terms of service.

Last updated 20 August 2026.