Data Processing Agreement

Field 2 Service — Data Processing Agreement (DPA)

---

0. How this Agreement works

0.1 Incorporation and acceptance

This Agreement forms part of, and is incorporated by reference into, the Field 2 Service Terms of Service. By accepting the Terms of Service — which you do when you create an account, start a trial, or continue to use the service — you also accept this Agreement, and you confirm you have authority to accept it for the business you represent. No separate signature is required: Article 28(9) of the GDPR expressly permits a processing contract to be concluded in electronic form.

Your acceptance is recorded against your account with a timestamp and the version of the Terms of Service in force at that moment.

0.2 When it takes effect

This Agreement takes effect on the earlier of (a) the date you accept the Terms of Service, and (b) the date any personal data is first supplied to us for processing on your behalf. It replaces any earlier version of this Agreement between us.

0.3 Precedence

If anything in this Agreement conflicts with the Terms of Service, or with any other document between us, this Agreement prevails in relation to the processing of personal data. If anything in this Agreement conflicts with the Standard Contractual Clauses or the UK Addendum referred to in section 8, those clauses prevail.

0.4 One document, every jurisdiction

We are established in Ireland and we sell worldwide. This Agreement is written to satisfy the EU GDPR and the UK GDPR at the same time; where those two regimes differ, the difference is stated in the clause itself or in Annex 4 (UK Addendum).

Sections 0 to 14 are the core and apply to every customer everywhere, drafted to the strictest formulation of each obligation we found rather than to the European minimum; section 14 explains how what follows fits together. Sections 15 to 17 — destination countries, retained control and retention floors — also apply to everyone. Sections 18 to 27 are short jurisdiction-specific riders for the handful of laws that require something the core cannot express — California's service-provider terms, the United States state laws, South Africa, Singapore, Brazil, Japan, Switzerland, Australia, Quebec and India — and each applies only where that law applies to you.

0.4.1 Precedence between the core and a jurisdiction section

Where a jurisdiction-specific section conflicts with the core, the one giving the data subject more protection prevails; on a point of form rather than protection, the jurisdiction-specific section prevails for a customer in that jurisdiction. Nothing in sections 15 to 27 reduces the core for anyone.

0.5 Honesty about what the product does

Every operational commitment in this Agreement describes something we can actually do today. Where a capability that a controller might reasonably expect does not exist in the product, or exists only as a manual process, it is disclosed in Annex 5 (Statement of current capabilities and limitations) rather than glossed over. Annex 5 forms part of this Agreement, and you should read it before you decide whether Field 2 Service is an appropriate processor for your processing.

---

1. Definitions

"Applicable Data Protection Law" means, as the context requires: (a) Regulation (EU) 2016/679 (the EU GDPR) and the Data Protection Act 2018 (Ireland); and (b) the UK GDPR as defined in section 3(10) of the Data Protection Act 2018 (United Kingdom), together with that Act as amended, including by the Data (Use and Access) Act 2025.

"controller", "processor", "sub-processor", "data subject", "personal data", "personal data breach", "processing" and "supervisory authority" have the meanings given to them in Applicable Data Protection Law.

"Customer Personal Data" means personal data that we process on your behalf under this Agreement, described in Annex 1.

"Services" means the Field 2 Service software-as-a-service platform and any related support we provide.

"Standard Contractual Clauses" or "SCCs" means the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021.

"UK Addendum" means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the Information Commissioner under section 119A of the Data Protection Act 2018 (UK).

"Supervisory Authority" means the Data Protection Commission of Ireland (the DPC) for the EU GDPR, and the Information Commissioner's Office (the ICO) for the UK GDPR.

---

2. Roles of the parties

2.1 You are the controller of your business data

You are the controller of all personal data you and your users put into, or generate within, the Services — your customers and their contacts, your leads and enquirers, your staff and engineers, and anyone else whose details appear in your account. You decide why and how that data is processed. We are your processor for it, and we process it only on your instructions.

2.2 We are the controller of our own account data

We are a controller, not your processor, in respect of: your account holder and billing contact details; your subscription and payment records with us; support tickets you raise with us; and enquiries submitted through our marketing website. That processing is governed by our Privacy Policy, not by this Agreement.

2.3 We do not become a controller of your data

We will not use Customer Personal Data for our own purposes. We do not use personal data to train any AI model, we do not provide it to anyone else to train theirs, and we do not sell it or share it for advertising. The terms on which the configured AI provider handles data sent to it, including its position on training, are recorded on our published Sub-processor list; section 6.6 sets out that position.

2.4 Sufficient guarantees

We provide the guarantees required by Article 28(1) by implementing the measures in Annex 2 and by disclosing, in Annex 5, the limitations of those measures, so that you can make an informed assessment.

---

3. Subject matter and details of the processing

The subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subject are set out in Annex 1, which forms part of this Agreement. Your obligations and rights as controller are set out in section 4 and in Applicable Data Protection Law.

---

4. Your obligations as controller

4.1 Lawfulness

You warrant that you have a lawful basis under Article 6 (and, where special categories of data are involved, Article 9) for every processing operation you instruct us to perform, and that your instructions to us are lawful.

4.2 Your own transparency duty

You warrant that you have given the individuals whose data you put into the Services the information required by Articles 13 and 14 — including that a service provider hosts the data on your behalf, and who that provider is. We do not give that notice on your behalf and we cannot. Where those individuals use the customer portal or the public booking page, you should publish your own privacy notice and make it reachable from those surfaces.

4.3 Accuracy of what you enter

You are responsible for the accuracy, quality and legality of the Customer Personal Data, and for the means by which you acquired it.

4.4 Special-category and criminal-offence data

The Services are not designed for, and must not be used to store, special categories of personal data under Article 9 (including health, disability or vulnerability information) or criminal-offence data under Article 10, unless you have first agreed that use with us in writing. Free-text fields — job notes, access instructions, completion sheets and message threads — are the usual place this happens by accident, and you are responsible for the content your users enter there.

4.5 Your users, your credentials

You are responsible for your users' access: issuing and removing accounts as people join and leave, enforcing the role permissions the product provides, and enabling two-factor authentication where you consider it appropriate. We cannot detect misuse of validly issued credentials on your behalf.

4.6 Features that send data onward at your direction

Several features transmit Customer Personal Data outside the platform because you switch them on and configure them. In each case you are instructing that transfer, and you are responsible for its lawfulness:

• Webhooks and API integrations. If you configure a webhook endpoint, we deliver the full record for the triggering event — including the complete customer record on customer events — to whatever URL you save, including automation tools such as Zapier. We do not control, and cannot vet, the recipient.
• Email and SMS. Messages are sent using the mail and SMS credentials you configure.
• The AI assistant. See section 6.6.
• Payment links. Where you enable an online payment provider, invoice details are transmitted to it.

4.7 Automated decision-making you choose to enable

The AI assistant proposes actions and a person confirms them. The one exception is Smart Dispatch Auto-pilot, an optional per-company setting that is off by default: when you turn it on, up to six scheduling actions per assistant turn — reassigning or re-sequencing your own engineers' work — are applied without an individual confirmation. Every such action is capped, logged and reversible, and no action that is destructive or money-related can ever auto-apply. Turning that setting on is your decision as controller, including any assessment you need to make under Article 22 in relation to your own employees.

4.8 Cooperation

You will provide us with any information we reasonably need to comply with this Agreement, and you will notify us promptly of any change in your instructions.

---

5. Our obligations as processor

5.1 Processing only on your documented instructions

We process Customer Personal Data only on your documented instructions, including in relation to transfers to a third country, unless we are required to process it by EU or Member State law (or, for UK controllers, UK law) to which we are subject. Where such a legal requirement applies, we will inform you of it before processing, unless that law prohibits us from doing so on important grounds of public interest.

Your documented instructions consist of: this Agreement; the Terms of Service and Acceptable Use Policy; the configuration choices you make in the product (the modules, integrations, automations and retention settings you switch on or off); and any further written instruction you give us and we accept. Switching a feature off withdraws the instruction to use it.

5.2 Unlawful instructions

If we consider that an instruction from you infringes Applicable Data Protection Law, we will inform you immediately. We may suspend performance of that instruction until it is withdrawn, amended or confirmed.

5.3 Confidentiality of personnel

Access to Customer Personal Data is limited to those of our personnel and contractors who need it to provide, support or secure the Services. Before being granted access, each is required to give a written confidentiality undertaking that survives the end of their engagement, or to be under an appropriate statutory obligation of confidentiality. We keep access to the minimum required and remove it when it is no longer needed.

5.4 Security

We implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as required by Article 32. Those measures are described in Annex 2, and their present limitations are disclosed in Annex 5. We keep the measures under review and may update them, provided the level of protection is not reduced.

5.5 Sub-processors

We engage sub-processors only in accordance with section 6.

5.6 Assisting you with data subject requests

Taking into account the nature of the processing, we will assist you by appropriate technical and organisational measures, insofar as this is possible, to respond to requests to exercise rights under Articles 15 to 22.

What you can do yourself, in the product:

• Search, view and correct any record in your account (Article 16).
• Export list data as CSV from the customers, jobs, quotes, invoices, leads, tasks, tickets, price book, assets, expenses and activity-log screens, and export reports.
• Remove a record to the recycle bin, and control the visibility of records in the customer portal.
• Set your own retention windows for customer-portal and staff message threads.
• Export everything the Services hold about one individual as a single archive — a README, one spreadsheet per table holding their data, and a summary naming every table searched including the empty ones — from the customer record, by a user you have granted the data-subject-rights permission (Articles 15 and 20). A signed-in customer-portal user can download their own copy of the same archive, which withholds your staff's names, their IP addresses, notes marked internal, and credentials.
• Erase one individual (Article 17), from the same record and the same permission, confirmed by typing the record's reference. The financial record survives in anonymised form as Article 17(3)(b) requires; everything else — notes, files and the files themselves, messages, message logs, the activity log, the portal credential, the recycle-bin snapshots — is deleted, and that customer's public payment and quote links are revoked. A customer-portal user can ask you for erasure; the request reaches your office as a notification and is yours to decide, because only you can weigh Article 17(3).

What requires our help, and how quickly you get it. The per-person export and erasure above answer most Article 15, 17 and 20 requests from the screens themselves (Annex 5, items L1 and L4). What they do not reach is uploaded file binaries (Annex 5, item L3), restriction of processing (below), and anything that needs work against the database itself. Where a request cannot be satisfied from the screens above, we will do the work manually against your database. If you notify us of a request within five business days of receiving it, we will:

• acknowledge your request for assistance within two business days; and
• provide the assistance — a compiled extract for an access or portability request, or a documented erasure, rectification, restriction or objection action — within ten business days, or, where the request is complex or covers a large volume of records, within twenty business days and in any event in time for you to meet your own one-month deadline under Article 12(3).

We provide this assistance at no charge for a reasonable volume of requests. If your volume of requests materially exceeds what is reasonable for the Services, we will discuss a fair charge with you before doing the work, and we will not refuse or delay assistance while that discussion is open.

Restriction of processing (Article 18) is not implemented as a state in the product. We give effect to a restriction instruction by an agreed manual measure — for example flagging and isolating the records concerned, and suspending automations that would otherwise contact the data subject — and we record what we did.

We will not respond to a data subject directly. If a data subject contacts us about data in your account, we will tell them that you are the controller, direct them to you, and notify you promptly. We will not disclose Customer Personal Data to them, or act on their request, unless you instruct us to or we are legally required to.

5.7 Assisting you with security, breaches, DPIAs and prior consultation

Taking into account the nature of the processing and the information available to us, we will assist you in complying with Articles 32 to 36. In practice that means:

• Article 32 — the measures in Annex 2, the honest limitations in Annex 5, and answers to your security questions under section 5.9.
• Articles 33 and 34 — the breach commitments in section 7, including the facts you need for your own notification to the DPC or the ICO and, where applicable, to data subjects.
• Article 35 — on request, the information you need for a data protection impact assessment, including our own data protection impact assessment of the AI assistant: what data it sends, to whom, under what safeguard, what is retained, and what the product's confirm-and-undo controls actually do.
• Article 36 — reasonable cooperation if you must consult a supervisory authority before processing.

We cannot help you demonstrate your Article 6 lawful basis from the product's records: there is no field on a customer record that captures why you hold that person's data or where their consent came from (Annex 5, item L6). You should keep that record outside the Services. The product does record every change to a customer's email and SMS contact preferences from 6 September 2026 — old value, new value, source, acting user and IP address — which evidences that a preference moved, and not a lawful basis.

5.8 Deletion or return of data at the end of the Services

During the term. You may remove records to the recycle bin at any time, and the bin's "permanently delete" removes the row, its related records, its uploaded files and the deletion snapshot (Annex 5, item L1). It is refused where live financial records still depend on the record. Where you need to erase one individual — and keep the financial record that Article 17(3)(b) protects — use the erasure action on the customer record (Annex 5, item L4) rather than the bin.

At the end of the Services. At your choice, we will either return or delete all Customer Personal Data, and delete existing copies, unless EU, Irish or UK law requires us to keep it. Where you give us no instruction, the timeline is: access ends on cancellation; we retain the Account database for a thirty-day reinstatement grace period; we then write to the account contact giving at least thirty days' notice to take an export; and we delete the Account database ninety days after the Services end.

• Return. On your written request we will provide a complete export of your tenant database as a verified archive within thirty days of the request. We can produce this at any time, including while your Account is live and during the cancellation grace period; where our standard tooling is not available we take the export manually. Uploaded files — photographs, signed completion sheets, receipts and imported documents — are stored separately and are not included in that archive (Annex 5, item L3); we will supply them as a separate archive on request in the same period.
• Deletion. On your written instruction we will delete your tenant database and any export archives we hold within thirty days of the instruction. If you give us no instruction, we will delete them ninety days after the Services end, having first given you at least thirty days' written notice to the account contact so that you can take an export.

> Deletion of a tenant database is run by hand by our operations team — from a single command, or from a > button in our administration console — and never automatically: nothing in the product deletes a > database on a timer, and the monthly review of cancelled accounts is what brings a due deletion to > somebody's attention. The preconditions are checked by the software itself rather than by the person > running it, and where one of them has an alternative that alternative is recorded with the deletion and > is not a silent waiver: the account must be cancelled or closed; the thirty-day reinstatement grace must > have passed; the ninety days must have run, or you must have given us a written instruction, which > is recorded by its reference; a verified export of the database must still exist and must still verify > against its own manifest, or the reason for proceeding without one is recorded with the deletion; > and the database name must match your account's own. We confirm > each deletion to the account contact in writing.

• Manual process. Both of these are performed by our operations team. There is no self-service account deletion in the product (Annex 5, item L2). We will confirm completion to you in writing.
• What survives the deletion. Your account record, our administrative audit log, and our support, agreement, data-subject-request and breach records are kept after the database is deleted. They are the evidence that the deletion happened and when, and we hold them under our own Privacy Policy rather than under this Agreement.
• Backups. Any backups operated at the hosting layer are the hosting provider's — [[OWNER: hosting provider and data-centre location]]. Separately, since 6 September 2026 we have our own encrypted database backup mechanism, whose artefacts are encrypted with a key held apart from the application's own and are pruned after thirty days, never below one surviving copy per database. That is a mechanism, not a commitment: today it writes to the same host it protects, no copy is held off-site, no key custody arrangement is in place and no recovery time or recovery point is stated, and this Agreement still makes no uptime, backup or disaster-recovery commitment (Annex 5, item L14). Data in a backup is isolated from active processing and is overwritten in the ordinary backup rotation; deletion propagates to backups on that cycle rather than immediately. Until it does, we will not restore deleted Customer Personal Data into active use except to recover the account at your request.
• Legal retention. We may keep the minimum data required by law — for example billing records we must keep for accounting and tax purposes — and we will keep it only for that purpose and for the statutory period.

5.9 Information and audits

We will make available to you all information necessary to demonstrate compliance with Article 28, and allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate.

• Information. On reasonable written request we will answer a security and data-protection questionnaire and provide the supporting documentation we hold, including the current version of Annex 2 and Annex 5. You may make such a request once per contract year without charge.
• Inspection. Where you have a reasonable, specific concern that is not resolved by the information we provide, or following a personal data breach affecting your data, you may inspect on thirty days' written notice. The once-a-year limit above does not apply after a breach. An inspection takes place during business hours, is limited to what is necessary to assess our compliance in relation to your data, must not compromise the confidentiality or security of other customers, and is subject to confidentiality obligations. Each party bears its own costs, except that we may charge our reasonable costs for an inspection repeated within twelve months without new cause.
• ⭐ Independent assessor, as an alternative to an inspection. Instead of an inspection under the bullet above, we may arrange for a qualified and independent assessor to assess our policies and our technical and organisational measures against an appropriate and accepted control standard or framework, and provide you the resulting report on request. Where we do, the assessment is carried out at least annually and at our own expense, and the report is offered in satisfaction of this section and of the equivalent requirement in your own law. ⚠ No such assessment has yet been carried out and no report exists today: this is the route we will take when one is commissioned, not a description of a report we hold. Until one exists, the information and inspection routes above are what is available (Annex 5, item L16).

• Regulators. Nothing in this section limits the powers of the DPC, the ICO or any other competent supervisory authority.

---

6. Sub-processors

6.1 General written authorisation

You give us a general written authorisation to engage sub-processors, subject to this section. The sub-processors authorised at the date of this Agreement are listed in Annex 3 and maintained, dated and versioned, at https://www.field2service.com/sub-processors.html.

6.2 Notice of changes, and your right to object

Before we add or replace a sub-processor that will have access to Customer Personal Data, we will give you at least thirty (30) days' notice by updating the published list and emailing the account contact we hold for you. You may object on reasonable data-protection grounds by writing to us within those thirty days.

If you object, we will do one of the following:

1. not appoint the sub-processor for your data;
2. make a reasonable change to the Services or your configuration so that the sub-processor does not process your data — for example by leaving the dependent feature switched off for your account; or
3. if neither is reasonably possible, tell you so, in which case you may terminate the affected part of the Services — or, if the sub-processor is essential to the Services as a whole, the subscription — without penalty, with a pro-rata refund of fees paid for the unused period.

Where a change must be made urgently to protect the security or continuity of the Services, we may make it sooner and notify you as quickly as possible; your objection right applies from that notice.

6.3 Flow-down and our liability

We appoint every sub-processor under a written contract imposing data protection obligations that are no less protective than those in this Agreement, and in particular the obligations in Article 28(3). We remain fully liable to you for the performance of each sub-processor's obligations.

6.4 Feature-gated sub-processors

Most sub-processors are engaged only if you switch the relevant feature on. If the AI assistant, SMS, or an online payment provider is off for your account, no Customer Personal Data reaches the corresponding sub-processor. Annex 3 and the published list mark which entries are conditional in this way.

6.5 Recipients you choose

Where you supply the credentials — your own SMTP mail provider, your own SMS account, your own webhook endpoints — you are selecting that recipient and it is not our sub-processor. You are responsible for having an appropriate contract and transfer safeguard with it. We will still treat it as part of the processing chain for the purposes of section 7 (breach notification) where we become aware of an incident affecting it.

6.6 The AI assistant, specifically

The AI features — the in-app assistant, form-assist, AI scan and digest phrasing, and the customer-portal AI — are provided using the configured provider, which is one of xAI Grok, Anthropic Claude, or OpenAI. The platform (super-admin) console names which is live, and the same name appears on the published Sub-processor list. Only that configured provider is engaged. When you use the features, Customer Personal Data — customer names, email addresses, phone numbers, full addresses; job titles, descriptions and notes; quote and invoice figures; engineer names and schedules; and photographs you upload — is transmitted to that provider's API in the United States for the purpose of generating the response. The payload is the same whichever provider is configured.

• Anthropic PBC. Transfers are covered by Anthropic's published Data Processing Addendum, which incorporates the EU Standard Contractual Clauses (Module Two and/or Module Three) and, in Schedule 3, the UK Addendum (https://www.anthropic.com/legal/data-processing-addendum, read 6 September 2026). Anthropic's Commercial Terms of Service, section B, state that "Anthropic may not train models on Customer Content from Services" (https://www.anthropic.com/legal/commercial-terms, read 6 September 2026). Prompt caching is used with this provider only, so content is briefly retained to serve later turns in the same conversation. How long Anthropic retains API content beyond prompt caching is not established; we carry that as an open item on the published Sub-processor list rather than stating a period we have not verified.
• X.AI LLC. Transfers are covered by xAI's published Data Processing Addendum, which records xAI as a processor and incorporates the EU Standard Contractual Clauses (Module Two or Module Three), the UK Addendum, and Swiss FADP modifications (https://x.ai/legal/data-processing-addendum/, read 6 September 2026). xAI's Enterprise FAQ, read 6 September 2026, states that "we do not use your business data, including inputs (prompts) or outputs (answers), for training our models" and that "Inputs and outputs are automatically deleted within 30 days, unless (a) otherwise agreed in writing, (b) xAI is legally required to retain them because, for example, they are flagged as potentially violating our Terms of Service or AUP."
• OpenAI OpCo, LLC / OpenAI Ireland Ltd. Transfers are covered by OpenAI's published Data Processing Addendum, effective 1 January 2026, which incorporates the EU Standard Contractual Clauses (Module Two and/or Module Three) and the UK Addendum; EEA and Swiss data are instructed to OpenAI Ireland Limited, with onward transfers on the Clauses or adequacy (https://openai.com/policies/data-processing-addendum/, read 6 September 2026). OpenAI's enterprise privacy pages, read 6 September 2026, state that "We do not train our models on your organization's data by default" and that API data is not used to train as of 1 March 2023 unless opted in. API abuse-monitoring logs are retained for up to 30 days by default. Zero Data Retention is not in place on this account.
• You can withdraw this instruction at any time by switching the AI features off for your company in Settings (that is the Article 28(2) objection described in section 6.2), or the platform can record a per-tenant opt-out. Either way, no Customer Personal Data leaves for any AI provider. The customer-portal AI is separately gated and is off by default; it is read-only, and it is scoped to the single signed-in customer.
• Images uploaded to the AI assistant are held outside the web root and deleted after sixty minutes.
• Our API key is held by us at platform level; it is never issued per tenant.

---

7. Personal data breach

7.1 Our notification to you

We will notify you of a personal data breach affecting Customer Personal Data without undue delay and in any event within twenty-four (24) hours of becoming aware of it. "Becoming aware" means the point at which we have a reasonable degree of certainty that a security incident has occurred that has led to Customer Personal Data being compromised. That point is reached as soon as that degree of certainty exists: we do not wait for the investigation to be finished, for the scope or the number of records to be established, or for the cause to be confirmed before we are "aware". Both the notification to you and the twenty-four hours run from that moment, and the twenty-four hours is an outer contractual limit measured from it, not a period we intend to use. Where a short period of initial verification is genuinely needed to establish that degree of certainty, it must be brief; it is not a licence to delay.

The twenty-four-hour commitment exists so that you can still meet your own seventy-two-hour deadline to notify the DPC or the ICO. The duty to notify a supervisory authority, and to notify data subjects where the risk is high, is yours as controller, not ours — Article 33(1) and Article 34 apply to the controller, and Article 33's seventy-two-hour clock is yours, not a period we may take before telling you.

⭐ Two rules govern how we apply this, and both are deliberately stricter than what most of the laws behind this clause require of a processor.

1. We tell you immediately on becoming aware, as that term is defined above — not at the end of the twenty-four hours, and not at the end of our investigation. The twenty-four hours is an outer contractual limit, not a period we intend to use, and we send what we have and follow up in phases (section 7.2).
2. ⭐ We apply no risk filter at our end. We do not assess whether a breach is likely to result in a risk, in serious harm or in significant harm before telling you. That judgement is yours, because the test that applies to you depends on your own law and they are not the same test: several regimes have no threshold at all, so every unauthorised access is notifiable; Switzerland's threshold is materially higher than the European one; Australia and New Zealand turn on serious harm; Singapore turns on a prescribed harm list plus a five-hundred-person scale test. A filter applied by us would break at least one of those. So you get everything, and you decide.

⚠ What the twenty-four hours is, and is not. It is a contractual promise we have chosen to make, and it is stricter than what most of the laws above require of a processor — several of which set no clock at all. It is not a statement that we will detect a breach within twenty-four hours: section 7.4 says plainly what our detection actually consists of. If you need a shorter guaranteed notification than twenty-four hours because your own regulator's clock is tighter, tell us before you sign and we will discuss it rather than leaving you to discover the gap.

7.2 What we will tell you

Our notification will describe, so far as we know it at the time:

• the nature of the breach, including where possible the categories and approximate number of data subjects and of personal data records concerned;
• the name and contact details of our point of contact for the incident;
• the likely consequences of the breach; and
• the measures we have taken or propose to take, including any mitigation.

Where we do not have all of that information, we will send what we have within the twenty-four hours and provide the rest in phases as it becomes available, without further undue delay.

7.3 Cooperation and records

We will cooperate with you and take the reasonable steps you direct to assist your investigation, mitigation and remediation, including supplying what you need to communicate with affected data subjects under Article 34. We will keep a record of the facts of each breach, its effects and the remedial action taken. We will not make a public statement identifying you in connection with a breach without consulting you first, unless we are legally required to.

7.4 What detection actually looks like

We keep an activity log of every state change in your account, with the acting user and IP address; a separate platform audit log of administrative actions; a log of every SMS attempt; and records of webhook deliveries. Since 6 September 2026 we also keep a durable, insert-only record of security events — failed sign-ins, account lockouts, password changes, two-factor removals, API-key creation and revocation, data exports, bulk permanent deletions and content-security-policy violations — and four red alert rules fire on it: repeated failed sign-ins from one address, one address attacking several accounts, an export outside working hours, and a batch of twenty-five or more permanent deletions. The record itself is written whatever you have switched on; the alert that follows it is not. Where your plan or your own settings leave the automations module or the Hub switched off, or where you have turned your alert master switch off, the event is still recorded and the alert is still computed but nobody is notified — so on such an account, treat awareness as arising by human report.

That is signalling on authentication and on bulk extraction; it is not security monitoring. We operate no intrusion detection, we do not ship logs to a separate system, we do not protect the logs against alteration, nothing alerts on the platform audit log, and there is no impossible-travel or privilege-change rule (Annex 5, item L8). A failed sign-in against an address that exists in no account is not recorded at all. Detection may still be by human report — from you, from data subjects or from third parties. You should factor that into your own risk assessment, and you should tell us immediately if you see something in your activity log that concerns you.

---

8. International transfers

8.1 Where your data is processed

The Services are hosted by [[OWNER: hosting provider and data-centre location]]. That entry states the hosting provider and the data-centre location, and it is the primary place your data is stored.

8.2 EU ↔ UK

Transfers of personal data from the EEA to the United Kingdom are covered by the European Commission's adequacy decision for the UK. Transfers from the UK to the EEA are permitted under the UK's own adequacy regulations, so no additional safeguard is required between us and a UK customer in either direction. ⚠ The UK instrument in favour of the EEA has not been verified against its primary source in the work behind this Agreement; the European Commission's decision in favour of the UK has. We will confirm it before the next annual review. If it turns out that the UK→EEA leg is not covered by adequacy, we will enter the ICO's International Data Transfer Agreement, or the UK Addendum to the Standard Contractual Clauses, with you for that leg — no such instrument is in place between us today, because none is understood to be needed.

8.3 Transfers to sub-processors outside the EEA and the UK

Some sub-processors are established in the United States. For each such transfer we rely on the safeguards set out in that sub-processor's own data processing agreement with us, which incorporate:

• the Standard Contractual Clauses, Module Three (processor to processor), for transfers subject to the EU GDPR; and
• the UK Addendum to those clauses, or the ICO's International Data Transfer Agreement, for transfers subject to the UK GDPR.

Where a recipient additionally participates in the EU-US Data Privacy Framework or its UK Extension, that may also apply; we do not rely on it alone, because certification is annual and can lapse. Annex 3 and the published sub-processor list state the mechanism relied on for each entry, with the date we last verified it.

You instruct us to make these transfers by using the corresponding features. Switching a feature off withdraws that instruction.

8.4 Copies of the safeguards

You may obtain a copy of the safeguards relied on for any transfer, or details of where they have been made available, by writing to hello@field2service.com. We will respond within thirty days.

8.5 Onward transfers you direct

Transfers that happen because you configured a webhook, an integration, or a mail or SMS provider are onward transfers made on your instruction. You are responsible for their lawfulness, including any transfer safeguard they require. See section 4.6.

8.6 Government and law-enforcement access

If we receive a legally binding request from a public authority for Customer Personal Data, we will notify you before disclosing anything, unless we are legally prohibited from doing so — in which case we will use reasonable efforts to obtain a waiver of the prohibition and will tell you as soon as we lawfully can. We will challenge a request that appears to us to be unlawful or excessive, and we will disclose only the minimum the request requires.

---

9. Liability

9.1 Cap

Each party's liability under this Agreement is subject to the limitations and exclusions of liability set out in the Terms of Service, and those limitations apply to all claims in the aggregate under the Terms of Service and this Agreement together — not separately to each.

9.2 What cannot be limited

Nothing in this Agreement limits or excludes either party's liability where it cannot lawfully be limited or excluded, including: liability for death or personal injury caused by negligence; for fraud or fraudulent misrepresentation; the liability each party has directly to a data subject under Article 82; or the powers of a supervisory authority under Article 83.

9.3 Apportionment between us

If either of us pays compensation to a data subject for damage caused by processing under this Agreement, that party may claim back from the other the part of the compensation corresponding to the other's share of responsibility for the damage.

9.4 Sub-processors

Section 6.3 applies: we remain fully liable to you for our sub-processors' performance of their data protection obligations.

9.5 No relief from statutory liability

Nothing in this Agreement relieves either of us of any liability imposed on us by law by virtue of our role in this processing relationship. A term that purported to do so would be void to that extent, and we do not ask for one. This applies in particular to the liability a controller or a processor bears under Applicable Data Protection Law, to the liability each of us has directly to a data subject, and to the liability an Indian Data Fiduciary bears for processing carried out on its behalf, which its own law imposes irrespective of any agreement to the contrary.

9.6 Our role is a fact, not a label

Whether a person is acting as a controller or as a processor is a fact-based determination that depends on the context of the processing, not on what a contract calls them. A processor that determines the purposes and means of a processing operation becomes a controller of it and answers for it as one. A processor that continues to act on the controller's instructions remains a processor — which is why section 5.1 defines your instructions precisely and section 2.3 says what we will not do with your data. Brazilian law puts the same rule at its sharpest: an operator that fails to follow lawful instructions is treated as a controller and is jointly and severally liable.

---

10. Term

This Agreement continues for as long as we process Customer Personal Data on your behalf. Sections 5.8 (deletion or return), 5.9 (information and audits), 7 (breach), 9 (liability) and 12 (governing law) survive its termination for as long as they are needed to give effect to their purpose, together with any of sections 15 to 27 that gives effect to one of them for your jurisdiction.

---

11. Changes to this Agreement

We may update this Agreement to reflect a change in law, in regulatory guidance, or in how the Services work. We will publish the new version with a new version number and date, and, where the change materially affects your rights or our obligations, we will give you at least thirty days' notice by email to the account contact before it takes effect. If you do not accept a material change, you may terminate the subscription before it takes effect, with a pro-rata refund of fees paid for the unused period. Changes to the sub-processor list are governed by section 6.2, not by this section.

---

12. Governing law and jurisdiction

This Agreement is governed by the laws of Ireland, and the courts of Ireland have exclusive jurisdiction, except that: (a) the Standard Contractual Clauses are governed as provided in those clauses; (b) the UK Addendum is governed as provided in Annex 4; and (c) nothing in this section deprives a data subject of the right to bring proceedings in the courts of their own habitual residence under Article 79(2).

---

13. Contact

---

14. Jurisdiction-specific terms — how sections 15 to 27 work

Sections 0 to 13 are the core of this Agreement and they apply to every customer, everywhere. They are drafted to the strictest formulation of each obligation we found across the regimes we examined, not to the European minimum — so for most customers in most countries the core already does more than local law requires.

Sections 15 to 27 exist because a handful of laws demand something the core cannot express. Each is short and each is additive: nothing in them reduces the core. Sections 15, 16 and 17 — destination countries, retained control and retention floors — apply to every customer, because they are the terms several laws require to be stated at all. Sections 18 to 27 are the ten jurisdiction riders and each applies only where that law applies to you.

We apply the GDPR standard to everyone, everywhere. Where your local law gives you rights beyond it we honour those rights, and they are set out below. We do not claim to be subject to a law that does not apply to us; where a law does apply to us directly it is named.

Two rules of construction follow, and they matter:

1. Where a jurisdiction-specific section conflicts with the core, the section that gives the data subject more protection prevails. Where they conflict on a point of form rather than protection — for example whether an approval must be given in advance — the jurisdiction-specific section prevails for a customer in that jurisdiction.
2. We do not import machinery a law does not ask for. Section 27 deliberately contains no European-style transfer clauses for India, and section 22 deliberately contains no Brazilian standard contractual clauses, because in both cases they would misstate the law. Section 24 says the same about Switzerland. Bolting on unnecessary instruments looks thorough and is in fact inaccurate.

---

15. Destination countries

We may transfer Customer Personal Data to, and process it in, the following countries and territories, and no others: Ireland; the United States; and [[OWNER: hosting provider and data-centre location]].

This is a closed list of the destinations we choose, not an illustration. If a country is not named here, we do not send your data there. It does not cover transfers you direct — a webhook or API endpoint you configure, your own mail or SMS provider, or a payment provider you enable, whose own entity and country are determined by it and by you. Those are onward transfers made on your instruction under sections 4.6 and 8.5, they are recorded in section 3 of the Sub-processor list, and naming their destinations is yours to do where your own law requires it. The list may be added to only through the thirty-day notice and objection process in section 6.2, and the same list is published in section 1.0 of the Sub-processor list, which names which provider sits in which country. If the two ever disagree, the more restrictive of them governs and you should tell us.

We state it this way because several laws require the destinations to be named rather than described: a transfer contract under the Singapore regulations must specify the countries and territories; South Africa requires the onward-transfer restriction in the agreement to be as strong as the original; Australia and Japan both expect the country to be identified where that is practicable; and Canadian guidance expects individuals to be told their data is processed abroad and may be reachable by the courts, law-enforcement agencies and national-security authorities of the countries concerned. Section 8.6 and our published Government and law-enforcement requests policy say what we do when such a request arrives.

What this clause does and does not discharge. For every transfer we make, this section is the named- destination term a Singapore transfer contract requires and the onward-transfer restriction South African law requires, and section 6.3 flows the same restriction down to each sub-processor. For a recipient you choose under section 4.6 — a webhook endpoint, your own mail or SMS account, a payment provider you enable — we do not select the recipient, we do not know its entity or its country, and we cannot name it here. Where your own law requires those destinations to be specified, that is your obligation as controller, and section 3 of the Sub-processor list records the categories so that you can complete it.

---

16. Retained control

For the whole time we hold Customer Personal Data:

1. You retain the power to access, modify, retrieve and delete it, through the Services and, where the product's own tooling does not reach, through a written request under section 5.6 or 5.8;
2. our functions are limited to those this Agreement specifies — we act on your instructions and for your purposes, and section 2.3 sets out what we will not do; and
3. every sub-processor is bound to the same obligations we owe you (section 6.3).

This is not decorative. Under Australian law, an organisation that retains effective control of information it sends to a service provider is making a use rather than a disclosure — so the cross-border principle in APP 8, and the strict onward liability in s.16C for the recipient's and its subcontractors' conduct, do not engage at all. The same reasoning supports the agent characterisation in New Zealand and the "use, not disclosure" analysis in Canada. The clause is drafted deliberately, so that an Australian, New Zealand or Canadian customer can rely on it.

---

17. Retention, where your law sets a floor

Section 5.8 gives you the choice of return or deletion, and the Data Retention Schedule states our defaults. Where your own law imposes a minimum retention period that is longer than the period you have chosen, tell us and we will hold the data for that period instead, and only for that period.

⚠ This is not a theoretical clause. India's rules will require a Data Fiduciary to cause its processor to retain personal data, traffic data and processing logs for at least one year before erasure — a floor that runs in the opposite direction from European storage limitation and from Singapore's retention-limitation obligation. A single global purge schedule cannot satisfy both, so retention is a per-customer position, not a platform-wide one. If you are subject to a retention floor, it is your instruction under section 5.1 that puts it in place.

---

18. California — service-provider rider

This section applies where you are a "business" and we are a "service provider" under the California Consumer Privacy Act. It exists because a European Article 28 agreement does not satisfy the CCPA: six of the ten terms California requires have no European equivalent, and a provider without a compliant contract is not a service provider at all — which would put you, not us, in the position of having "sold" personal information.

Terms defined in the CCPA and its regulations have their CCPA meanings in this section.

We are your service provider. We:

1. will not sell or share the personal information you disclose to us;
2. process it only for the specific business purposes set out in Annex 1, which are described specifically and not in generic terms, and you disclose it to us only for those limited purposes;

1. will not retain, use or disclose it for any purpose other than those business purposes, including not for a purpose listed as a business purpose in the regulations unless this Agreement permits it;

1. will not retain, use or disclose it for any commercial purpose other than those business purposes;

1. ⭐ will not retain, use or disclose it outside the direct business relationship between us, and will not combine it with personal information we receive from, or on behalf of, any other person, or collect ourselves — except where the regulations permit a service provider to do so;

1. will comply with the applicable obligations of the CCPA and its regulations, and will provide the same level of privacy protection the CCPA requires of you, including the duty to implement and maintain reasonable security procedures and practices under Civil Code §1798.81.5;

1. grant you the right to take reasonable and appropriate steps to ensure that we use the personal information in a manner consistent with your obligations, including audits at least once every twelve months — exercisable through section 5.9;
2. ⭐ will notify you if we determine that we can no longer meet our obligations under the CCPA;

1. grant you the right, on notice, to take reasonable and appropriate steps to stop and remediate unauthorised use of personal information; and
2. will enable you to comply with consumer requests made under the CCPA.

Subcontractors. Where we engage a sub-processor in providing the Services to you, we contract with it on terms that comply with the CCPA and its regulations, including the ten terms above. ⚠ California requires the full term set to flow down, which is stricter than European law's "same data protection obligations".

Requests sent to the wrong party. If a consumer sends a CCPA request directly to us about personal information we hold on your behalf, we will act on your instructions where you have given them, and otherwise inform the consumer that the request has been sent to the wrong party and tell them to direct it to you.

Breach. California's breach statute binds us with no threshold at all — anyone maintaining computerised data it does not own must notify the owner immediately following discovery. Section 7.1 is drafted to that standard for every customer. Where you must notify California residents, the notice has to carry the statutory headings — "What Happened?", "What Information Was Involved?", "What We Are Doing", "What You Can Do", "For More Information" — and we will give you the facts for each of them.

⚠ What we do not claim. We are not a "business" under Civ. Code §1798.140(d) — we meet none of the three thresholds — so we do not describe ourselves as CCPA-compliant in that capacity, and we post no "Do Not Sell or Share My Personal Information" link, because we neither sell nor share. ⚠ Whether each of our sub-processors publishes a §7051-compliant service-provider addendum has not been verified; it is an open item on the Sub-processor list, not a representation.

---

19. United States — State Privacy Law Addendum

This section applies where you are a controller under any United States state comprehensive consumer privacy law. It is drafted once, to the strictest formulation found in any of them, and applies to all. Where a state uses different words for the same idea — processor, service provider, vendor, customer rather than consumer — the state's own words are read in.

Every one of these laws requires you to impose these terms on us, so we offer them as a baseline rather than on request:

19.13 Transfers. ⭐ No United States state privacy law restricts international transfers. Nothing needs to be put in place for the United States leg, and section 15 names the destinations for your own notice.

19.14 Consumer requests and appeals. Where a consumer exercises a state-law right against you, section 5.6 governs our assistance. Where we receive the request directly we route it to you. We support a 45-day response with one 45-day extension, and an appeal answered within 60 days, which are the timescales these laws use.

⚠ 19.15 What this section does not do. It does not say that any of these laws applies to us. Most reach a person on their own numbers only above thresholds we are far below — but Texas and Nebraska have no volume threshold at all, and their only filter is a federal small-business test that, on the text of the federal regulation, requires a place of business in the United States. On that reading an Irish company cannot claim it. We therefore assume Texas and Nebraska apply to us and we claim no exemption from them. ⚠ We also make no statement about Georgia, which has no comprehensive privacy law despite what several bill trackers report.

---

20. South Africa — POPIA operator addendum

This section applies where you are a responsible party under the Protection of Personal Information Act. It is also the written contract POPIA requires and the binding agreement on which a transfer out of South Africa rests, because POPIA has no adequacy list for any country.

1. Section 19 security. We establish and maintain appropriate, reasonable technical and organisational measures to prevent loss of, damage to, or unauthorised destruction of personal information and unlawful access to or processing of it. We identify reasonably foreseeable internal and external risks, establish safeguards against them, regularly verify that the safeguards are effectively implemented, and continually update them in response to new risks, having due regard to generally accepted information security practices. Annex 2 describes the measures; Annex 5 discloses their limits.
2. Section 20(a). We process personal information only with your knowledge or authorisation.
3. Section 20(b). We treat personal information that comes to our knowledge as confidential and do not disclose it, unless required by law or in the course of the proper performance of our duties — section 5.3.
4. ⭐ Section 21(2). We notify you immediately where there are reasonable grounds to believe that personal information of a data subject has been accessed or acquired by an unauthorised person, and in no event later than the twenty-four hours in section 7.1. Section 7.1 is drafted to that standard; where its trigger and section 21(2)'s differ, section 21(2)'s applies to you, because section 0.4.1 gives the more protective rule precedence. Note that POPIA applies no risk qualifier: every confirmed unauthorised access is reportable by you to the Information Regulator and to the data subject, on the prescribed Form SCN1, with the content section 22(5) requires — including a recommendation of the measures the data subject should take and, if known, the identity of the unauthorised person. We will give you what you need for each of those.
5. ⭐ Section 72(1)(a) — onward transfers. Every sub-processor is bound by an agreement that itself restricts further transfer on terms substantially similar to this section, so the chain out of South Africa is protected at every link, not only the first. Section 15 names the destination countries.
6. ⭐ Juristic persons. POPIA protects an identifiable existing juristic person as well as a natural person, and section 72's adequacy benchmark expressly covers juristic persons. The protections in this Agreement therefore extend to personal information about juristic persons — companies, close corporations and trusts — in the same way as to information about individuals. We state this expressly because European standard contractual clauses protect natural persons only and would be under-inclusive on their face.

⚠ Two things we do not claim. POPIA contains no express sub-operator clause, no audit right, no deletion-on-termination duty and no documented-instructions language — the core of this Agreement gives you all four, but they come from us, not from POPIA. And we have not registered an Information Officer with the Information Regulator and have not authorised a person within South Africa as one; the Regulator's guidance says a multinational based outside South Africa should, and section 55(2) makes registration a condition of taking up the duties. We record it as open rather than claim compliance we do not have.

⚠ Special personal information and children's information. Section 57(1)(d) may require your prior authorisation from the Information Regulator before transferring special personal information or children's information to a foreign country that does not provide adequate protection, with processing suspended until the Regulator concludes. That is your obligation as responsible party. Section 4.4 already asks you not to put special-category data into the Services without telling us.

---

21. Singapore — data-intermediary addendum

This section applies where you are an organisation under the Personal Data Protection Act 2012.

1. ⭐ We process personal data only on your behalf and for your purposes, under this written contract. That statement is load-bearing: the data-intermediary provisions apply only to processing carried out on behalf of and for the purposes of another organisation, pursuant to a contract evidenced or made in writing. Without it we would not be a data intermediary at all. Section 2.3 states what we will not do with your data, and we do not use it for our own analytics, benchmarking or model training.

1. Protection (s.24). We make reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or disposal of personal data, and loss of any storage medium on which it is held — Annex 2, with its limits in Annex 5. This obligation binds us directly.
2. Retention limitation (s.25). We cease to retain personal data, or remove the means by which it can be associated with an individual, as soon as it is reasonable to assume that the purpose is no longer served by retention and retention is no longer necessary for legal or business purposes. This too binds us directly. ⚠ Where retention is governed by a setting you control, the position is yours: Annex 5 items L5 and L11 disclose which records have no default retention limit today, and section 17 governs a case where your own law imposes a floor.
3. Breach (s.26C(3)(a)). We notify you of a data breach without undue delay from the time we have we become aware of one, as section 7.1 defines that. Section 7.1 exceeds that. ⚠ We do not offer a shorter numeric guarantee here than the twenty-four hours in section 7.1, because Singapore prescribes no period and a number we could not meet would create a contractual breach where the law creates none.
4. ⭐ Transfer (reg 11(2)). This Agreement is the transfer contract, and it does both things the regulation requires: it requires us to provide a standard of protection at least comparable to the protection under the Act, and it specifies the countries and territories to which personal data may be transferred — section 15, which names them. ⚠ A clause permitting sub-processors "globally" would not satisfy limb (b), which is why section 15 is a closed list. ⚠ That list covers the transfers we make. A recipient you configure — a webhook endpoint, your own mail or SMS account, a payment provider you enable — is not a transfer by us and we cannot name its country; if you send Singapore personal data to one, specifying its destination under reg 11(2)(b) is your own obligation as the transferring organisation.
5. Withdrawal of consent. Where an individual withdraws consent, you must cease processing and cause your data intermediaries to cease. Tell us and we will act under section 5.6. ⚠ Annex 5 item L7 records what the product itself can do — switching a customer's contact preference off stops every message the Services send them on that channel — and item L4 records that a per-person erasure is a product action. Anything beyond those two we do by hand under section 5.6.

⚠ What we do not claim. ⭐ Singapore has no adequacy concept at all — no whitelist, no equivalence mechanism, and the EEA is not recognised. Ireland is treated exactly like any other destination, so European standard contractual clauses are beside the point here; the reg 11(2) contract is the mechanism. We hold no APEC or Global CBPR or PRP certification, which reg 12 would treat as a shortcut, and we claim none. And we express no view on whether the Act applies to us on its own terms; we comply on the assumption that it does.

⚠ Marketing text messages. Do Not Call obligations are not disapplied by data-intermediary status, and a platform that transmits a message can itself be a "sender". Section 4.6 and the Acceptable Use Policy govern what you may send through the Services.

---

22. Brazil — LGPD operador addendum

This section applies where you are a controlador under the Lei Geral de Proteção de Dados. In this Agreement you are the controlador and we are the operador.

1. Article 39 — instructions, and your right to verify. We process personal data according to the instructions you provide, and you have the right to verify our observance of your own instructions — exercisable through section 5.9. Brazilian law puts an affirmative duty on you to check, so we support checking rather than merely permitting it.
2. Article 37 — records. We maintain records of the processing operations we carry out on your behalf. ⚠ Brazil has no employee-count exemption from this duty, unlike the European rule, so it applies to us at any size.
3. Article 46 — security by design. We adopt security measures from the design phase of the product or service through to its execution, not only at run time. Annex 2 describes them and Annex 5 states their limits.
4. Article 48 — incidents. We inform you of a security incident without unjustified delay; section 7.1 exceeds that. ⚠ Your own clock is three business days to the ANPD and three business days to the data subject, running from your knowledge — so we notify immediately and give you the facts the ANPD requires, including whether technical measures had rendered the data unintelligible, which affects how the incident is assessed.
5. ⭐ Article 33, item I — transfers. ANPD Board Resolution No. 32 of 26 January 2026 recognises the European Union as providing an adequate level of personal data protection. A transfer from Brazil to our infrastructure in Ireland therefore rests on adequacy and needs no Brazilian standard contractual clauses, no binding corporate rules and no specific consent. This Agreement deliberately does not attach the Annex II clauses that were required before that date.
6. Article 42 — liability, and the line we must not cross. An operador that fails to comply with data-protection law, or fails to follow your lawful instructions, is jointly and severally liable and is treated as a controlador. Section 9.6 records the same rule, and section 5.1 defines your instructions precisely so that neither of us has to argue about them later.
7. Article 18(VII) — telling a person who has their data. Brazilian law gives a data subject the right to be told the actual entities with which their data has been shared, not merely categories. For the processing we carry out on your behalf, our sub-processor list is short, published and per-purpose, and we will confirm in writing which of those entities could have received a given individual's data. ⚠ The Services do not maintain a per-record sharing log, so neither we nor you can produce a per-individual history from the product; and where you have configured a webhook or integration, that recipient is yours to record, not ours (section 6.5).

---

23. Japan — APPI addendum

This section applies where you are a personal information handling business operator under the Act on the Protection of Personal Information, and we are your entrustee (委託� �).

1. ⭐ Recital — the condition on which the transfer route depends. We are established in Ireland and we are subject to the EU General Data Protection Regulation. The Personal Information Protection Commission's designation notice carves the thirty EEA states and the United Kingdom out of "foreign country" for Article 28 purposes, so a provision of personal data from Japan to us does not require Article 28 consent — but the notice attaches a binding condition: the carve-out applies only where the recipient is subject to the GDPR. This recital is what engages it, and it is the reason this Agreement records it expressly rather than leaving it to be inferred from our address.
2. Article 25 — your supervision, and our support for it. Japanese law places the duty on you: you must exercise necessary and appropriate supervision over us so that the security of the entrusted data is ensured. The Guidelines make one limb mandatory — before entrusting, you must confirm in advance that the security measures in the Commission's annex will be reliably implemented. We support that confirmation with Annex 2, Annex 5 and section 5.9, and we will answer a written confirmation request rather than asking you to take our word for it. The Guidelines treat a contract recording the agreed measures, and periodic review of how we handle the data, as expected practice, and sections 5.9 and 11 provide both.
3. ⭐ Sub-contracting (再委託). We give you prior notice of any new sub-processor and an opportunity to object (section 6.2), together with its work scope and the categories of data it handles, so that you can discharge the Guidelines' expectation of prior report or approval. ⚠ This matters more in Japan than elsewhere: where an entruster has not supervised properly and a sub-processor mishandles data, that can be judged a violation of the Act by the original entruster — by you, not by us.
4. Publication. Where you must publish the country in which data is handled, it is Ireland, plus the other countries in section 15.

⚠ What this section does not do. ⚠ Japan's breach-notification regime was not examined in the research behind this Agreement, so nothing here states a Japanese breach position, and we cite no Japanese provision: section 7 of this Agreement applies to our notification to you, and you should take your own advice on what the Act requires of you when we do. ⚠ Japan's 2026 amending Act is enacted but its principal provisions are not yet in force, and it revises the duties of entrustees; this section will be re-checked before those provisions commence.

---

24. Switzerland — FADP addendum

This section applies where you are a controller subject to the Swiss Federal Act on Data Protection.

1. ⭐ Article 9(3) — prior approval for sub-processing. Swiss law says, without qualification, that a processor may only assign processing to a third party with the prior approval of the controller. It provides no general-authorisation alternative, and a breach is a criminal offence attaching to a natural person. So, for a Swiss controller: your acceptance of this Agreement constitutes your prior approval of each sub-processor named in Annex 3 and on the published list at the date you accept it, and each thirty-day notice under section 6.2 seeks your prior approval of the addition it announces. If you do not object within the notice period we treat approval as given for that addition; if you object, section 6.2 applies and we will not appoint that sub-processor for your data. ⚠ We flag this as a construction of Article 9(3), not something its text spells out: the market practice of a published list plus notice is a comfortable fit for European law and a less certain one for Swiss law. If you need specific written approval per sub-processor instead, tell us and we will operate that way for your account.
2. ⭐ Article 24(3) — breach notification, unqualified. We notify you of any breach of data security as quickly as possible. Swiss law applies no threshold to the processor's duty — the high-risk filter belongs to you, not to us — which is exactly the rule section 7.1 already applies to every customer. ⚠ Note that your own threshold is higher than the European one: you notify the FDPIC only where a breach is likely to lead to a high risk to a data subject's personality or fundamental rights, and you inform the data subject only where that is needed for their protection. Many breaches notifiable to a European authority are not notifiable to the FDPIC.
3. ⭐ Article 16(1) — transfers, and what is NOT needed. Ireland is named on Annex 1 to the Swiss Data Protection Ordinance, so Switzerland recognises it as providing adequate protection. A transfer from Switzerland to our Irish infrastructure needs no standard contractual clauses, no binding corporate rules, no notification to the FDPIC and no derogation, and this Agreement deliberately attaches none for that leg. ⚠ The real Swiss exposure is onward transfer from Ireland to a country not on Annex 1, which is why section 15 names every destination and section 6.3 flows the obligations down. ⚠ Note also that the United States entry on Annex 1 is conditional on the recipient holding a current Swiss-US Data Privacy Framework certification; we do not rely on any provider's certification, for the reasons in section 8.3. For that leg we therefore rely on the EU Standard Contractual Clauses incorporated in each sub-processor's own agreement with us (section 8.3), applied to Swiss-originating data with the adaptations the FDPIC recognises — references to the GDPR read as references to the FADP, references to the supervisory authority read as references to the FDPIC, and the protections extended to data about juristic persons. ⚠⚠ Two things about that reliance are not yet established, and we will not pretend otherwise. The precise adaptations the FDPIC requires were not verified from its recognition decision in the research behind this Agreement; and we have not confirmed that the Clauses in our sub-processors' own agreements carry a Swiss addendum at all — the agreements we read record EU and UK instruments only. Until both are closed, no Swiss-specific transfer instrument is in place for the Ireland-to-United States leg, and we record that as an open gap rather than leaving it implicit. We will confirm the position, or put a Swiss-specific instrument in place, before a Swiss customer relies on this section — tell us before you sign if you need it closed first, and we will close it or tell you we cannot.
4. Article 9(1)–(2). We process the data only in the manner in which you are yourself permitted to process it, we are bound by the confidentiality duties in section 5.3, and Annex 2 is provided so that you can satisfy yourself that we are able to guarantee data security.
5. No Swiss representative is required of us. The Article 14 duty applies to controllers established abroad, on five cumulative conditions, and does not extend to processors.

---

25. Australia — Privacy Act rider

This section applies where you are an APP entity under the Privacy Act 1988.

1. ⭐ Retained control — section 16. Section 16 of this Agreement is drafted so that you retain effective control of the personal information you place in the Services: our functions are limited by this contract, every subcontractor is bound to the same obligations, and you keep the power to access, modify, retrieve and delete. Where you retain effective control the handling is a use, not a disclosure, so APP 8 does not apply and the strict onward liability in s.16C does not engage. ⚠ This is the route we recommend, because the alternative is worse: no country has ever been prescribed as having substantially similar laws, and the regulator publishes no list, so an APP 8.2(a) assessment would be one you make yourself with no regulatory backing.
2. APP compliance covenant. In handling personal information on your behalf we will not do an act, or engage in a practice, that would breach an Australian Privacy Principle if done by you.
3. APP 11 security floor. We take the steps described in Annex 2 to protect the information from misuse, interference and loss, and from unauthorised access, modification or disclosure. Annex 5 states the limits.
4. APP 12 and APP 13 assistance. We assist you with access and correction requests under section 5.6. ⚠ APP 13.4 — where you decline to correct information and the individual asks you to associate a statement with it — has no counterpart field in the Services (Annex 5, item L17). Where the record is one we hold as controller we will attach the statement by hand; inside your account there is nowhere for it to live, and you should handle it outside the Services until that changes.
5. Notifiable Data Breaches scheme. We give you what you need for an assessment under the scheme, on the basis that your assessment must be reasonable and expeditious and completed within thirty calendar days of your suspicion. Section 7.1 notifies you immediately so that the thirty days is available to you rather than consumed by us. Section 7.2 supplies the content a statement to the Commissioner requires: a description of the breach, the kinds of personal information concerned, and the steps we recommend individuals take.
6. The countries. Where you must name them, section 15 does.

⚠ Our own status. We believe the small business operator exemption in s.6D applies to us at present, so the Australian Privacy Principles do not bind us as an entity; we apply their standards regardless and will comply in full once our turnover exceeds the threshold. ⚠ This is a reasoned position and not a certainty — there is no regulator guidance on how the exemption applies to a cloud provider, and the statutory tort for serious invasions of privacy reaches entities that are not APP entities at all.

---

26. Quebec — Law 25 rider

This section applies where you carry on an enterprise in Quebec.

1. ⭐ The assessment comes first, and this Agreement is tethered to it. Before entrusting personal information to a person outside Quebec, you must conduct a privacy impact assessment (an évaluation des facteurs relatifs à la vie privée) covering the sensitivity of the information, the purpose of its use, the protective measures including contractual ones, and the legal regime applicable in the destination State — and you may proceed only if it shows the information will receive adequate protection. You must also conduct one for the acquisition or overhaul of an information system involving personal information, which is what adopting the Services is. This Agreement is entered into having regard to the findings of that assessment, and where it identifies a specific risk, the measures agreed to mitigate that risk are recorded as an appendix to this Agreement and form part of it. Tell us what your assessment found and we will agree the mitigation terms; a boilerplate agreement does not satisfy Quebec on its face, and we would rather say so than pretend otherwise.
2. Our standing support pack. So that you can complete the assessment rather than stall at procurement, we maintain and will provide on request: a data map of what the Services hold; the sub-processor list with destination countries; the technical and organisational measures in Annex 2 with the limitations in Annex 5; and a summary of the Irish and European legal regime that applies to us. The regulator's own guidance points at the European regime as a benchmark of generally recognised protection principles, which is the regime we are subject to.
3. Automated decisions. Where a decision about an individual is based exclusively on automated processing, Quebec requires you to inform them no later than when the decision is communicated, and to let them correct the data used, present observations to a member of staff able to review the decision, and have the decision reviewed by a person. ⚠ Quebec attaches no "legal or similarly significant effects" threshold to that duty. Section 4.7 identifies the one optional feature in the Services that applies a change without a human confirmation, and Annex 1 describes it.
4. Incidents. Section 7.1 applies. ⚠ Note two Quebec-specific points for your own records: your standard is to act promptly, with no fixed hour count, and you must keep a register of all confidentiality incidents — including those presenting no risk of serious injury — for a minimum of five years. We keep our own breach records to that standard so that ours can support yours.
5. ⚠ Product defaults. Quebec requires a technological product offered to the public to provide, by default, the settings giving the highest level of confidentiality — a product-configuration mandate stricter than European privacy-by-design. We have not assessed the Services' defaults against that standard and we do not claim to meet it (Annex 5, item L18). Several relevant settings are yours to configure, including whether staff location is recorded and how long messages are kept.

---

27. India — DPDP Act rider

⚠ Read the commencement position first. India's Digital Personal Data Protection Act 2023 is enacted, but its operative provisions — including the processor-contract requirement, the security duty, the breach duty, the rights, the transfer provision and the penalty power — are not yet in force. They commence around May 2027. Until then the operative Indian law for sensitive personal data remains section 43A of the Information Technology Act 2000 and the SPDI Rules 2011, ⚠ which were not examined in the research behind this Agreement. Nothing in this section states a position under them.

This section applies where you are a Data Fiduciary under the DPDP Act. It takes effect as those provisions commence, and we will contract now on the terms they will require.

1. Section 8(2) — a valid contract. This Agreement is that contract.
2. Rule 6(1)(f) — security in the contract. Sections 5.4 and Annex 2 are the appropriate contractual provision for taking reasonable security safeguards. ⚠ Neither the Act nor the Rules prescribes any minimum contract content beyond validity and a security clause, so the core of this Agreement does considerably more than Indian law asks.
3. Breach — rule 7. We notify you under section 7.1. ⚠ Your own duty has no threshold of any kind: every personal data breach must be intimated to the Data Protection Board and to every affected Data Principal, "without delay", with a detailed report to the Board within seventy-two hours. Because your first intimation is itself "without delay", any notification we measured in days would break your clock — which is why section 7.1 notifies you immediately rather than at the twenty-four-hour limit. ⚠ We do not promise a shorter number, because section 7.4 describes honestly what our detection consists of.
4. ⭐ Rule 8(3) — the one-year retention floor. Indian rules will require you to cause us to retain personal data, traffic data and processing logs for at least one year before erasure. Section 17 gives effect to that as your instruction. ⚠ It conflicts with European storage limitation and with Singapore's retention-limitation duty, so it is applied per customer and not platform-wide.
5. Section 8(7)(b) — erasure. Where you must cause erasure, section 5.6 and section 5.8 apply, subject to the floor above.
6. Section 11(1)(b) — naming who has the data. Where a Data Principal asks you for the identities of the fiduciaries and processors with which their data has been shared, we will confirm which entities on our sub-processor list could have received it. ⚠ The Services keep no per-record sharing log.
7. ⭐ Transfers — and what is deliberately absent. India uses a negative-list model: transfers are permitted unless the Central Government notifies a restricted country, and that power is not yet in force, so no country can have been notified. No adequacy decision, no standard contractual clauses, no binding corporate rules, no certification, no consent and no transfer impact assessment are required for the India leg. ⚠ This Agreement therefore contains no European-style transfer machinery for India, because importing it would overstate Indian law. The only condition the rules attach concerns making personal data available to a foreign State or an entity under its control, which section 8.6 and our published Government and law-enforcement requests policy address.
8. ⚠ Children. The Act will require verifiable parental consent before processing any personal data of anyone under eighteen, will prohibit tracking, behavioural monitoring and targeted advertising directed at children, and carries no de minimis. The Services provide no age gate, no parental-consent capture and no way to segregate a child's record (Annex 5, item L15). We do not claim compliance with that section. The honest position, which section 4.4 and the Portal Privacy Notice both state, is that the Services are not intended for children, that you are instructed not to enter a child's personal data, and that we will delete such data on request.

⚠ What we are, and are not. The DPDP Act imposes no obligation and no penalty on a Data Processor — every duty in it falls on the Data Fiduciary, "irrespective of any agreement to the contrary". We therefore do not describe ourselves as compliant with it in our processor capacity, because there is nothing for a processor to comply with. What this section does is give you the contract you will need.

---

Annex 1 — Description of the processing

A1.1 Subject matter

The provision of the Field 2 Service field-service-management platform to you, and the support of that platform, including hosting and processing the records you and your users create in it.

A1.2 Duration

From the date this Agreement takes effect until the Services end, plus the return-or-deletion period in section 5.8 (up to ninety days after the Services end where you give no instruction), plus any period for which we are legally required to retain specific records.

A1.3 Nature and purpose of the processing

The purpose is to provide the Services to you. The nature of the processing consists of collection, recording, organisation, structuring, storage, retrieval, consultation, use, alteration, transmission, making available, restriction and erasure of Customer Personal Data, carried out by automated means, specifically —

• hosting and storing your records in a database dedicated to your account;
• scheduling, dispatching and route-planning field work, including travel-time and distance calculations;
• producing and transmitting quotes, invoices, receipts, reminders and completion sheets;
• initiating card and online payments through a payment provider you enable;
• sending email and SMS to the recipients your workflow determines;
• operating a customer portal and a public booking page for the individuals you serve;
• generating AI-assisted retrieval, drafting and scheduling suggestions and — only where you enable it — applying a capped set of scheduling actions automatically (section 4.7);
• generating reports, statistics and alerts from your own data;
• delivering webhooks and API responses to endpoints you configure;
• maintaining an audit log and support access for the operation of the Services.

A1.4 Types of personal data

Special categories of personal data (Article 9) and criminal-offence data (Article 10) are outside the intended scope of the Services and must not be entered without our prior written agreement (section 4.4).

A1.5 Categories of data subject

• Your customers, and the individual contacts at your customer organisations
• The individuals who use your customer portal, and who submit public booking requests
• Your leads, prospects and enquirers
• Your employees, engineers, subcontractors and other users of your account
• Your suppliers' and partners' contacts, where you record them
• Anyone else whose details your users enter into free-text fields

A1.6 Frequency of the transfer

Continuous, for the duration of the Services.

A1.7 Sensitivity and special restrictions

The data is ordinary business and service-delivery data. It is not intended to include special categories or criminal-offence data (section 4.4). It does include home addresses and access information for private residences, which should be treated as sensitive in practice even though it is not special-category data.

A1.8 Retention

For the duration of the Services, plus section 5.8, subject to: the retention windows you configure for message threads (which default to "keep indefinitely" — Annex 5, item L5); the sixty-minute deletion of AI image uploads; and the thirty-day default purge of dismissed alerts. Operational logs currently have no automatic limit — see Annex 5, item L11.

---

Annex 2 — Technical and organisational measures

Every measure below is implemented in the product today. Measures a reader might expect to find here and that are not implemented are disclosed in Annex 5 rather than omitted.

A2.1 Pseudonymisation and encryption

• All access to the Services is over HTTPS. HTTP Strict Transport Security is enforced as a response header.
• Passwords for staff users, customer-portal users and platform administrators are hashed with PHP's password_hash using the platform default algorithm (bcrypt) and verified with password_verify. Hashes are stripped from the session and excluded from the API and AI surfaces.
• Stored third-party secrets — SMTP passwords, payment API keys, OAuth tokens — are encrypted at rest with AES-256-CTR under an SHA-512 HMAC, and are decrypted only at the moment of the outbound call. They are never written to logs.
• Two-factor authentication seeds (TOTP, RFC 6238) are encrypted at rest with the same encrypter, and recovery codes are stored hashed.
• Public payment and quote links are unguessable HMAC-SHA256 signed tokens; where no application key is configured, no valid token exists and the route returns 404. Since 6 September 2026 a valid token is not enough on its own: the link must also have a live registration that has neither expired nor been revoked, and only the hash of the token is stored, so the register cannot be read back into working links. Expiry is ninety days from issue by default and is yours to set; revocation is per link, or all of one customer's links at once. See Annex 5, item L9, for the two limits.

A2.2 Confidentiality and access control

• Tenant isolation by a separate database per customer. A single class is the only code path that re-points the database connection; in multi-tenant mode the default connection is deliberately pointed at a schema that does not exist, so any query issued before a tenant has been resolved fails loudly rather than reading another customer's data. Every application query is additionally scoped to the company.
• Role-based access control over every module and action, with a defined permission matrix.
• Optional two-factor authentication for user accounts, with recovery codes.
• Session cookies are HttpOnly, SameSite=Lax and Secure in production; sessions expire after two hours.
• CSRF protection on state-changing requests, using a randomised token with a two-hour lifetime. The three documented public endpoints that cannot carry a session token — public signup, public booking and public support intake — are protected instead by origin and referer checks, a honeypot field and a per-IP throttle.
• Rate limiting against brute force and credential stuffing: staff login five attempts per IP address and five per email address per ten minutes; password reset twenty per hour per IP address and five per hour per email address; customer-portal login five per IP address per ten minutes; portal AI twenty messages per hour per customer and one hundred and fifty per hour per company.
• Account-enumeration resistance: login, password reset, portal reset and signup all return generic responses that do not reveal whether an account exists.
• Uploaded files are stored outside the web root, under a per-company directory.
• Anti-framing is enforced (frame-ancestors 'self').
• The AI assistant is hard-scoped to the calling company, and a field engineer's AI access is further scoped to their own jobs. AI write actions are staged as proposals and applied only on explicit confirmation, each recorded with an undo record; server-side caps of ten proposals and five destructive actions per turn apply regardless of what the user or the model asks for. The customer-portal AI is read-only and scoped to the single signed-in customer.
• AI error logs record only a timestamp, company identifier, user identifier, location and message — never the conversation.

A2.3 Integrity and availability

• Every state change is written to an activity log with the acting user, the entity, a description and the IP address. Administrative actions on the platform are written to a separate audit log.
• Money-affecting operations use database locks around check-then-write sequences, and document totals are re-derived from the source rows rather than written by hand.
• Since 6 September 2026, security-relevant events — failed sign-ins, lockouts, password changes, two-factor removals, API-key creation and revocation, data exports, bulk permanent deletions and content-security-policy violations — are written to a durable, insert-only record, and four alert rules fire on it. It records an IP address, a user-agent string and the acting user, and never an email address, a password, a code, a token or the contents of a form. See Annex 5, item L8, and section 7.4 for what this is not.
• Availability, restoration and disaster recovery are provided by our hosting arrangement — [[OWNER: hosting provider and data-centre location]]. Since 6 September 2026 we additionally operate our own encrypted database backup mechanism, with the encryption key held apart from the application's own key and with each run recording the size and checksum of what it wrote; it can decrypt and re-read its own artefacts and can restore one into a scratch database and compare the number of tables it contains with the live database. No copy is held off-site today, no key custody arrangement is in place, no recovery time or recovery point is stated, and no rehearsal has been carried out on the production host. See Annex 5, item L14, for what we do not claim.

A2.4 Testing and review

• Changes are reviewed before release, and a pre-release verification harness runs read-only checks across every tenant database.
• This Annex and Annex 5 are reviewed at least annually, and whenever a sub-processor, a security control or a material product capability changes.

A2.5 Data minimisation and storage limitation in the product

• AI image uploads are deleted after sixty minutes.
• Dismissed alerts are purged after a configurable window, thirty days by default.
• Message threads are purged on the retention window you set (see Annex 5, item L5, for the default).
• Password reset links expire after one hour; staff invitation links expire after a configurable window, seven days by default.
• The customer portal, the public booking page and our marketing website load no third-party resources and set no third-party cookies. The application sets only two cookies, both first-party and strictly necessary: the session cookie and the CSRF token. There is no analytics, advertising or "remember me" cookie anywhere in the product. The staff application does load three third-party browser resources — Google Fonts, Google Maps JavaScript and Places, and the Google Maps embed iframe — listed in the published sub-processor list (Annex 5, item L13).
• A retention sweep runs daily against the retention register and deletes what the register declares. It is deliberately inert where no period has been declared: a store with no period set is not swept at all, and no period is invented for it. See Annex 5, item L11, for the stores that have no period today.

A2.6 Measures for transfers to sub-processors

See section 6 and Annex 3. Each sub-processor is engaged under a written agreement with data protection terms no less protective than this Agreement, and each transfer outside the EEA or the UK relies on the mechanism recorded in the published sub-processor list.

---

Annex 3 — Approved sub-processors

The authoritative, dated list is published at https://www.field2service.com/sub-processors.html and is incorporated into this Agreement by reference. The version current at the date of this Agreement is version 1.0, published on the date shown at the head of this Agreement, and it contains the entries summarised below. Changes are notified under section 6.2.

Destination countries: Ireland; the United States; and [[OWNER: hosting provider and data-centre location]] — the closed list in section 15, which the published list repeats provider by provider. The AI providers and Twilio are in the United States (OpenAI also contracts in Ireland for EEA and Swiss customers); Stripe is in Ireland and the United States. It does not cover transfers you direct — a webhook or API endpoint you configure, your own mail or SMS provider, or a payment provider you enable, whose entity and country are determined by it and by you. Those are onward transfers made on your instruction under sections 4.6 and 8.5, they are recorded in section 3 of the published Sub-processor list, and naming their destinations is yours to do where your own law requires it. If this summary, section 15 and the published list ever disagree, the most restrictive governs.

Our own outbound mail relay carries only account-holder data, for which we are the controller, and is therefore not a sub-processor under this Agreement. It is listed in section 2 of the published Sub-processor list.

The published list also records third parties that are not our sub-processors but that receive data in connection with the Services. PayPal and Google Maps Platform receive data in connection with the Services but act as independent controllers under their own terms, not as our sub-processors; the published list records why — PayPal's Privacy Statement identifies the PayPal entity in the payer's own jurisdiction as the controller of that payer's personal information, and Google Maps Platform is supplied under Google's Controller-Controller Data Protection Terms, clause 4.1 of which states that each party is an independent controller. The same section of the published list records the recipients you choose — your own SMTP email provider, your own SMS account and any webhook endpoint you configure (section 6.5) — together with the browser-side resources the staff application loads. Read it in full before relying on this summary.

---

Annex 4 — UK Addendum

This Annex applies where, and to the extent that, your processing is subject to the UK GDPR. It modifies the rest of this Agreement for that processing; everything not modified applies unchanged.

A4.1 Reading the Agreement for UK processing

• References to the GDPR are read as references to the UK GDPR, and references to the Data Protection Act 2018 are read as references to that Act as it applies in the United Kingdom, as amended by the Data (Use and Access) Act 2025.
• References to a supervisory authority are read as references to the Information Commissioner's Office (ICO) — helpline 0303 123 1113 · https://ico.org.uk/.
• Our ICO registration, where applicable, is [[OWNER: ICO registration number, if registered]].

A4.2 Transfers of UK personal data

• UK to Ireland/EEA. Covered by the UK's adequacy regulations for the EEA. No further safeguard is required for you to send data to us. ⚠ That instrument was not verified against its primary source in the work behind this Agreement — section 8.2 states the position and what we will do if it does not hold.
• Onward transfers to sub-processors outside the UK. Where a sub-processor is outside the UK and is not covered by UK adequacy regulations, we rely on the UK Addendum to the EU Standard Contractual Clauses (or, where the sub-processor uses it instead, the ICO's International Data Transfer Agreement), as incorporated in that sub-processor's data processing agreement with us. Where the recipient participates in the UK Extension to the EU-US Data Privacy Framework, that may also apply; we do not rely on it alone.
• For the purposes of the UK Addendum, the Exporter is Field 2 Service and the Importer is the sub-processor; the Appendix Information is the description in Annex 1 and the measures in Annex 2; and neither party may end the Addendum under its Section 19 other than as that Section permits.

A4.3 Complaints

If you or a data subject wishes to complain to us about how personal data has been handled, write to hello@field2service.com with "Data protection complaint" in the subject line. We will acknowledge the complaint within 30 days, investigate it, and tell you the outcome without undue delay, keeping you informed of progress in the meantime. Where the complaint concerns data held in a customer's account, we will notify that customer, because they are the controller and the complaint is properly theirs to answer.

Complaining to us does not affect the right to complain to the ICO, or to the DPC where the EU GDPR applies, or to seek a judicial remedy.

A4.4 UK representative

Whether we are required to appoint a UK representative under Article 27 of the UK GDPR depends on whether we offer services to individuals in the United Kingdom within the meaning of Article 3(2). We offer the Services to businesses. Where a representative is appointed, the appointment and contact details will be published in our Privacy Policy and in the published sub-processor list.

A4.5 UK-only lawful bases

We do not rely, in this Agreement or in the Services, on any lawful basis that exists only under the UK GDPR (including the "recognised legitimate interests" basis introduced by the Data (Use and Access) Act 2025). This Agreement is written to the EU GDPR standard throughout, which is the stricter of the two.

---

Annex 5 — Statement of current capabilities and limitations

This Annex is published so that you can make the assessment Articles 24 and 28(1) require of you. It is accurate as at the date shown at the head of this Agreement and is updated when the product changes. Each item is a limitation we have chosen to disclose rather than paper over. "Under consideration" means we have recorded the item; it is not a commitment to change it, and no date is promised. "Resolved" means the limitation no longer applies as at the date shown at the head of this Agreement; we keep the row, with the date the position changed and any residual, so that the numbering stays stable and you can see what moved.

---

Document control