Data Processing Agreement

Version 1.0 · Last updated: 7 October 2026 · Effective for each customer from the later of that date and the date they accept the Terms of Service

This Data Processing Agreement ("DPA") forms part of the Terms of Service between Scanalyse Limited, a company registered in England and Wales under company number 17338724, whose registered office is at 99 Stockport Road East, Bredbury, Stockport, England, SK6 2AQ ("Scanalyse", "we", the "Processor") and the customer that has accepted those Terms ("you", the "Controller").

You do not need to sign this document for it to apply. It applies to every customer as part of the Terms of Service. Article 28(9) UK GDPR permits the contract required by Article 28(3) to be in writing, including in electronic form, and this is that writing. If your organisation needs a countersigned copy, write to [email protected] and we will provide one on these terms without charge.

Where this DPA and the Terms of Service conflict on a matter of data protection, this DPA prevails. On every other matter, including the limit on our liability, the Terms of Service prevail.

1. Definitions

"UK GDPR", "controller", "processor", "personal data", "processing", "personal data breach", "data subject" and "supervisory authority" have the meanings given in the UK GDPR and, where the EU GDPR applies to your processing, the EU GDPR.

"Data Protection Law" means the UK GDPR, the Data Protection Act 2018, the Privacy and Electronic Communications (EC Directive) Regulations 2003 and, where applicable to you, Regulation (EU) 2016/679 and its national implementations, in each case as amended, including by the Data (Use and Access) Act 2025.

"Customer Personal Data" means personal data we process on your behalf under the Terms of Service, described in Annex I.

"Sub-processor" means a processor engaged by us to process Customer Personal Data.

"Ledger" means the accounting system you have connected to the service: a QuickBooks Online company or a Xero organisation, each held by you under your own agreement with its provider.

"Order Form" means any written subscription terms or order document we agree with you. "Administrator" means a user account you have designated as an administrator of your workspace, and the email address held against it, which is where every notice under this DPA is sent, together with any privacy contact you name in writing to [email protected], to whom we will also send every notice.

"Standard Contractual Clauses" means the 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. "IDTA" means the International Data Transfer Agreement issued under the same section.

2. Roles and scope

2.1 You are the controller of Customer Personal Data. We are your processor.

2.2 We are an independent controller of the account and audit records described in our Privacy Policy under "Our role": your users' account records, and the audit trail of security-relevant actions. This DPA does not govern that processing; our Privacy Policy does.

2.3 If you are yourself a processor for a third party (for example, a bookkeeper or accounting practice acting for a client), you confirm that you have that party's written authorisation to appoint us as a sub-processor on these terms, that you will pass on to them any notice we give you under clauses 6, 9 and 16 that concerns their data, and references to "you" in this DPA include your obligations to them. We will treat an instruction from you as an instruction from that party.

2.4 Each of us complies with Data Protection Law as it applies to us. You are responsible for the lawfulness of the data you give us and of the instructions you give us, including for providing whatever privacy information the law requires you to provide to the individuals named in your suppliers' documents. We have no relationship with those individuals and cannot do that for you.

3. Processing on your instructions

Article 28(3)(a).

3.1 We process Customer Personal Data only on your documented instructions, including in relation to transfers to a third country, unless required to do otherwise by law that applies to us. Where the law requires it, we will tell you before processing unless the law prohibits us from telling you.

3.2 Your instructions are: the Terms of Service, this DPA, the configuration choices you make in the application (including which Ledger you connect, which email senders may send to your workspace address, which of your users may use the in-app assistant, whether automatic posting is used and, if you set one, the monetary ceiling for it, and who may receive an approval link), and the actions your users take in it. Reading documents with our AI provider, and asking it to propose a category for lines that no learned rule matches, are part of how the service works for every workspace and are within your instruction under this clause. Any other instruction must be agreed in writing and we may charge for the work it requires.

3.3 We will tell you immediately if, in our opinion, an instruction infringes Data Protection Law. (Article 28(3), final paragraph.) We may suspend the processing concerned while the point is resolved.

4. Confidentiality

Article 28(3)(b).

4.1 We ensure that every person authorised to process Customer Personal Data is bound by an appropriate obligation of confidentiality, whether by contract of employment, contractor agreement or statutory duty, and that the obligation survives the end of their engagement.

4.2 We limit access to Customer Personal Data to those who need it to provide, secure or support the service. Access by our staff to a customer's data through the operator console is recorded in an audit trail that is retained for as long as the records it describes.

5. Security

Article 28(3)(c) and Article 32.

5.1 We implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. The measures in force are set out in Annex II.

5.2 We may update Annex II to reflect the measures actually in force. We will not make a change that materially reduces the overall level of security, and a change that materially affects your rights is notified under clause 16.1 like any other.

5.3 You are responsible for the security decisions available to you in the application: who has an account, what role each account holds, whether automatic posting is enabled and the monetary ceiling you set for it, which email senders are allowed to send documents to your workspace address, and who receives approval links.

6. Sub-processors

Articles 28(2) and 28(4), and Article 28(3)(d).

6.1 You give us general authorisation to engage the sub-processors listed in Annex III, which is published and kept current at /subprocessors.

6.2 Before we add or replace a sub-processor we will give you at least 30 days' notice by email to your Administrator and by updating the published list. We will replace a sub-processor on shorter notice only where the reason is outside our reasonable control and continuing with the existing sub-processor would put your data or the service at risk; in that case we will give the notice as soon as we reasonably can, which may be after the replacement has taken effect, and clause 6.3 applies from the date of that notice in the same way.

6.3 You may object to a new or replacement sub-processor within 30 days of our notice, by writing to [email protected], stating reasonable grounds relating to data protection. While your objection is being resolved we will not send your Customer Personal Data to that sub-processor where the service allows it. We will work with you in good faith to resolve the objection, for example by not routing your data to that sub-processor or by proposing another measure. If we have not resolved it to your reasonable satisfaction within 30 days of your objection, you may terminate the Terms of Service, or the affected part of the service where it can be separated, on written notice and without penalty, and within 30 days we will refund the fees you have prepaid for the period after termination (for a separated part, a fair proportion of them). Where the sub-processor supports the whole service, so that your data cannot be kept from it while the service runs (today: our hosting provider, our AI provider, our mail provider for the email we send, and our log provider), we will tell you so in our first response and you may then terminate under this clause at once, without waiting out the 30 days; terminating the affected part then means terminating the service.

6.4 Each sub-processor is bound by a written contract with us that imposes data protection obligations meeting the requirements of Article 28(3) UK GDPR. For the sub-processors listed today, that contract is the provider's own standard data processing terms, named in Annex III. We have checked each against Article 28(3), and where a provider's terms give us less than this DPA gives you (for example an audit right exercised through the provider's own reports rather than a visit) we will exercise the rights we have on your behalf and share the result with you. We remain fully liable to you for a sub-processor's performance of those obligations, subject to clause 13.

6.5 Each sub-processor publishes its own list of sub-processors and a way to be told of changes, named in Annex III; we will help you subscribe to it. We do not give separate notice under clause 6.2 of a change within a sub-processor's own chain.

6.6 The providers of your Ledger (Intuit for QuickBooks Online, Xero for a Xero organisation) are not our sub-processors. We send data to them on your instruction, into an account you hold under your own agreement with them. Annex III explains this and lists them anyway, so that you can see every company your data reaches.

7. Assisting you with data subject requests

Article 28(3)(e).

7.1 If a data subject contacts us directly about Customer Personal Data, including with a complaint, we will not respond to the substance. We will tell them to contact you, and pass the request or complaint to you within five working days, unless the law prevents us.

7.2 Taking into account the nature of the processing, we assist you by appropriate technical and organisational measures, insofar as this is possible, to fulfil your obligation to respond to requests to exercise rights under Chapter III UK GDPR and to respond to complaints under section 164A of the Data Protection Act 2018. In practice this means: an export of everything derived from a document, in a structured machine-readable form; erasure of everything derived from a document across the tables that hold it and the stored file, except the coding rules learned from it (which record a supplier's name and the account or item chosen for it) and the mirror of your Ledger, each of which we delete on request; the ability to correct extracted data through the application at any time; and, on request, erasure of your whole workspace. Emails that carried your documents are held in our mailbox as Annex III describes and are not reached by an item-by-item erasure; we delete them on request.

7.3 Erasure through the service does not reach your Ledger. When a document is posted on your authorisation, a bill or a credit note is written into your own QuickBooks company or Xero organisation with the scan attached. That record is yours, held by you with Intuit or Xero, and we make no call to delete it. An erasure performed here removes our copy and leaves yours intact. Our erasure record captures the identity of the surviving Ledger record so that you can act on it. Answering an Article 17 request completely will therefore require you to act in your Ledger as well.

7.4 Assistance under this clause is provided without additional charge, unless a request requires work that is disproportionate to the tooling described above, in which case we will agree a reasonable charge with you first.

7.5 Whether a request is valid, and how to answer it, are your decisions. Your deadline for responding to a data subject is not extended by the time we take, so tell us as early as you can and we will prioritise accordingly.

8. Assisting you with your other obligations

Article 28(3)(f).

Taking into account the nature of the processing and the information available to us, we assist you in complying with your obligations under Articles 32 to 36 UK GDPR: security of processing, notification of a personal data breach to the supervisory authority and to data subjects, data protection impact assessments, and prior consultation. Annex II and our published sub-processor list are provided so that you can complete an assessment without a separate request, and we will answer a reasonable written question about either within 30 days.

9. Personal data breach

9.1 We notify you of a personal data breach affecting Customer Personal Data without undue delay after becoming aware of it, and in any event within 72 hours of becoming aware, and never later than we notify a Ledger provider under clause 9.5. We treat a sub-processor's notification to us as the moment we become aware.

9.2 The notification will describe, to the extent known at the time: the nature of the breach and the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed; and a contact point. If we do not have all of it at once we will notify in phases rather than wait, and we will not delay the first notice in order to complete an investigation.

9.3 We do not notify the supervisory authority or data subjects on your behalf. As controller, that decision and that duty are yours. Article 33(1) requires you to notify without undue delay and, where feasible, not later than 72 hours after you become aware. Regulators' guidance treats a controller as aware once its processor has told it, so our notice will usually start your own clock; we send it with the information you need. We will give you reasonable assistance with the content of your notification.

9.4 We keep a record of every personal data breach, notifiable or not, as Article 33(5) requires, and our incident procedure treats a sub-processor's notification as our own detection.

9.5 Where an incident involves data connected to your Ledger, we are separately required by the Ledger provider's developer terms to notify Intuit or Xero within 24 hours of discovery. You instruct us to make that notification, which will contain no more of your data than the Ledger provider's terms require. It runs in parallel with clause 9.1 and does not delay it; clause 9.1 means you hear from us no later than the Ledger provider does.

10. Return and deletion

Article 28(3)(g).

10.1 At the end of the provision of the service, at your choice, we delete or return all Customer Personal Data and delete existing copies, unless law requires us to keep it. The retention periods in Annex I and in our Privacy Policy apply while the service is running; they do not survive it and are not a reason to keep anything after it ends. In particular the seven year figure tracks a VAT record keeping obligation that is yours and not ours, so it gives us no basis to retain your data once you have asked for it back or asked us to delete it.

10.2 You may make that choice at any time up to 30 days after the service ends, by writing to [email protected]. Your documents are already attached to the records in your Ledger; on request we will also give you, within 30 days, a machine-readable export of the data we hold for your workspace and copies of the stored documents. If you make no choice, we delete your Customer Personal Data within 30 days after that period ends, subject to clause 10.4.

10.3 Retention periods that apply while the service is running are set out in Annex I and in our Privacy Policy.

10.4 Backups. Data in database backups cannot be deleted item by item. On deletion we put it beyond use immediately, meaning we do not access it, do not restore it into the live service, and keep it secured, and it is then destroyed with the backup on that backup's ordinary cycle, currently seven days. This follows the Information Commissioner's stated position on Article 28(3)(g), that immediate deletion from backups is not required where the data is put beyond use and destroyed on the next deletion cycle.

10.5 Clause 7.3 applies: records already written into your Ledger are not ours to delete.

10.6 Platform logs and the mailbox. Operational log lines are retained by our hosting and log providers on short cycles stated in Annex II and Annex III and are not reached by an item-by-item erasure; they are written with customer values replaced by opaque tokens, as Annex II describes. Emails that carried your documents are kept in our mailbox for the period stated in Annex III and are not reached by an item-by-item erasure or by erasing your workspace; we delete them sooner on request.

11. Information and audits

Article 28(3)(h).

11.1 We make available to you all information necessary to demonstrate compliance with Article 28 and this DPA. The ordinary means are our evidence pack: Annex II; our published sub-processor list; our records of processing and data protection impact assessment on request; the results of our automated dependency and security scans; and our answers to a reasonable security questionnaire, which we will give within 30 days. We intend to keep the evidence pack current so that most audit questions can be answered from it without a visit.

11.2 You may audit us, or appoint an independent auditor to do so, once in any twelve month period, and additionally after a personal data breach affecting your data. Before an audit begins we will offer the evidence pack and any current independent report covering the scope you propose. Whether that answers your question, and the choice of auditor, remain yours. We do not hold a SOC 2 or ISO 27001 certification today and we do not claim one. We will also allow an audit that a supervisory authority requires. If you act for clients (clause 2.3), you may exercise this right on behalf of any of them; one audit in any twelve month period covers all of them, except an audit after a breach that affects a particular client.

11.3 An audit is subject to: at least 30 days' written notice; a scope proposed by you in that notice, limited to our processing of your Customer Personal Data, which we may ask to narrow but may not refuse, and which stands as proposed if we have not responded within 14 days; conduct during business hours in a way that does not disrupt the service or expose the data of other customers; and the auditor being bound by confidentiality. You bear your own costs and the auditor's; we bear ours, unless the audit finds a material breach of this DPA, in which case we bear the reasonable costs of that audit.

11.4 We may propose an auditor, and we may make a remote audit available; the final choice of auditor and of remote or on-site is yours.

12. International transfers

12.1 Our application, database and stored documents are hosted in the United Kingdom, in DigitalOcean's London region (LON1); our AI provider reads document contents in the United States (Annex III). DigitalOcean states that its employees do not have access to customer content unless a customer grants permission for support. DigitalOcean's published sub-processor list names providers in the United States that support all of its services, including Amazon Web Services for backups and infrastructure, Cloudflare for platform security, and Traversal for customer troubleshooting and support, so some handling of data outside the UK is possible, principally for support, backup and platform security.

DigitalOcean, LLC holds an active certification under the EU-U.S. Data Privacy Framework and its UK Extension, due for recertification on 3 March 2027 (as at the version date of this DPA; we re-check it before each version is published), and this is the mechanism its data processing agreement applies to such transfers. That agreement also sets out the EU Standard Contractual Clauses (2021/914) and the UK Addendum to those Clauses, which take effect if the Data Privacy Framework is invalidated or DigitalOcean fails to recertify. DigitalOcean is contractually responsible to us for its sub-processors and requires them to meet obligations no less protective than its own.

12.2 Our other sub-processors, and the countries they process in, are listed in Annex III, which states for each the transfer mechanism relied on. Where we transfer Customer Personal Data to a country that is not covered by UK regulations approving transfers to it, the transfer is made under the Standard Contractual Clauses as supplemented by the UK Addendum, or under the IDTA, as set out in the relevant sub-processor's data processing terms. We assess and record the risk of each such transfer (what UK legislation now calls the data protection test); the written assessments for the transfers in Annex III are being completed and will be available in the evidence pack under clause 11.1. Where an importer is certified under the UK Extension to the EU-US Data Privacy Framework we may instead rely on that certification, and we re-check that its status is active.

12.3 You instruct us to make those transfers as a necessary part of providing the service. Every document you submit is read by our AI provider, and the names and types of the accounts and items in your Ledger are sent to it so that document lines can be matched to them. The service cannot be run without that transfer. If you cannot accept it, the service is not suitable for you; clause 6.3 applies to any change of AI provider.

12.4 Transfers to your Ledger provider are made on your instruction into your own account and are governed by your own agreement with Intuit or Xero, including the transfer safeguards in that agreement. Annex III states where each provider processes.

12.5 Where you are established in the United Kingdom, no restricted transfer takes place between you and us. Where you are established in the European Economic Area, your transfer to us is covered by the European Commission's adequacy decision for the United Kingdom. If you are established elsewhere and your law requires a transfer instrument for your transfer to us, tell us and we will agree one with you. Where that instrument is the Standard Contractual Clauses, Module Two (controller to processor) applies, or Module Three (processor to processor) where you act as a processor for a client; this DPA populates their Annexes as follows: Annex I to the Clauses is Annex I to this DPA, Annex II to the Clauses is Annex II to this DPA, and the list of sub-processors is Annex III to this DPA; the optional docking clause does not apply; the period for sub-processor notice is the period in clause 6.2; and the governing law and forum are those in clause 17 save where the Clauses require otherwise.

13. Liability

13.1 Each party's liability under or in connection with this DPA, including for a breach of Data Protection Law in performing it, is subject to the exclusions and the limit of liability in the Terms of Service, and all liability under this DPA counts towards the single limit in those Terms. There is no separate limit here and no uncapped carve-out for data protection claims.

13.2 Nothing in this clause or in the Terms of Service limits or excludes: a data subject's rights or remedies against either of us under Article 82 UK GDPR; either party's liability to a supervisory authority; or any liability that cannot lawfully be limited or excluded. As between us, where we are each liable for the same damage under Article 82(4), each of us bears the part of the compensation that corresponds to its responsibility, as Article 82(5) provides, and the limit in the Terms applies to that contribution to the extent the law allows.

14. Our own direct obligations

Nothing in this DPA relieves either of us of the obligations that Data Protection Law places on us directly. In particular, we do not process Customer Personal Data except on your instructions unless the law requires it, we maintain records of the categories of processing we carry out for you, we have registered with the Information Commissioner (registration ZC205165), and we cooperate with the Information Commissioner on request.

15. Term

This DPA applies for as long as we process Customer Personal Data, and clauses 4, 7.3, 9.4, 10, 11, 13, 14 and 17 survive its end.

16. Changes to this DPA

16.1 We may update this DPA where a change in law, in the service, or in our sub-processors requires it. We will give you at least 30 days' notice of a change that materially affects your rights, by email to your Administrator and by publishing the new version with a new date and version number at /dpa. If a change is materially adverse to you, you may terminate the Terms of Service before it takes effect and we will refund any fees you have prepaid for the period after termination.

16.2 We keep previous versions available on request, so that you can see what you agreed to and when.

17. Governing law and jurisdiction

This DPA, and any dispute or claim arising out of or in connection with it, whether contractual or not, is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction, except that where the Standard Contractual Clauses apply directly between us their own governing law and forum provisions prevail for the purposes of those Clauses.

About this document. This agreement was prepared with the assistance of an AI drafting tool working from UK GDPR Article 28, the Information Commissioner's published guidance and our own records of how the service works, and Scanalyse Limited has chosen to publish it without a solicitor's sign-off. We recommend that you have your own adviser read it. If a solicitor's review leads to a revised version, it will be published under clause 16.

Annex I: Details of the processing

Structured to mirror Annex I to the Standard Contractual Clauses, so that a customer's data protection officer can map it without translation.

A. Parties

Data exporter / controller	The customer accepting the Terms of Service. Role: controller (or, where the customer is a bookkeeper or accounting practice acting for a client, processor for that client). Activities: operating its own, or its client's, accounts payable. Contact: the Administrator account on the customer's workspace
Data importer / processor	Scanalyse Limited, 99 Stockport Road East, Bredbury, Stockport, England, SK6 2AQ, company number 17338724. Role: processor. Contact: [email protected]. ICO registration ZC205165

B. Description of the processing

Categories of data subjects

• Suppliers of the controller, including individuals trading in their own name
• Employees and contacts of those suppliers named in purchase documents
• The controller's own customers where a purchase document names them (for example a vehicle registration or a job reference on a parts invoice)
• The controller's own users, where their names or email addresses appear in documents, approval requests or the list of allowed email senders
• Recipients of a document approval link sent by the controller
• People who email documents to the controller's workspace address

Categories of personal data

• The contents of uploaded, photographed or emailed purchase documents and supplier statements, including any personal data they happen to contain
• Supplier name, trading address, email address, telephone number
• Tax and company registration numbers
• Bank and payment reference details appearing on a document
• Line item descriptions, quantities and prices, and purchase order references
• Reference data read from the Ledger: supplier, customer, item and account names and codes, tax rates, and the open bills and payments the Ledger lists
• The sender address of an emailed document, and the email addresses the controller allows to send to its workspace
• The answers the controller gives to the business profile questions, where they name a person

Your users' account records and our audit trail are processed by us as controller (clause 2.2) and are described in our Privacy Policy, not here.

Special categories of personal data

None is intended, requested or extracted. Purchase documents should not contain data of the kinds described in Articles 9 or 10 UK GDPR, and the Terms of Service prohibit using the service for them without written agreement. There is a residual risk that a document incidentally contains such data; no additional restriction beyond the measures in Annex II is applied to it, and the erasure tooling reaches it.

Frequency of the transfer

Continuous, for the duration of the Terms of Service.

Duration of the processing

For the term of the Terms of Service and, after it ends, the period in clause 10.

Nature and purpose of the processing

Reading purchase data from documents using a large language model, with human review in the application; mapping each line to an item or nominal account in the controller's Ledger, using the Ledger's own reference data and, for lines that do not match a learned rule, a large language model; learning that mapping per workspace; application of UK VAT treatment; posting of bills, credit notes and, where the feature is available for the connected Ledger, bill payments to the controller's Ledger with the document attached; reconciliation of supplier statements; production of spend analytics for the controller; an in-app assistant that answers questions about using the service and about the controller's business profile; provision of support.

Automated decision-making

The service makes no decision producing legal or similarly significant effects on an individual without human involvement, and it does not profile individuals. Where the controller switches automatic posting on, documents that pass the application's checks (and, where the controller has set a monetary ceiling, are at or below it) are posted to the Ledger without a person looking at them; that is the controller's instruction and the controller's responsibility.

Retention

These are the default retention settings for Customer Personal Data while the service is running. By using the service you instruct us to apply them; you can shorten them at any time by deleting documents or asking us to delete them, and we will not lengthen them for your data without notice under clause 16.1. In summary: documents are archived once posted, or after approximately 90 days if left un-posted, and are deleted approximately 7 years after archiving, aligned to UK VAT record keeping; a document that has been dismissed or has failed and is uploaded again is treated as a new arrival and its periods run again from that upload, while a second upload of a document that is already live is refused as a duplicate and creates no new copy; Ledger access tokens are kept until you disconnect the Ledger; the sender address of a refused email is blanked after 90 days; emails that carried your documents are kept as Annex III states. The mirror of your Ledger is a cache of your own records, refreshed from the Ledger and cleared from the application's Settings or on request; records written into your Ledger are outside our control (clause 7.3). The automated sweep that applies these periods is not yet switched on: un-posted documents older than 90 days may not yet have been archived, no document has reached the seven year deletion point, and deletion on request is available at any time. Our Privacy Policy repeats this summary for the people named in your documents; if the two ever differ, this Annex governs.

Transfers to sub-processors

See Annex III. Each entry states the subject matter, nature and duration of that sub-processor's processing.

C. Competent supervisory authority

The Information Commissioner's Office (United Kingdom), as the authority of the processor's establishment. Where the EU GDPR applies to the controller, the controller's own competent authority applies to the controller's processing.

Annex II: Technical and organisational measures

Article 32 UK GDPR. Every measure below was checked against the application source as at the version date above. Items marked [operator-attested] are true of the production deployment but are configuration rather than code, and cannot be verified from source alone; the evidence for each is held in our deployment records.

1. Pseudonymisation and encryption (Art. 32(1)(a))

• Encryption at rest of the documents themselves. Scanned documents are encrypted with Fernet (AES-128-CBC with HMAC-SHA256 authentication) before they are written to object storage, so ciphertext is what reaches the storage provider. Enabled by default.
• Encryption at rest of credentials. Ledger access and refresh tokens for QuickBooks Online and for Xero, and two-factor authentication secrets, are encrypted with the same key family before being stored. Xero credentials are additionally held in a table the application role cannot read directly (see tenant isolation below).
• Fail-closed key handling. If no encryption key can be resolved, the application raises rather than falling back to plaintext. There is no plaintext-on-failure path.
• Key rotation. Multiple keys are supported concurrently: a new key encrypts, all configured keys decrypt, so a key can be rotated without downtime and old data re-encrypted progressively.
• Key provider. Keys are supplied by a pluggable provider supporting an environment or secret store, a file, an external command, or AWS KMS. The production deployment uses the hosting platform's encrypted secret store.
• Encryption in transit. The service is served over HTTPS with HTTP Strict Transport Security, and connections to the managed database use TLS. [operator-attested]
• Storage-layer encryption is additionally applied by the hosting provider to the managed database and object storage.
• Pseudonymised logging. Supplier names, line descriptions, email addresses and similar values are replaced in operational logs by opaque keyed tokens, so that a log line can be matched to a database row by us but names nobody to a reader holding only the log. This is a best-effort control applied at the places we have identified; it is not a guarantee that no customer value ever reaches a log.
• AI usage records hold counts, never content. The record we keep of each AI call stores token counts, the calling feature and document identifiers only; no prompt text, reply text, supplier name or file name.

2. Confidentiality, integrity, availability and resilience (Art. 32(1)(b))

Access control

• Per-user accounts. No shared or generic logins.
• Passwords hashed with PBKDF2-HMAC-SHA256 at 200,000 iterations with a per-password random salt, verified in constant time. Minimum length 12 with a letter and a digit required.
• Role-based access control: admin and operator roles within a customer workspace, plus two platform tiers held only by Scanalyse personnel, one for support and one for the cross-customer operator console. The operator console tier is granted only from the command line and never through the application, and it refuses machine and API-token principals.
• Two-factor authentication (TOTP) is required for administrator accounts and for all Scanalyse platform staff. It is enforced at the router level across the whole application, so an enforced account that has not enrolled cannot reach any page other than enrolment. Authenticator secrets are stored encrypted. [operator-attested: switched on in production.]
• Session revocation. Session cookies are signed with HMAC-SHA256, last 12 hours (30 days where the person ticks "Remember me") and carry a per-user epoch that is compared against the stored value on every request. Changing a password or resetting two-factor authentication increments that epoch in the same database statement, so every outstanding session for that person stops working immediately, including sessions on other devices.
• Approval links sent to an external approver are scoped to one document by a hashed token, bound to the device that first opens them, time-limited, revocable, and audited; the approver sees exactly what will be posted.

Tenant isolation

• Every customer's data is scoped to a tenant identifier at the application layer, and PostgreSQL row level security policies enforce the same boundary at the database layer, keyed on a per-connection setting that the application sets on checkout and clears on return. The policies are fail-closed: a connection with no tenant set reads nothing. [operator-attested: applied to the production database by an operator procedure rather than by the migration runner; in force since 12 July 2026, confirmed by live query on 12 August 2026, and re-confirmed before each version of this Annex is published.]
• Tables holding credentials that may be shared across workspaces (Xero sign-ins) are deny-all to the application role: every access goes through database functions owned by the schema owner that read the current tenant themselves rather than accepting it from the caller, and erasure of those rows goes through the same functions.
• A workspace may hold one Ledger at a time, enforced in the database on both the QuickBooks and the Xero tables, so one workspace's mapping rules and mirror cannot be written against another organisation's records.

Application security

• Cross-site request forgery protection on cookie-authenticated state-changing requests, using a token cryptographically derived from the session cookie so that it rotates with the session automatically. On by default; API callers authenticating with a bearer token are outside its scope, by design. [operator-attested, as above.]
• Security response headers on every response: X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer, Cross-Origin-Opener-Policy: same-origin, X-Frame-Options, a Permissions-Policy, and a Content Security Policy restricting sources to the application's own origin, with framing denied by default. HTTP Strict Transport Security where enabled. The Content Security Policy currently permits inline scripts and styles; removing that permission is a tracked engineering item.
• All database queries are parameterised. Values interpolated into QuickBooks query strings, which the QuickBooks query language does not allow to be parameterised, are validated against strict anchored patterns before use.
• Uploads are limited by size, type and page count. Emailed documents are accepted only from senders the workspace has allowed (its own users' addresses and any addresses an administrator adds), routed by the workspace's own unique address, and a refused sender's address is blanked after 90 days.
• Prompt injection defences. Document text sent to the AI provider is fenced with an unpredictable per-request boundary, and the model's reply is accepted only against a closed vocabulary and the identifiers that were actually sent, so text inside a supplier's document cannot instruct the model to post, delete or map anything. A document whose AI reading was cut short is never auto-posted.
• Rate limiting: a per-IP limit for anonymous requests and a per-sign-in limit for authenticated ones, and repeated failed sign-in attempts throttled at five attempts per fifteen minutes, applied both per IP address and per account, with the counter reset on a successful sign-in. This is time-windowed throttling, not a persistent account lock.
• Unattended posting is bounded. Automatic posting is off unless it is switched on. Where it is on, a document posts without review only if the AI reading was complete and self-consistent, it passes the application's other checks, and it was not emailed to the workspace (an emailed document always waits for a person). Credit notes are treated in the same way as bills. A workspace administrator can set a monetary ceiling; once one is set, a document whose total is above it waits for a person. Until an administrator sets a ceiling, there is no limit on the amount that can be posted automatically.

Logging and accountability

• An audit trail records sign-ins and failed sign-ins, two-factor verification, password resets, document postings and bulk postings, entity creation in the Ledger, payment recording, committing and deletion, mapping changes, data exports and erasures, Ledger connections and disconnections, and access by Scanalyse staff to a customer's data through the operator console.
• Writing an audit entry never blocks the action it describes, so in the event of a database failure an action can complete without its entry being written. We do not present the audit trail as a guaranteed-write ledger. Every such failure is logged as a warning with the actor, the action and the tenant, so a gap in the trail is detectable rather than silent.
• Audit entries evidencing a deletion or a data request, entries that are the only record of something the application still displays, and the record of staff access are retained for as long as the records they describe, rather than being trimmed at 24 months; the trim can never run below 12 months.
• Requests carry a correlation identifier through the application logs.
• Operational logs from both the web and the worker components are forwarded to a log provider (Annex III) for alerting, where they are retained for a short cycle, currently three days on the plan in use.

Availability and resilience

• The managed database is backed up daily by the hosting provider with point-in-time recovery within a seven day window. A restore drill and a point-in-time recovery drill were executed and passed on 21 July 2026, each proven by comparing row counts and sentinel rows between the restored and source clusters. [operator-attested. The database is single-node with no high-availability standby.]
• The web and worker tiers are separate components; each worker loop records a heartbeat, and external monitors alert on the service and on named failure lines in the logs.

3. Restoring availability and access after an incident (Art. 32(1)(c))

Provider backups and point-in-time recovery as above; a documented incident response and breach runbook covering detection, containment, risk assessment, notification (including the 24-hour notice owed to the Ledger provider) and recording; and per-customer credential revocation, encryption key rotation, session revocation and account disablement as containment measures.

4. Testing and evaluation (Art. 32(1)(d))

• Automated dependency vulnerability scanning on every push and pull request, failing the build on any advisory, together with generation of a CycloneDX software bill of materials.
• An automated test suite that is a condition of merge, including tests that enforce data protection properties directly: that the erasure and export paths reach every table holding document-derived data, that the audit trim never removes an entry a screen still reads, that log redaction is applied where customer values are logged, and that the published legal pages state the correct legal entity.
• Internal security self-assessment.

5. Organisational measures

• Confidentiality obligations on everyone with access, per clause 4.
• Access limited to those who need it. Staff access to a customer's data through the operator console is recorded in the audit trail and kept for as long as the records it describes. Direct access to the production database is limited to the company's director, is used only for maintenance, support you have asked for and incident response, and is not recorded in the application's audit trail.
• Secrets held in the hosting platform's encrypted secret store, never in source control; Ledger and mail credentials are stripped from logs and error reports at the configuration layer.
• Records of processing maintained under Article 30, and a data protection impact assessment, each available to you on request.
• ICO registration ZC205165.

6. Measures the controller is responsible for

Deciding who has an account and what role it holds; enabling or not enabling automatic posting and setting its ceiling; deciding who receives document approval links; deciding which email senders may send to the workspace address; keeping its users' credentials secure; and deciding which of its users may use the in-app assistant.

Annex III: Sub-processors

Published and kept current at /subprocessors. That published page is the operative list; this annex reproduces it as at the version date above. Notice of changes is given under clause 6.2. Each entry was checked against the provider's own published terms on the date stated in it.

Sub-processor	What it processes	Purpose, duration and retention	Transfer mechanism
Anthropic (contracting entity for UK customers: Anthropic Ireland, Limited, Dublin; processing in the United States)	Every page of every document you upload, photograph or email, and every supplier statement, as images and text; the lines of each document, with the names and types of the accounts and items in your Ledger so that lines can be matched to them; your answers to the business profile questions; and the text of in-app assistant conversations, for users who have the assistant switched on	Reading purchase data from documents, proposing a category for lines no learned rule matches, and answering questions in the assistant, for the duration of the Terms of Service. Under Anthropic's commercial terms, which our account is on, inputs and outputs are deleted within 30 days, except where content is flagged by the provider's automated trust and safety systems, in which case it may be kept up to 2 years and the resulting classification scores up to 7 years. The provider does not train its models on what we send it. We are seeking a zero-data-retention arrangement and a countersigned copy of Anthropic's data processing addendum; until either is in place, Anthropic's standard addendum, incorporated in its commercial terms (addendum effective 24 February 2025), governs and the retention described here applies. Anthropic's own sub-processors are listed at trust.anthropic.com	Anthropic processes the data in the United States. The transfer is made under Anthropic's data processing addendum, which incorporates the Standard Contractual Clauses (Module Three, with us as exporter) and the UK Addendum, and which requires Anthropic to apply equivalent safeguards to its affiliates and sub-processors. Our contracting party is Anthropic Ireland, Limited. Anthropic is not certified under the Data Privacy Framework (checked against the official register 6 August 2026)
DigitalOcean (DigitalOcean, LLC, a United States company; the data is held in its London region)	All data at rest: application, managed PostgreSQL database, and object storage holding the encrypted documents; platform runtime logs	Hosting, for the duration of the Terms of Service	Processed in DigitalOcean's UK region (LON1). Some support, backup and platform-security providers are in the United States. Covered by DigitalOcean's active EU-U.S. Data Privacy Framework certification and UK Extension, with the EU Standard Contractual Clauses and UK Addendum in its data processing agreement as the fallback. Stated in full at clause 12.1
Microsoft (Microsoft Limited, Microsoft Campus, Thames Valley Park, Reading RG6 1WG, United Kingdom, from which we buy Microsoft 365; the mailbox tenant is set up in the United Kingdom)	Inbound: emails sent to your workspace's forwarding address ([email protected]) and their attachments, including the sender's address and the message. Outbound: the notices, password resets, approval links and digests we send to your users and approvers	Hosting the mailbox that email forwarding reads through Microsoft Graph, and sending our outbound email (which is not kept in the mailbox), for the duration of the Terms of Service. A processed message is moved to a Processed folder in the mailbox, a refused message to a Held folder, and a message to an address that matches no workspace to an Unrouted folder. A retention policy on the mailbox deletes messages in those folders after 90 days. Deleting a document in the service, or erasing your workspace, does not remove the email it arrived in before then; on request we will delete it sooner	Microsoft's Products and Services Data Protection Addendum, which incorporates the EU Standard Contractual Clauses and the UK Addendum, with Microsoft's Data Privacy Framework certification including the UK Extension where applicable. Exchange Online data for a tenant provisioned in the United Kingdom is stored in Microsoft's UK data centres under Microsoft's published data residency commitments; support and some service operations may take place elsewhere
Better Stack (Better Stack, Inc., a Delaware corporation operated from Prague; log and uptime monitoring)	Operational log lines forwarded from our web and worker components: workspace identifiers, the usernames of your users where an action is logged, opaque tokens standing in for supplier names and line descriptions, email domains, error text and request identifiers. Never documents, and never the values the redaction layer replaces	Alerting us when the service, the mailbox reader or a Ledger connection fails, for the duration of the Terms of Service. Retained for three days on the plan in use (checked 12 August 2026)	Logs are stored in the European Union. Better Stack, Inc. is a United States company and some of its sub-processors are in the United States, including Amazon Web Services, Cloudflare and an AI provider (OpenAI, L.L.C.), whose AI features we keep switched off on our account. The transfer is made under the Standard Contractual Clauses together with the UK Addendum set out in Schedule E of Better Stack's data processing agreement (25 February 2025). Its sub-processor list is published with that agreement

Your Ledger provider is a recipient, not a sub-processor. We transmit your data to Intuit or to Xero on your instruction, into a QuickBooks Online company or a Xero organisation that you hold in your own name under your own agreement with that provider. We do not engage either to process data on our behalf.

Intuit's developer terms state that an application developer does not process User Data on Intuit's behalf, and we are required to tell you so; Intuit is not our sub-processor. As between you and us, everything we read from or write to your Ledger is Customer Personal Data that we process as your processor under this DPA. Xero's developer terms do not use controller or processor language; under your own agreement with Xero, Xero is your processor for your organisation's data, and it is not ours.

Recipient	Location	What it receives	Basis
Intuit (Intuit Limited, London, for UK customers; QuickBooks Online is operated from the United States)	United States	Supplier, line item, VAT and payment data written to your QuickBooks company, and the document attached to it; and the reference data and open items we read back from it	Your instruction, and your own agreement with Intuit for your QuickBooks account. Intuit is certified under the Data Privacy Framework including the UK Extension and its terms also carry the Standard Contractual Clauses and the UK Addendum
Xero (Xero Limited, New Zealand, operates the developer platform; Xero (UK) Limited, Milton Keynes, company number 06071722, is Xero's UK entity; Xero hosts its service outside the United Kingdom)	Outside the United Kingdom, as stated in Xero's own privacy notice and data processing terms	Supplier, line item and VAT data written to your Xero organisation as bills and credit notes, the document attached to it, a new contact where a supplier is not already there, and the reference data and organisation settings we read back from it. Payments and statement features are not available on a Xero organisation today	Your instruction, and your own agreement with Xero, under which Xero's data processing terms (carrying the UK Addendum) apply between you and Xero

Sage. We do not offer a Sage connection to customers today. If we do, Sage will be added to this table as a recipient under clause 6 before any customer connects it.

We disclose Intuit and Xero here notwithstanding the classification, because a list of every company your data reaches is more useful to you than a list that is technically exact and quietly incomplete. Clause 7.3 and the Retention section of our Privacy Policy explain the consequence that matters: records written into your Ledger are outside our reach, including for erasure.

Not sub-processors. Individuals and companies engaged by Scanalyse Limited to provide support or development services are not sub-processors of Customer Personal Data unless they process it, and where they do they are bound by clause 4 and are within the scope of clause 6.4.