Schedule 1 — Data Processing Terms
Pocket Docket Ltd · company number NI742827 · registered in Northern Ireland · registered office 137 York Road, Belfast, BT15 3GZ
Before the legal part: what this document is, in plain English
You connect your Xero organisation to Pocket Docket. Your Xero organisation contains personal data — the names, email addresses, phone numbers, addresses and payment histories of your customers, your suppliers and sometimes your staff. That data is yours. You decided to collect it and you decide what it is for.
We only see it because you clicked "Allow access" in Xero. That makes us your processor: we handle that data on your instructions and for no purpose of our own.
There is a second, much smaller set of data — your name, your email address, your card details, your support tickets, our security logs. That is data we decide the purposes for, so for that data we are a controller. Our privacy notice covers it.
This Schedule is the contract that UK data protection law requires between a controller and a processor. Article 28(3) UK GDPR says it must be "a contract or other legal act… in writing, including in electronic form". It does not have to be a separate document and it does not have to be signed. So this Schedule forms part of our terms of service and you accept it when you sign up, in the same way Xero and FreeAgent handle it.
If you want a signed copy for your own records, ask and we will provide one. It will say the same thing.
1. Interpretation
1.1 In this Schedule:
"Account Data" means personal data relating to your subscription that we determine the purposes and means of processing for: subscriber and user identity, contact details, billing and payment records, subscription and usage records, support correspondence, and security and abuse-prevention telemetry.
"Customer Data" means all personal data within the Xero organisation you connect to the Service, within any bank connection you authorise, and within any content you or your users submit through the Service, which we process on your behalf. Annex 1 particularises it.
"Data Protection Law" means the UK GDPR, the Data Protection Act 2018, and the Privacy and Electronic Communications (EC Directive) Regulations 2003, in each case as amended (including by the Data (Use and Access) Act 2025), together with any binding guidance or code of practice issued by the Information Commissioner.
"Kipp" means the assistant feature of the Service, built on Anthropic's Claude API.
"Restricted Transfer" means a transfer of Customer Data to a country outside the United Kingdom that would be prohibited without a mechanism under Chapter V UK GDPR.
"Service" means the Pocket Docket subscription service described in the Terms of Service.
"Sub-processor" means a third party engaged by us to process Customer Data.
"Terms" means our Terms of Service, of which this Schedule forms part.
"UK GDPR" has the meaning given in section 3(10) of the Data Protection Act 2018.
"controller", "processor", "data subject", "personal data", "personal data breach", "processing" and "supervisory authority" have the meanings given in the UK GDPR.
1.2 References to an Article are to an Article of the UK GDPR. References to a statutory provision include any provision that replaces it.
1.3 If anything in this Schedule conflicts with anything else in the Terms, this Schedule wins in respect of the processing of Customer Data. Clause 11 (liability) is the single exception and is drafted to say so expressly.
2. Which of us is which
2.1 Customer Data — you are the controller, we are the processor. You decide why the personal data in your accounting records exists and what happens to it. We receive it only because you authorised a Xero OAuth connection, and we process it only to run the Service for you.
2.2 Account Data — we are the controller. We decide the purposes and means of processing Account Data. That processing is not governed by this Schedule; it is described in our privacy notice.
2.3 We are also a controller for two narrow things. We act as controller, not processor:
(a) for platform security, fraud prevention and abuse prevention — detecting and refusing unauthorised access to dashboards, rate limiting, investigating suspected misuse, and keeping the security logs that make that possible; and
(b) for aggregated statistical data derived from use of the Service that has been irreversibly anonymised — and only where we can actually evidence that the anonymisation is irreversible.
2.4 On (b), the honest position. Anonymisation is easy to claim and hard to prove. Our commitment is that we will not treat any dataset as anonymised, or use it under clause 2.3(b), unless we hold a written assessment showing that re-identification is not reasonably likely by us or by anyone else, taking account of what we and others hold. Until such an assessment exists for a given dataset, that dataset is Customer Data and this Schedule governs it in full. See also clause 4, which puts hard limits on what we would do with such data anyway.
2.5 Each of us is separately responsible for its own compliance with Data Protection Law. Nothing here makes either of us answerable for the other's independent failures.
2.6 Duration. This Schedule applies for as long as we process Customer Data, and survives termination of the Terms until deletion is complete under clause 9.
3. What we will do, as your processor
We will do each of the following. Where a clause implements a specific requirement of Article 28(3), it says so, so that your accountant or solicitor can check it off.
3.1 Process only on your documented instructions. (Art 28(3)(a)) We will process Customer Data only on your documented instructions, including in relation to Restricted Transfers, unless we are required to do otherwise by law that applies to us. If that happens, we will tell you before we process, unless that law prohibits us from telling you on important grounds of public interest.
3.2 What counts as your instructions. Your documented instructions are: the Terms, this Schedule, the configuration choices you make inside the Service (including which Xero organisation you connect, which scopes you grant, which bank connection you authorise if any, who you nominate to receive dashboard links, and what you ask Kipp), and any further written instruction you give us that we accept. Using a feature is an instruction to process the data that feature needs.
3.3 Tell you immediately if an instruction looks unlawful. (Art 28(3), final paragraph) If in our opinion an instruction from you infringes Data Protection Law, we will tell you immediately. We may pause performance of that instruction while we discuss it with you. We are not obliged to give you legal advice, and telling you does not make us responsible for the lawfulness of your instructions.
3.4 Keep our people under a duty of confidence. (Art 28(3)(b)) We will make sure that every person we authorise to process Customer Data is bound by a written duty of confidence that survives the end of their engagement, is trained on their obligations, and has access only where they need it for their role. Where any of them is under a statutory duty of confidence instead, that is sufficient.
3.5 Keep the data secure. (Art 28(3)(c), Art 32) We will implement and maintain the technical and organisational measures set out in Annex 1 Part F, having regard to the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the risk to individuals. We may change a measure, but not in a way that materially reduces the overall level of security.
3.6 Only use sub-processors on the conditions in clause 6. (Art 28(3)(d), Art 28(2), Art 28(4))
3.7 Help you answer your customers, suppliers and staff. (Art 28(3)(e)) Taking into account the nature of the processing, we will assist you by appropriate technical and organisational measures, so far as possible, in meeting your obligation to respond to requests to exercise rights under Chapter III UK GDPR — access, rectification, erasure, restriction, portability, objection, and rights relating to automated decision-making. In practice:
(a) the Service lets you export the data we hold for you at any time, which answers most access and portability requests without our involvement;
(b) if a data subject contacts us directly about Customer Data, we will not respond substantively. We will tell them to contact you, and tell you within five working days that they contacted us, unless the law prevents us; and
(c) if you need something the Service cannot do by itself, ask us and we will do it. There is no charge for reasonable assistance. If a request requires substantial engineering work beyond configuring the Service, we will tell you before we start and agree a cost with you first.
3.8 Help you with security, breaches, DPIAs and prior consultation. (Art 28(3)(f), Arts 32–36) Taking into account the nature of the processing and the information available to us, we will assist you in complying with your obligations under Articles 32 to 36 — keeping data secure, notifying the ICO and data subjects of a breach, carrying out data protection impact assessments, and consulting the ICO in advance where required. Our security statement, sub-processor list and the information in Annex 1 are provided so that you can complete a DPIA without a bespoke request. If you need more, ask.
3.9 Delete or return the data at the end. (Art 28(3)(g)) At the end of the Service, we will delete or return Customer Data as you choose, and delete existing copies, unless the law requires us to keep it. Clause 9 sets out the mechanics and the timescales.
3.10 Show our work, and let you audit us. (Art 28(3)(h)) 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 by an auditor you mandate. Clause 10 sets out how.
3.11 Keep records. (Art 30(2)) We will maintain a written record of the categories of processing we carry out on your behalf, and make it available to the ICO on request.
4. Four things we will not do
These are commitments, not descriptions of current practice that we might quietly change. They bind us for as long as we process Customer Data.
4.1 We will not pool your data with anyone else's. We will not combine, aggregate or compare Customer Data across subscribers for benchmarks, industry averages, product analytics, research, or any other purpose. Your ledger is analysed against your ledger and nothing else.
4.2 We will not use your data to train AI. We will not use Customer Data to train, fine-tune, adapt or enhance any artificial intelligence or machine learning model, and we will not permit any Sub-processor to do so. Anthropic does not train models on data submitted through its API, and our contract with Anthropic reflects that. If any provider changed that position, we would move provider or stop using the feature; we would not ask you to accept it.
4.3 We will not cache across tenants. Every cache, index, snapshot and derived record in the Service is scoped to a single connected organisation. There is no shared cache, no shared index and no cross-tenant lookup.
4.4 We will not sell it, and we will not advertise off it. We do not sell Customer Data, we do not share it for advertising or marketing purposes, and we set no advertising or tracking technologies in the Service.
Why the wording of 4.2 is what it is. "Train" on its own is too narrow. Xero's developer terms use "train, adapt, or enhance", and the tail words do the real work: they catch retrieval indexes, evaluation sets and prompt libraries built out of customer content, not only gradient updates. We have used the same words on purpose.
5. What you are responsible for
5.1 You confirm that:
(a) you have a lawful basis under Article 6 (and, where relevant, a condition under Article 9) for the processing you instruct;
(b) you have given the privacy information required by Articles 13 and 14 to the people whose data is in your accounting records — including your customers, suppliers and staff — covering the fact that a software provider processes it, that an AI assistant processes figures derived from it, and that the Sub-processors in Annex 2 are involved;
(c) you are entitled to connect the Xero organisation and any bank account you connect, and to instruct us to process the data we retrieve from them;
(d) your instructions comply with Data Protection Law; and
(e) you will not deliberately put special category data (Article 9) or criminal offence data (Article 10) into the Service. We accept that fragments can arrive incidentally in a free-text field — an invoice description, a contact note — and clause 3.5 applies to that data in the same way. What we are asking is that you do not use the Service as a store for it.
5.2 You are responsible for the accuracy of Customer Data and for how you obtained it.
5.3 You will not use the Service to take a decision about an individual based solely on automated processing that produces legal effects or similarly significant effects for them, without applying the safeguards required by Articles 22A to 22C UK GDPR. The Service is not built to take such decisions: Kipp drafts, you approve, and nothing leaves your business without a human pressing send.
6. Sub-processors
6.1 You authorise us to use sub-processors, generally. (Art 28(2)) You give general written authorisation for us to engage Sub-processors on the conditions in this clause.
6.2 The list is public. Our current Sub-processors are listed at app.pocketdocket.co.uk/legal/sub-processors and reproduced in Annex 2. The live page is the authoritative version. By accepting the Terms you authorise the Sub-processors listed there at the date you sign up.
6.3 The list is updated before, not after. We will update the published page before a new or replacement Sub-processor begins processing any Customer Data. This is a commitment, not an aspiration.
6.4 You can subscribe to changes. Email privacy@pocketdocket.co.uk with the subject "sub-processor notifications" and we will email you at least 14 days before any addition or replacement takes effect. We will use reasonable endeavours to give 30 days' notice, and will give it wherever our own supplier gives us enough warning to do so.
6.5 You can object. (Art 28(2)) You may object to a new Sub-processor on reasonable data protection grounds within 14 days of notification. Tell us the grounds and we will discuss it with you in good faith. If we cannot offer you a reasonable alternative — a different provider, a configuration that keeps your data out of scope, or the feature disabled for you — you may terminate the affected part of the Service, or the Service as a whole if the part cannot sensibly be separated, and we will refund charges you have paid for the period after termination. Not objecting is not deemed consent to anything else.
6.6 Urgent replacements. If a Sub-processor has to be replaced quickly for security, legal or continuity reasons, we will give as much notice as we practically can, tell you as soon as possible with our reasons, and your objection right under clause 6.5 applies just as it would have done in advance.
6.7 Flow-down. (Art 28(4)) We will impose on each Sub-processor, by written contract, data protection obligations that are materially equivalent to ours under this Schedule, and in particular the same restrictions on purpose, training and transfers.
6.8 We stay liable. (Art 28(4)) We remain fully liable to you for each Sub-processor's performance of its data protection obligations, subject to clause 11.
7. Personal data breaches
7.1 We will tell you within 48 hours. (Art 33(2)) If there is a personal data breach affecting Customer Data, we will notify you without undue delay and in any event within 48 hours of becoming aware of it. We are aware of a breach when a member of our team with responsibility for security has reasonable confidence that a breach has occurred — not when the investigation is finished.
7.2 What the notification will contain. So far as we know it at the time: what happened; the categories and approximate number of data subjects and records affected; the likely consequences; the measures we have taken or propose to take; and a named contact. If we do not have all of it at once, we will send what we have and follow up without undue further delay rather than wait.
7.3 We will help you meet your own 72 hours. Your clock under Article 33(1) runs for 72 hours from when you become aware. The 48-hour commitment in clause 7.1 exists so that you have time left. We will co-operate with you on investigation, containment, remediation and the content of any notification you have to make.
7.4 We will not notify on your behalf. We will not notify the ICO or any data subject about a breach affecting Customer Data unless the law requires us to, or you instruct us to in writing. That decision is yours.
7.5 We keep a breach log. We maintain an internal record of every personal data breach affecting Customer Data, including the facts, effects and remedial action, and we will make the entries relating to you available to you on request.
7.6 Other clocks. You should know that a breach may also trigger obligations we owe elsewhere — in particular Xero requires incident reporting within 24 hours under its developer terms. Where notifying a third party would identify you, we will tell you that we are doing it.
8. International transfers
8.1 We will not make a Restricted Transfer of Customer Data unless a lawful transfer mechanism under Chapter V UK GDPR is in place for it.
8.2 You instruct and authorise the Restricted Transfers set out in Annex 2, and instruct us to enter into the relevant transfer mechanism on your behalf where one is needed.
8.3 The mechanisms we rely on. For each Sub-processor outside the UK we rely on one of:
(a) the UK Extension to the EU–US Data Privacy Framework (the "UK–US data bridge"), where the recipient is certified to it and the transfer falls within its certification. Where we rely on the data bridge, no transfer risk assessment is required, because the transfer is to a country the Secretary of State has determined provides an adequate level of protection; or
(b) the ICO's International Data Transfer Addendum to the EU Standard Contractual Clauses (or the IDTA), supported by a documented transfer risk assessment.
8.4 Transfer risk assessments. Where we rely on clause 8.3(b) we carry out and document a transfer risk assessment before the transfer begins, and review it at least annually and whenever there is a material change. Our assessments incorporate by reference the Department for Science, Innovation and Technology's published analysis of the laws and practices of the destination country, which the ICO expressly permits and describes as a reasonable and proportionate approach for low, medium and high risk transfers. We will provide the assessment to you on request.
8.5 If a mechanism fails. If we learn that a transfer mechanism has stopped being valid, or that a recipient can no longer comply with it, we will tell you, put an alternative in place without undue delay, or suspend the transfer.
8.6 We will not disclose Customer Data to a public authority outside the UK unless we are legally compelled to. If we are, we will tell you before disclosing where the law permits, and challenge the request where we have reasonable grounds to think it is unlawful.
9. Deletion and return
9.1 Your choice. On termination or expiry, you may tell us to return Customer Data to you, delete it, or both. Tell us within 30 days of termination. If you tell us nothing, we delete.
9.2 Retrieval window. For 30 days after termination we will keep your data available for export in a structured, commonly used, machine-readable format so that you can take it with you.
9.3 Live systems. We will delete Customer Data from live systems within 30 days of the end of the retrieval window.
9.4 Backups. Backups are not deleted individually; they expire on rotation. All Customer Data will have aged out of our backups within 90 days of deletion from live systems. During that window the data stays encrypted, stays subject to this Schedule, and is not accessed for any purpose other than restoring the platform after a failure.
9.5 Credentials first. We will revoke and delete your stored Xero token set, and any bank connection credential, within 7 days of termination — before the rest. You can also revoke our access yourself at any moment from inside Xero, and that revocation takes effect immediately regardless of anything in this Schedule.
9.6 Sub-processors. We will instruct each Sub-processor to delete Customer Data on equivalent terms and use reasonable endeavours to see that they do. We can instruct; we cannot compel. We would rather say that plainly here than promise something we cannot perform.
9.7 What we may keep. We may keep Customer Data where the law requires it, or where it is strictly necessary to establish, exercise or defend a legal claim. Anything kept stays subject to this Schedule, is processed for no other purpose, and is deleted once the reason for keeping it ends.
9.8 Confirmation. We will confirm deletion in writing if you ask within 60 days of termination.
10. Information and audit
10.1 Documentation first. We will give you, on request and free of charge:
(a) our security statement, which is written to serve as the information necessary to demonstrate compliance under Article 28(3)(h); (b) the current Sub-processor list and the transfer mechanism relied on for each; (c) the relevant part of our Article 30(2) record; (d) our transfer risk assessments; and (e) a summary of the most recent penetration test or independent security assessment we hold, once one has been carried out.
10.2 Questions. If that documentation does not answer your question, send the question to privacy@pocketdocket.co.uk and we will answer it in writing within 30 days. Most audits are satisfied here.
10.3 On-site or hands-on audit. If the documentation and our answers are genuinely not sufficient, you may audit us, on these conditions: once in any 12-month period; on 30 days' written notice; during business hours; without unreasonable disruption to the Service or to other customers; limited to systems and records relating to your Customer Data; subject to a written confidentiality undertaking; and at your cost, including our reasonable costs of assistance beyond one working day.
10.4 For cause and by regulators. The once-a-year limit and the notice period do not apply where the audit follows a personal data breach affecting your data, or where the ICO or another competent supervisory authority requires it. In those cases we will co-operate promptly and the cost is ours.
10.5 Your auditor. An auditor you mandate must be independent, must not be a competitor of ours, and must sign a confidentiality undertaking before starting.
10.6 What we will not do. We will not give any auditor access to another customer's data, to our source code, or to information whose disclosure would breach a duty we owe someone else. If that limits what an audit can establish, we will say so and find another way of evidencing the point.
11. Liability
11.1 Liability under this Schedule is subject to the limitation of liability clause in the Terms of Service. That clause contains a separate, higher cap for breaches of data protection, security and confidentiality obligations, set at the greater of £25,000 or five times the Charges paid by you in the 12 months before the claim.
11.2 What that cap does not do. It governs the position between you and us. It does not, and cannot:
(a) limit a data subject's direct right to compensation under Article 82 UK GDPR against either of us; (b) limit the ICO's powers, including its power to issue penalties directly against a processor; or (c) limit anything that cannot lawfully be limited.
11.3 We say this plainly because it matters: a processor has direct statutory obligations and direct statutory liability. A contractual cap between us has no effect on either.
12. If we go outside your instructions
If we determine the purposes and means of processing Customer Data for ourselves, other than as permitted by clause 2.3, we are a controller in respect of that processing under Article 28(10) and answerable for it as a controller. Nothing in this Schedule limits that.
13. Changes to this Schedule
13.1 We may update this Schedule where an update is needed to reflect a change in Data Protection Law, regulatory guidance, an approved code or certification, or a transfer mechanism. We will give you 30 days' notice of any such update.
13.2 If an update materially reduces your protections, you may terminate the Service on notice before it takes effect and we will refund charges paid for the period after termination.
13.3 Every version is dated and kept. Previous versions are available on request.
14. General
14.1 This Schedule is in writing in electronic form, as Article 28(9) permits.
14.2 It is governed by the law of Northern Ireland, and the courts of Northern Ireland have exclusive jurisdiction, unless the Terms say otherwise.
14.3 If any provision is held invalid, the rest continues in force.
14.4 Nothing in this Schedule confers any right on a third party under the Contracts (Rights of Third Parties) Act 1999, except that clause 11.2 is a statement of law and not a grant of rights.
14.5 Contact. Data protection questions: privacy@pocketdocket.co.uk. Security reports: security@pocketdocket.co.uk. Post: Pocket Docket Ltd, 137 York Road, Belfast, BT15 3GZ.
Annex 1 — Particulars of processing
This Annex sets out the matters Article 28(3) requires the contract to state.
Part A — Subject matter and duration
| Subject matter | Our processing of personal data contained in the Customer's connected Xero organisation, any connected bank feed, and content submitted through the Service, for the purpose of providing the Pocket Docket dashboard and the Kipp assistant. |
| Duration | From the first connection of a Xero organisation until the end of the subscription, plus the retrieval, deletion and backup-expiry periods in clause 9. |
Part B — Nature and purpose of the processing
Nature. Collection and retrieval from the Xero API under the Customer's OAuth authorisation; storage; organisation and structuring; per-tenant caching of computed figures; computation of financial metrics in our own code; transmission of computed figures and the Customer's question to the Claude API for explanation; generation of draft text; display through a signed, device-bound dashboard; transmission of email through our email provider at the Customer's instruction; export; erasure.
Purpose. Providing the Service to the Customer, and nothing else. Specifically not: model training, fine-tuning, adaptation or enhancement; cross-customer aggregation or benchmarking; product analytics derived from ledger contents; profiling for our own purposes; marketing to the Customer's contacts; or sale or disclosure to any party outside Annex 2.
A note on how the numbers are produced. Financial figures shown in the dashboard are computed in our own code, not by the AI model. The model receives figures that have already been calculated and explains them. This matters for accuracy, and it also limits how much personal data is sent to the AI provider: what goes is the computed figures relevant to the question and the question itself, per request — not the ledger.
Frequency. Scheduled synchronisation from Xero during the subscription; on demand when the Customer opens the dashboard or asks Kipp a question.
Part C — Types of personal data
- Names, trading names and contact details (email, telephone, postal address) of the Customer's customers and suppliers as recorded in the connected accounting organisation
- Transaction data attributable to those individuals: invoices, credit notes, bills, payments, dates, amounts, references, due dates and payment histories
- Free-text content in invoice descriptions, contact notes, reference and memo fields, which may incidentally contain other personal data
- Bank account names, account masks, institution names, transaction descriptions, amounts and dates, where and only where the Customer connects a bank feed (see the note in Annex 2 — the bank connection is integrated but not active in production)
- Names, contact details and role information of the Customer's own personnel appearing in the accounting organisation, including as approvers, contacts or payees
- Where the Customer is a sole trader or unincorporated business, the Customer's own personal data
- The content of questions submitted to Kipp and the responses generated, and the content of drafts generated for the Customer's approval
- Recipient addresses and message content of emails the Customer instructs the Service to draft or send
- Access records relating to dashboard use: device binding identifiers, timestamps, outcome, coarse device description, and salted hashes of IP addresses
Part D — Categories of data subject
- The Customer's customers — including individuals, sole traders, and named contacts at business customers
- The Customer's suppliers — including individuals, sole traders, and named contacts at business suppliers
- The Customer's employees, officers and contractors, where they appear in the connected accounting organisation
- Other contacts appearing in the connected accounting organisation — agents, advisers, intermediaries, referrers and any other individual recorded there
- The Customer, where the Customer is a sole trader or an unincorporated business
- Users nominated by the Customer to access the dashboard
Special category data: none instructed. Criminal offence data: none instructed. See clause 5.1(e).
Part E — Retention
How these are enforced, stated plainly. Deletion on the end of a connection, and on request, is carried out by us on request or when the connection ends. The periods below for logs, tokens and enquiry details are our retention policy, applied by scheduled review rather than by an automated purge; an automated job enforcing them is being built. We would rather tell you the mechanism than let you assume one.
| Data | Retention |
|---|---|
| Accounting data and computed snapshots | For the life of the connection; then clause 9 |
| Device bindings | For the life of the connection; then clause 9 |
| Access, portal and rate-limit logs | 90 days |
| One-time portal tokens | 30 days |
| Trial and enquiry details | 24 months |
| Complaint records | As long as required for the complaint and any resulting claim |
Part F — Technical and organisational measures (Article 32)
The security statement is the fuller version of this and forms part of it. This table is the summary a reviewer needs in the contract itself.
| Area | Measure |
|---|---|
| Encryption in transit | TLS 1.2 or higher for all connections to the application and to every Sub-processor |
| Encryption at rest — credentials | The Xero token set and the bank access token are encrypted at application level with AES-256-GCM: a 32-byte key held only in platform environment configuration, a 12-byte random initialisation vector per record, and the authentication tag stored with the ciphertext |
| Encryption at rest — everything else | Provider-managed disk encryption on the managed database, including backups. We state this precisely because the two fields above are the only ones we encrypt ourselves; see the security statement for what is planned |
| Pseudonymisation in logs | IP addresses and certain email addresses in log tables are stored as salted SHA-256 hashes, not in the clear. Hash, don't store |
| Access control — customers | Dashboard access is by an HMAC-signed link bound to the first device that opens it. Every other device is refused and the refusal is logged. Refusals are generic and reveal nothing about whether a link, a tenant or a token exists |
| Device identifiers | Randomly generated 256-bit values that we mint. Not device fingerprints. We do not fingerprint browsers |
| Server-side enforcement | The device binding is re-checked server-side on every data API call, not only on the page. The page gate is not the gate |
| Fail-closed | Access controls fail closed. If a check errors, access is refused and the error is logged |
| Tenant isolation | Every query, cache, index and snapshot is scoped to a single tenant. No shared cache, no cross-tenant lookup |
| Least privilege | Administrative access limited to named individuals with multi-factor authentication; service credentials scoped to their function |
| No third-party assets | Nothing in the application loads from a content delivery network or any third-party origin. This is a standing engineering rule, and it is why there are no third-party pixels or trackers to disclose |
| Payment data | Card details never reach our systems. Payment is by hosted checkout at our payment provider |
| Write-back safety | The assistant produces drafts only. No invoice is approved, no email is sent and no payment is made without a human acting |
| Logging and audit | Access outcomes, portal token use, device binding events and administrative actions are logged |
| Incident response | Documented response process; notification to the Customer within 48 hours under clause 7 |
| Sub-processor management | Published list, written contracts with equivalent obligations, notification and objection under clause 6 |
| Personnel | Written confidentiality obligations, data protection training, access on a need-to-know basis |
| Backups | Provider-managed, encrypted, expiring on rotation; restoration exercised as part of platform maintenance |
Annex 2 — Authorised Sub-processors
The current list is published at app.pocketdocket.co.uk/legal/sub-processors and that page is the authoritative version. This Annex reproduces it as at the date of this Schedule so that the contract is complete on its face. Where the two differ, the published page governs, and clause 6 governs how it changes.
| Sub-processor | What it does | What it receives | Location and transfer basis |
|---|---|---|---|
| Vercel Inc. | Hosting and application runtime | All application traffic in transit; environment configuration | United States. DPF-certified (UK Extension to be confirmed on the active list); fallback Vercel DPA standard contractual clauses with the UK Addendum |
| Supabase | Managed Postgres database | Customer records; encrypted Xero token sets; accounting snapshots; trial and referral enquiries; registered contact addresses; device bindings; hashed security logs | Region-dependent — primary region, backup, log and Edge Function locations to be confirmed and stated before publication |
| Anthropic PBC | Claude API — the assistant and the signals layer | Per request: the computed financial figures relevant to the question, and the question asked. Does not train on data submitted through the API | United States. Standard contractual clauses auto-incorporated in the Anthropic DPA; UK Addendum to be confirmed; transfer risk assessment required |
| Resend | Transactional email | Recipient address and message content | EU (Ireland) infrastructure, US entity. Remote access by US personnel is a restricted transfer and is treated as one |
| Stripe | Payments and subscription billing | Name, email, card details, billing address, subscription and payment history | United States. DPF-certified; the UK IDTA Addendum is incorporated into Stripe's Data Transfers Addendum. Stripe acts partly as an independent controller for payment processing, fraud prevention and its own regulatory obligations — for that processing Stripe is not our processor and its own privacy policy applies |
| GitHub, Inc. | Source code hosting | No customer personal data. Listed for completeness | United States |
| Plaid | Bank account connections | Bank institution, account names and masks, transaction history, consent dates | Plaid Inc. (US) / Plaid Financial Ltd (UK). Integrated but not active in production. No customer data reaches Plaid unless and until the feature is enabled and a customer authorises a connection |
Xero Limited is not a sub-processor. Xero is the accounting platform your data already lives in, under your own agreement with Xero. We receive data from it only because you authorised the connection, and you can revoke that authorisation at any time from inside Xero, without asking us.
Version 1.0 · in force from 21 August 2026
© 2026 Pocket Docket Ltd · Registered in Northern Ireland, company number NI742827 · Registered office: 137 York Road, Belfast, BT15 3GZ · ICO registration ZC223982