Data processing terms
Updated 7 October 2026
These data processing terms form part of my Terms.
Between you (the business hiring me, the controller) and Garry McEwen, trading as Once, Not Twice, 38 Vernon Rd, Greenmount, Bury, BL8 4DD, garry@oncenottwice.co.uk (me, the processor).
This addendum forms part of my Terms of business. It applies to every job where I can see or handle personal data in your systems. Words like "personal data", "processing", "controller", "processor", "data subject" and "personal data breach" mean what they mean in the UK GDPR.
1. Roles and what I do
1.1 You decide why and how your personal data is used. You're the controller. I process it only to build, test, hand over and (in the fix window) fix the job in the job sheet. I'm your processor.
1.2 Annex 1 (filled in for each job, in the job sheet) sets out the subject matter, duration, nature and purpose of the processing, the types of personal data, and the categories of data subjects.
1.3 You confirm you have a lawful basis for the processing and that you've told the people concerned what they need to know.
2. Instructions
2.1 I process your personal data only on your documented instructions. The job sheet, these terms and your written messages (WhatsApp or email) are your instructions. That includes any transfer outside the UK (section 7).
2.2 If the law requires me to do something else, I'll tell you first unless the law forbids it.
2.3 If I think an instruction breaks data protection law, I'll tell you straight away and pause that part.
3. Confidentiality
3.1 I'm a sole trader and do the work myself. If anyone else ever works on your job (for example a subcontractor you've approved under section 5), they'll be bound by confidentiality before they get access.
4. Security
4.1 I take the measures in Annex 3, appropriate to the risk, as Art. 32 requires.
4.2 You're responsible for the security of your own systems and accounts, including giving me least-privilege access (Terms 7.1) and keeping backups (Terms 7.2).
5. Sub-processors
5.1 You give me general written authorisation to use the sub-processors listed in Annex 2, and any added for a job in Annex 1.
5.2 For each job, I list in the job sheet any sub-processor that will touch your personal data (including any AI provider, Annex 4), before you agree the job. If I want to add or change one during a job, I'll tell you in writing first, and you can object. If you object, I won't use it, and we either agree another way or end the job under Terms section 13 with no charge for the change.
5.3 I'll make sure each sub-processor is bound by data protection terms giving at least the same protection as this addendum, in particular sufficient guarantees on security. In practice that's the provider's own data processing terms, which I check before using them.
5.4 I remain responsible to you for my sub-processors.
5.5 Your accounts, not mine. Every build is set up and runs in your accounts (your Zapier, Make or n8n, your API keys for any AI or other service, your email), as the Terms (8.4) say. Those providers are your processors under your contract with them, not my sub-processors. I may sketch a workflow in my own account with made-up test data only. Your personal data never goes through my accounts.
6. Helping you
6.1 People's rights. If someone asks me (rather than you) to see, correct, delete or stop use of their data, I'll pass it to you within 2 working days and not answer it myself. I'll help you respond as far as I reasonably can, given what I hold (normally nothing after handover).
6.2 Security, breaches, DPIAs and the ICO. I'll help you meet your duties under Art. 32 to 36 (security, breach notification, data protection impact assessments and consulting the ICO), taking into account what I do and what I know. Annex 4 covers DPIAs for AI steps.
6.3 Help that takes more than an hour or so beyond the job may be charged at a price agreed in advance, except where it's needed because of my own breach.
7. Transfers outside the UK
7.1 I don't transfer your personal data outside the UK except on your instructions as recorded in the job sheet (for example a US-based tool or AI provider), and only with a valid transfer route: UK adequacy regulations (including the UK Extension to the EU-US Data Privacy Framework, where the recipient is certified for that type of data), or the ICO's International Data Transfer Agreement (IDTA) or Addendum to the EU SCCs, with a transfer risk assessment.
8. Personal data breaches
8.1 If I become aware of a personal data breach affecting your data, I'll tell you without undue delay and in any case within 24 hours, by phone or WhatsApp and then in writing.
8.2 I'll tell you what I know: what happened, what data and roughly how many people, the likely consequences, and what I've done or propose. I'll send more as I find it out.
8.3 I'll take reasonable steps to contain it and help you decide whether to tell the ICO (within 72 hours of you becoming aware) and the people affected. That decision is yours as controller.
8.4 I keep a record of any breach affecting your data.
9. End of the job: deletion
9.1 At handover, or when the job ends for any other reason, I'll remove my access and delete any of your personal data I hold (exports, test files, screenshots, notes, chat attachments) within 7 days. I'll confirm that in writing. If you ask, I'll return a copy first.
9.2 If a copy sits in a backup or service I can't delete from straight away, I'll put it beyond use and let it expire under that service's normal deletion cycle.
9.3 I may keep the job sheet, the handover sheet and our messages (which shouldn't contain your customers' data) as business records (Privacy notice: 6 years).
9.4 I can keep data only if UK law requires me to.
10. Information and audits
10.1 I'll give you the information you reasonably need to show this addendum is being followed: for example my security checklist, sub-processor list, access log for your job, and deletion confirmation.
10.2 You (or an auditor you appoint, bound by confidentiality) can inspect on reasonable notice, at most once a year unless there's been a breach or the ICO requires it, at your cost, and without access to other customers' data.
11. Liability and term
11.1 Liability under this addendum is subject to the cap (the job price) and exclusions in Terms section 11. Nothing limits either of our liability to data subjects or the ICO under the law.
11.2 This addendum lasts as long as I process your personal data, and sections 3, 8, 9 and 10 survive.
11.3 It's accepted in writing, including electronically: your "yes" to the quote that links it.
Annex 1: data section of the job sheet (filled in per job)
| Item | What the job sheet records |
|---|---|
| Subject matter | What the build does, for example joining Gmail enquiries to the Tradify job list |
| Duration | From agreement to deletion 7 days after handover, plus the 30-day fix window if I need access again (you grant it each time) |
| Nature of processing | Read, copy, transform, write or delete, by the automation platform named in the job sheet, and any AI step (Annex 4) |
| Purpose | Building, testing, handing over and fixing the build described in the job sheet |
| Types of personal data | For example names, email addresses, phone numbers, postal addresses, job details, invoice amounts, free-text email content |
| Special category / criminal data | None, unless agreed in writing in the job sheet |
| Data subjects | Your customers, enquirers, staff or suppliers, as listed in the job sheet |
| Where the build runs | Your account on the platform named in the job sheet (Terms 8.4) |
| Sub-processors used for this job (beyond Annex 2) | None, or each one's name, service, location and transfer route |
| AI step? | No, or yes with the Annex 4 record completed |
| Test data | Dummy data, or a small real sample deleted after the test |
| Access method | A separate user for me (for example "garry-ont") and the role it has |
Annex 2: sub-processor list (Garry's own tools)
Only the tools I use to run my business that might touch your data. Automation platforms and AI providers aren't listed: builds run in your accounts and on your keys, so they're your processors (section 5.5).
| Sub-processor | What for | Location / transfer route | Status |
|---|---|---|---|
| Google Workspace (Business Starter) | My garry@oncenottwice.co.uk mailbox and business files (Drive, Docs): job messages and documents, which may include data you send me | Google, may process outside the UK, including the US. Google LLC is certified to the UK Extension to the DPF; Google's Cloud Data Processing Addendum also includes the UK transfer clauses | Confirmed 6 Oct 2026, under Google Workspace's data processing terms (Cloud Data Processing Addendum) |
| WhatsApp (Meta) | Messages with you about the job | Meta, outside the UK, under Meta's own transfer safeguards | Use for job talk only. Please don't send your customers' personal data or passwords over WhatsApp |
Annex 3: security measures (a one-person business)
- 2-factor authentication on every account I use for work (email, password store, automation platforms, AI providers, GitHub, bank, Stripe), using an authenticator app or security key, not SMS where avoidable.
- Unique, long passwords. Customer credentials are stored only in an encrypted password store: never in WhatsApp, email, notes or code.
- Least privilege. A separate user for me in each customer system, with only the permissions the job needs. API keys are scoped to the job. No use of the customer owner's login.
- Removing access at handover. I delete my user or ask you to, revoke my API keys and OAuth connections, delete any stored credentials, and remind you to rotate any shared secret. I record the date.
- Device security. Full-disk encryption, screen lock, automatic OS and browser updates, a reputable anti-malware tool, no shared work computer.
- Minimal copies. Test with dummy data where possible. No local exports unless needed. Any working copy is kept in one known folder and deleted within 7 days of handover.
- Access log. For each job: when access was granted, what I did, and when access was removed.
- Secure building. Secrets kept in the platform's credential store, not hard-coded. Error notifications don't contain personal data where avoidable. Logs and run history retention set to the minimum the platform allows, where you agree.
- Training. I keep up with the ICO's guidance for small businesses (e.g. its data protection essentials).
- Breach readiness. This addendum's section 8 process. Phone numbers for each customer contact kept up to date.
Annex 4: AI steps
4.1 Your choice. An AI step (an LLM API such as OpenAI, Anthropic or Google Gemini, or an AI step inside n8n, Make or Zapier that calls one) is only used if you choose it and it's written into the job sheet. You can say no at any point before handover, and I'll build without it or stop under Terms section 13.
4.2 Named provider, told in advance. The job sheet names the provider, the service or endpoint, whose account it runs in, where data is processed, and the transfer route. It always runs on your account and API key (section 5.5), so the provider is your processor. I still name it in advance, and you can say no.
4.3 No-training tiers only. I only use API or business tiers whose terms say inputs and outputs are not used to train the provider's models by default. I don't opt in to any sharing or feedback programme. Before each job I check the provider's current data-use page and record the result below. What the providers said when I checked on 6 Oct 2026:
| Provider | Training (API / business tier) | Retention to note | Options to record |
|---|---|---|---|
| OpenAI API | "Data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)", since 1 Mar 2023 | Abuse monitoring logs kept "for up to 30 days" by default. Some endpoints keep application state (e.g. the Responses API keeps response data for 30 days by default unless store=false). Files, vector stores etc. are kept until deleted | Zero Data Retention or Modified Abuse Monitoring need OpenAI approval. Record whether store=false is set |
| Anthropic (Claude) API / commercial | By default, commercial-product inputs and outputs aren't used to train models. The exceptions are feedback you give, explicit opt-in (e.g. the Development Partner Program), and content flagged for trust and safety review | Conversation content not retained by default for the API, but: some "covered models" require 30-day retention; content flagged for policy violations can be kept up to 2 years; some features store data (e.g. Batch results ~29 days, Files until deleted) | Zero Data Retention is available on request for eligible customers. Record the model and features used |
| Google Gemini API | Paid services: prompts and responses not used to improve Google's products, processed under Google's data processing terms. Unpaid services: may be used to improve products, and humans may review them. Google says "You may use only Paid Services when making API Clients available to users in the European Economic Area, Switzerland, or the United Kingdom", and that for users in those places the paid-service data terms apply to all services | Prompts and responses logged for a limited period for abuse monitoring. Grounding with Google Search or Maps stores prompts and context for 30 days | Record that a paid (billing-enabled) project is used, and whether grounding is off |
| AI step inside n8n / Make / Zapier | Depends on the underlying model provider and whether the platform's own AI feature or your own API key is used | Platform run history may store inputs and outputs | Not verified. Use your own API key in a standard HTTP/LLM node, so the provider terms above apply. Check the platform's AI terms per job |
Per-job record (kept with the job sheet): provider; service or model; account (yours, with the account name or ID); training off or not used (source URL and date checked); retention setting (for example store=false, Zero Data Retention or the default 30 days); data region; transfer route; fields sent; human check point; the date I checked it.
4.4 Minimal data. The AI step gets only the fields the task needs (e.g. the email body and sender domain, not the whole thread history or attachments), stripped where practical. No special category or criminal-offence data (health, religion, ethnicity, sexuality, politics, union membership, genetics, biometrics, criminal records) unless you agree it in writing in Annex 1, after a DPIA.
4.5 Transfers. OpenAI, Anthropic and Google process data mainly in the US. The transfer route is recorded per job:
- (a) the UK Extension to the EU-US DPF (the "UK-US data bridge"), if the provider is certified and the certification covers the data type. Google LLC states it's certified (checked 6 Oct 2026). OpenAI's and Anthropic's certification status was not verified on 6 Oct 2026. Check the DPF list per job; or
- (b) the provider's data processing terms incorporating the ICO IDTA or the UK Addendum to the EU SCCs, with a short transfer risk assessment; or
- (c) a UK or EU data-residency option, if the provider offers one for that service.
4.6 A human checks. If the AI step drafts or decides anything that will go to your own customers or the public (e.g. a reply email or a quote), the build holds it for one of your people to check and approve before it goes, unless we agree in writing that a specific low-risk step can run unchecked. The AI step doesn't make decisions with legal or similarly significant effects on people (for example refusing someone service) without a human decision.
4.7 DPIA. You're the controller, so the DPIA is yours to do. I'll give you a short template filled in with the technical details and help you complete it. The ICO says that "in the vast majority of cases" using AI involves processing likely to be high risk, so a DPIA is needed, and if you decide one isn't, you should document why. The ICO's list of likely high-risk processing includes innovative technology (including AI) when combined with another factor such as large-scale processing or invisible processing, and gives the "application of AI to existing process" as an example. My recommendation: do a short DPIA (1–2 pages) for any build where AI reads a mailbox or documents containing other people's personal data, and always if it runs across a whole inbox or at volume. If the DPIA shows a high risk you can't reduce, don't go ahead (or consult the ICO).
4.8 Accuracy. AI output can be wrong. Terms section 9.6 applies.