Data Processing Agreement.

Parties

1. What this is

You are the controller of the personal data your customers give you. We are your processor: we hold and handle it only to run the website and dashboard you pay us for.

This document is the written contract Article 28(3) of the UK GDPR requires between a controller and a processor. Both of us need it to exist.

2. Our obligations

We agree that we will:

2.1 Process only on your instructions. We will process personal data only as needed to provide the service, as set out in Annex A, and on your documented instructions. If we think an instruction breaks data protection law, we will tell you and may pause until it is resolved.

2.2 Keep it confidential. Everyone with access is bound to confidentiality. As of the date of this agreement that is one person: Declan Morton. We will tell you if that changes.

2.3 Keep it secure. We will apply appropriate technical and organisational measures under Article 32. What is in place is listed in Annex B— that annex describes the present, not an ambition.

2.4 Not add a sub-processor without telling you. You give general authorisation to the sub-processors in Annex C. If we want to add or replace one, we will give you 30 days’ notice by email. If you object on reasonable data protection grounds within that time, we will work with you to find an alternative; if we cannot, you may cancel without penalty for the remainder of the term. Every sub-processor is under written terms no less protective than these.

2.5 Help you answer your customers.If one of your customers asks you for a copy of their data, or asks you to correct or delete it, we will help you answer within your one-month deadline. We will pass on any request that reaches us directly rather than answering it ourselves — you are the controller and the answer is yours. What the product can do today is set out in Annex D.

2.6 Help you with security, breaches and assessments. We will assist with Articles 32 to 36 to the extent reasonable for the size of our business, taking account of what we know that you do not.

2.7 Tell you about a breach without undue delay. If we become aware of a personal data breach affecting your data we will notify you without undue delay and in any event within 24 hours of becoming aware. Your own clock for reporting to the ICO is 72 hours, and 24 hours is set deliberately to leave you time inside it. We will tell you what happened, what data and roughly how many people are affected, what we are doing, and what you should consider doing.

2.8 Delete or return your data when we are done. On cancellation your data is kept for 30 days so you can change your mind or take an export, then the site and its database are permanently deleted, unless the law requires us to keep something (financial records). Ask us at any point during that window and we will give you an export.

2.9 Give you the information you need to check. We will make available the information needed to show we are meeting these obligations, and allow audits or inspections by you or an auditor you appoint, on reasonable notice, no more than once a year unless a breach or a regulator requires more. We may charge for time on anything beyond a reasonable enquiry.

3. Your obligations

You agree that you will:

• have a lawful basis for everything you collect;
• give your customers your own privacy notice;
• make sure your instructions to us are lawful;
• not put special category data into free-text fieldsunless we have agreed in writing how to handle it — see section 5, which is the clause that matters most;
• keep your staff logins secure and remove access when someone leaves.

4. International transfers

Some of our sub-processors are outside the UK. Annex Csays which. Where a transfer needs a mechanism, we rely on the one contained in that supplier’s own data processing terms — in each case either the UK International Data Transfer Addendum to the EU Standard Contractual Clausesor the supplier’s own UK-approved mechanism, incorporated into our contract with them by their standard terms rather than negotiated separately by us.

5. Special category data

Our product contains free-text fields. They are not designed, secured or contracted for special category data, and you must not use them for it.

If you need to record health information — allergies, skin conditions, medication, pregnancy — to serve your customers safely, tell us. We will build a flow for it, with consent capture and handling appropriate to Article 9, and we will amend this agreement to cover it. Until then, this agreement does not authorise us to process special category data on your behalf, and doing so anyway would be a breach of your obligations under section 3.

6. Liability and governing law

Liability under this agreement is subject to the limits in our Terms of Service. Nothing here limits either party’s direct liability to a data subject or a regulator under the UK GDPR.

This agreement is governed by the law of Scotland, and its courts have exclusive jurisdiction.

Annex A — What we process, and why

Types of personal data. Taken from the live database schema, not from a generic list.

ChairTime — salon booking

OrderBoard — food ordering

Annex B — Security measures in place

The Article 32 measures we apply, described as at the date on this page. Nothing appears here that is not true of the running system.

Access control

• Passwords stored as bcrypt hashes; driver PINs likewise.
• Role-based access. In ChairTime the role is re-read from the database on every permission checkrather than trusted from the session token, so removing someone’s access takes effect immediately.
• An automated attack suite calls every owner-only action with a staff session and asserts the action never reaches the database — with a completeness check that fails the build if a new action is added and left unclassified.
• Two-factor sign-in (password plus emailed code) on the operator account.

Tenant separation

• Each client’s site runs as its own deployment with its own database. There is no shared customer table. One client’s site cannot query another’s, because there is no shared database to query.

Transport and network

• HTTPS throughout, HSTS with preload.
• Security headers on every response: X-Content-Type-Options, Referrer-Policy, X-Frame-Options / frame-ancestors, Permissions-Policy.
• Rate limiting on every public endpoint, keyed on a client IP derived from the trusted end of the proxy chain rather than from a header the caller controls.

Payments

• No card number, CVV or expiry date is ever stored, transmitted or logged by us.Card entry happens on Stripe’s own hosted or embedded elements.
• Stripe webhook signatures verified on every event, failing closed if a secret is missing.
• Prices are always recalculated server-side from the database. A client-supplied price never reaches Stripe.

Application security

• All database access through a parameterised ORM. No unsafe raw SQL.
• Customer-supplied values escaped before being rendered into emails.
• CSV exports neutralise spreadsheet formula injection.
• Uploaded images validated by file signature rather than by their declared type, and EXIF metadata (including GPS) stripped before storage.
• No credential has been committed to source control, verified across every commit in every repository.

Logging

• Request logs redact query strings, referrer headers, phone numbers in URLs and email addresses.
• Database bound parameters are not logged.

The limits of those measures

You are relying on this annex to write your own notice and to answer your own customers, so it states the boundaries as plainly as it states the controls.

• Backups. A weekly export of key business records is taken off site. It is not a full database dump and we do not offer a restore time. Treat any data you would be unable to recreate as worth exporting yourself.
• Encryption at rest is whatever our hosting provider applies by default. We do not give a separate warranty for it.
• Deletion happens on request, not on a timer. Erasure works (see Annex D); there is no scheduled job that ages records out. If you need a retention period enforced automatically, ask and we will build it.
• Detection depends on a person. We run no automated alerting, so tell us the moment something looks wrong rather than assuming we have already seen it.
• Content Security Policy is applied to the control plane. The two product surfaces rely on the other headers listed above.
• Operator sessions are revoked in bulk rather than one at a time.
• Payment credentials. Each provisioned store carries a shared platform credential rather than a per-store restricted one. We are moving to per-store credentials; until that lands, a compromise of one store is a larger event than it should be, and you are entitled to know that.

Annex C — Sub-processors

Every entry was checked against the code or the running configuration. Where a supplier receives nothing, it says so.

C.1 Core infrastructure

C.2 Correspondence

Because the enquiry form keeps no database record, a mailbox is acting as the store for that data. It means there is no automatic retention period on it, deletion is by hand, and answering a subject access request about an enquiry means searching a mailbox.

C.3 AI processing

Images are forwarded for the import and are not persisted. If AI features ever extend to customer records — summarising client notes, drafting messages to customers — this row changes completely and we will amend this agreement before that ships.

C.4 Called from your customer’s browser (OrderBoard)

These are not conventional sub-processors: the data goes from your customer’s browser straight to the third party without passing through us. They are listed because we designed them in, so you must be told and must disclose them in your own notice.

C.5 Optional integrations

C.6 Recorded so you do not have to wonder

• No SMS provider. The database models an SMS notification channel and nothing sends through it. No text message is sent by any product.
• No analytics, tag manager or advertising pixel on any surface — see our Cookie Policy.
• SMTP is a fallback that cannot run.Our hosting platform blocks outbound SMTP ports, so every message — service email and marketing alike — leaves through Resend.

Annex D — What we can do for a data subject request

You will be the one promising a customer an answer within a month, so this says what the product can actually do rather than what the law asks for.

On erasure, specifically. The approach is anonymise rather than delete: identity, contact details and every free-text note are destroyed, while the appointment, order and payment rows are kept because tax law requires the financial record and, once the identifying fields are gone, they name nobody.

Three limits worth knowing before you promise anything:

1. ChairTime retail salesrecord a buyer name and email with no link to the client record. Erasure reports these as unreachable rather than guessing by name — matching on a name could erase a stranger. They are handled by hand.
2. Stripe keeps its own copy under its own retention policy, outside our control.
3. Any weekly backup export already emailed is a copy in a mailbox. Erasure does not reach it.

See also our Terms of Service, our Privacy Notice and our Cookie Policy.