Senex Intelligence Ltd - Customer Data Processing Agreement

Version: customer-dpa-v2026-07-18
Effective date: 18 July 2026
Product: Mosaic Theory AI and related Senex Intelligence research-intelligence software
Processor: Senex Intelligence Ltd, a private limited company registered in England and Wales with company number 17114748 and registered office at 167-169 Great Portland Street, 5th Floor, London, United Kingdom, W1W 5PF
Customer: [Customer legal name]
Agreement: The applicable order form, pilot agreement, Terms of Service, master services agreement, or other customer contract between Senex and Customer

1. Introduction

1.1 This Data Processing Agreement (DPA) forms part of the Agreement between Customer and Senex.

1.2 This DPA applies where Senex processes Customer Personal Data as a processor or sub-processor in connection with the Service.

1.3 If there is a conflict between this DPA and the Agreement on the subject of privacy, data protection, or processing of Customer Personal Data, this DPA prevails. If Standard Contractual Clauses, a United Kingdom International Data Transfer Agreement, or a United Kingdom Addendum applies to a Restricted Transfer, that transfer instrument prevails to the extent required by law.

2. Definitions

In this DPA:

Affiliate means an entity that directly or indirectly controls, is controlled by, or is under common control with a party.

Agreement means the applicable commercial agreement between Customer and Senex for use of the Service.

Approved Sub-processor means a Sub-processor listed in Schedule 3 or later appointed in accordance with section 8.

Cloudflare-only default configuration means the default pilot and Entry-tier configuration in which Cloudflare is the only Approved Sub-processor for Customer Personal Data, and Anthropic, Modal, OpenAI, Google artificial-intelligence services, and any other non-Cloudflare artificial-intelligence or document-conversion provider are not enabled for Customer Personal Data unless separately authorised.

Conditional Egress Feature means an optional product feature that transmits or makes Customer Data available to a provider other than Senex's Cloudflare-only default infrastructure stack.

Conditional Egress Provider means a provider used for a Conditional Egress Feature, including Anthropic for anthropic_platform and Modal Labs for modal_ingest where those features are enabled.

DPA Reference or dpaRef means a customer-specific reference to the signed order form, signed DPA amendment, written instruction, or other legally binding customer document authorising the relevant Conditional Egress Feature. A generic placeholder, blank field, unsigned link, "terms coming soon" label, or internal ticket number alone is not a DPA Reference.

Feature Consent means the affirmative tenant-level record by which Customer authorises a Conditional Egress Feature after being shown the current Feature DPA Terms and feature disclosure.

Feature DPA Terms means the viewable legal terms for the relevant Conditional Egress Feature, identified by a stable version string and disclosure hash.

Customer Content means documents, prompts, questions, outputs, account data, audit data, and other content submitted to or generated through the Service for Customer.

Customer-enabled Third-Party Service means a third-party service that Customer chooses to enable using Customer's own account, credentials, contract, or application programming interface key, and for which Customer is responsible for the relevant third-party relationship unless an Order Form says otherwise.

Customer Personal Data means any Personal Data contained in Customer Content that Senex processes on behalf of Customer in connection with the Service.

Data Protection Laws means all privacy and data-protection laws applicable to the processing of Customer Personal Data under the Agreement, including, where applicable, the United Kingdom General Data Protection Regulation, the Data Protection Act 2018, the European Union General Data Protection Regulation, the Swiss Federal Act on Data Protection, and any replacement or successor legislation.

Personal Data Breach has the meaning given in applicable Data Protection Laws and, in practical terms, means a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data.

Restricted Transfer means a transfer of Customer Personal Data to a country or recipient that requires a transfer safeguard under applicable Data Protection Laws.

Service means Mosaic Theory AI and any related Senex Intelligence software, platform, hosted infrastructure, support, and documentation supplied under the Agreement.

Sub-processor means another processor engaged by Senex to process Customer Personal Data on behalf of Customer.

The terms controller, processor, data subject, processing, personal data, and supervisory authority have the meanings given in applicable Data Protection Laws.

3. Roles of the parties

3.1 Customer as controller. Customer is the controller of Customer Personal Data. Customer determines what Customer Content is uploaded, what questions are asked, which users are authorised, and the purposes for which the Service is used.

3.2 Senex as processor. Senex processes Customer Personal Data as Customer's processor, only to provide the Service and only in accordance with Customer's documented instructions.

3.3 Customer acting as processor. If Customer is itself acting as a processor for a third-party controller, then Senex acts as Customer's sub-processor. In that case, Customer is responsible for ensuring that its instructions to Senex are consistent with the instructions and authorisations Customer has received from the relevant controller.

4. Customer instructions

4.1 Customer instructs Senex to process Customer Personal Data only as necessary to:

• provide, secure, maintain, troubleshoot, and improve the Service for Customer;
• receive, store, convert, index, retrieve, and process Customer Content;
• generate embeddings, search results, answers, citations, source links, histories, and audit records for Customer;
• process Customer Personal Data through Approved Sub-processors for the purposes described in Schedule 3;
• transmit Customer Personal Data to a Customer-enabled Third-Party Service only where Customer has enabled and authorised that service in accordance with section 9;
• provide support requested by Customer;
• comply with the Agreement and applicable law; and
• perform the processing described in Schedule 1.

4.2 Senex must not process Customer Personal Data for any purpose other than the purposes described in this DPA, the Agreement, Customer's configuration choices, or Customer's written instructions.

4.3 Senex must not sell Customer Personal Data, use Customer Personal Data for advertising, or use Customer Content to train artificial-intelligence models.

4.4 Conditional non-default provider egress. Senex must not send, transmit, disclose, or make Customer Personal Data available to Anthropic, Modal Labs, OpenAI, Google artificial-intelligence services, or any other non-Cloudflare artificial-intelligence, document-conversion, document-processing, or external-processing provider unless one of the following applies:

• the provider is listed as an Approved Sub-processor in Schedule 3 for the relevant Service configuration and processing purpose; or
• Customer has expressly authorised the specific Conditional Egress Feature through an Order Form, signed amendment, written instruction, or product setting that is backed by an active Feature Consent, current Feature DPA Terms, matching disclosure hash, and non-empty DPA Reference.

A placeholder disclosure, missing DPA Reference, stale version string, stale disclosure hash, or "terms coming soon" page is not a valid instruction and must not be treated as Customer consent.

4.5 If Senex believes that an instruction infringes applicable Data Protection Laws, Senex will inform Customer unless prohibited by law.

4.6 If Senex is legally required to process Customer Personal Data other than on Customer's instructions, Senex will inform Customer before doing so unless legally prohibited.

5. Customer responsibilities

5.1 Customer is responsible for the lawfulness of Customer Personal Data and Customer Content submitted to the Service, including ensuring that it has a lawful basis, notices, consents, permissions, and authority required to process that data and to instruct Senex to process it.

5.2 Customer is responsible for deciding whether Customer Content is suitable for upload to the Service. Senex does not review, classify, screen, or approve Customer Content for sensitivity, lawfulness, confidentiality, market-sensitivity, or regulatory suitability unless a specific feature is separately enabled and agreed.

5.3 Customer should not upload special category data, criminal-offence data, or other highly sensitive Personal Data unless Customer has confirmed that the upload is lawful, necessary, proportionate, and covered by appropriate safeguards.

5.4 Customer is responsible for managing its authorised users, access rights, account configuration, and internal use of answers or outputs generated by the Service.

5.5 Customer is responsible for assessing and authorising any Customer-enabled Third-Party Service that Customer chooses to enable, including any applicable international-transfer, confidentiality, regulatory, or procurement requirements.

6. Senex processor obligations

6.1 Senex will process Customer Personal Data only on Customer's documented instructions.

6.2 Senex will ensure that persons authorised to process Customer Personal Data are subject to confidentiality obligations.

6.3 Senex will implement and maintain appropriate technical and organisational measures designed to protect Customer Personal Data, as further described in Schedule 2.

6.4 Senex will provide reasonable assistance to Customer as described in sections 11, 12, 13, and 14.

6.5 Senex will maintain records reasonably necessary to demonstrate compliance with this DPA.

6.6 Senex may update its technical and organisational measures from time to time, provided that the updated measures do not materially reduce the overall protection of Customer Personal Data.

7. Confidentiality and personnel access

7.1 Senex will restrict access to Customer Personal Data to personnel who need access for operational reasons, including support, incident response, security, maintenance, and service administration.

7.2 Under normal operation, Senex personnel do not access Customer Content through the product interface.

7.3 If Customer requests support that requires Senex to access Customer Content, Senex will do so only as reasonably necessary to provide that support, and such access will be logged where practicable.

7.4 Behind-the-scenes infrastructure access is restricted to authorised personnel, logged where practicable, and subject to periodic review.

8. Sub-processors

8.1 Customer authorises Senex to use the Approved Sub-processors listed in Schedule 3 for the purposes described there.

8.2 Senex will not authorise a Sub-processor to process Customer Personal Data unless Senex has entered into a written agreement with that Sub-processor imposing data-protection obligations that are materially no less protective than those imposed on Senex under this DPA.

8.3 Senex remains responsible to Customer for the performance of its Sub-processors' data-protection obligations, subject to the liability limits in this DPA and the Agreement.

8.4 Senex may appoint a new or replacement Sub-processor by giving Customer at least 30 days' advance notice, unless shorter notice is reasonably necessary to maintain the security, availability, or continuity of the Service.

8.5 Customer may object to a new or replacement Sub-processor on reasonable data-protection grounds by notifying Senex within 15 days after receiving notice. The parties will work in good faith to resolve the objection.

8.6 If the parties cannot resolve the objection, Senex may suspend or avoid the affected processing, and Customer may terminate the affected Service to the extent the objected-to Sub-processor is necessary to provide it.

8.7 Senex will not use a non-Cloudflare artificial-intelligence model provider, non-Cloudflare document-conversion provider, or other Conditional Egress Provider to process Customer Personal Data unless Customer expressly authorises the specific provider and feature through an Order Form, written instruction, product setting, or amendment to this DPA that satisfies the versioned DPA-reference requirements in section 9.

8.8 For clarity, the optional providers listed in Schedule 4 are not Approved Sub-processors unless and until they are expressly added to Schedule 3 or otherwise authorised in accordance with this DPA.

8.9 Cloudflare is Senex's core infrastructure provider and the sole Approved Sub-processor for the Cloudflare-only default configuration. Senex configures Customer Content storage and other persistent data stores for European Union jurisdiction where supported by the relevant Cloudflare service and confirmed in Senex's technical configuration.

8.10 Cloudflare processing is subject to Cloudflare's Data Processing Addendum, applicable transfer safeguards, and service-specific data-localisation capabilities. Cloudflare edge compute, artificial-intelligence inference, vector search, queues, logs, analytics, operational metadata, support, and administrative processing may be subject to Cloudflare's global network, service-specific regional controls, and documented exceptions. Unless an Order Form expressly states otherwise, Senex does not represent that every Cloudflare processing operation, metadata item, log, inference operation, or vector-search operation occurs only in the European Union.

9. Customer-enabled Third-Party Services, BYOK Anthropic, and Conditional Egress Features

9.1 Customer may choose to enable a Customer-enabled Third-Party Service only where the feature is available, Senex has not disabled it for the relevant tenant or plan, and the enablement is permitted by the Agreement, this DPA, and any applicable Order Form.

9.2 For Anthropic bring-your-own-key (BYOK), Anthropic may be treated as a Customer-enabled Third-Party Service, rather than a Senex-appointed Approved Sub-processor, only where: (i) Customer supplies an application programming interface key tied to Customer's own Anthropic account; (ii) Customer has accepted Anthropic's applicable commercial and data-processing terms; (iii) Customer instructs Senex to transmit Customer Data to Anthropic for the BYOK feature; and (iv) Senex does not use a Senex-held platform key or independently appoint Anthropic for that processing. If any of those conditions is not satisfied, Anthropic should be treated as a Senex conditional Sub-processor and must be listed or authorised as such before use.

9.3 Before enabling BYOK Anthropic, Customer confirms that: (i) Customer has an active Anthropic account and has accepted Anthropic's applicable commercial and data-processing terms; (ii) Customer authorises Senex to transmit the relevant prompts, retrieved context, request metadata, and other Customer Data to Anthropic using Customer's application programming interface key; (iii) Customer has assessed and accepted the international-transfer consequences of that transmission, including any transfer to or access from the United States or other locations used by Anthropic; and (iv) Customer has put in place any transfer mechanism required for Customer's use case, including Standard Contractual Clauses, the United Kingdom International Data Transfer Addendum or International Data Transfer Agreement, Swiss transfer addendum, adequacy mechanism, or other lawful safeguard as applicable.

9.4 Senex's role for BYOK Anthropic is limited to transmitting the Customer-directed request through the Service, protecting the BYOK credential within Senex-controlled systems, applying Mosaic Theory AI's security controls to Senex-held records, and recording non-content usage or audit metadata. Senex is not responsible for Anthropic's processing under Customer's Anthropic account, except to the extent caused by Senex's breach of its own obligations.

9.5 BYOK Anthropic, Senex-platform Anthropic, Modal, OpenAI, Google artificial-intelligence services, and other non-Cloudflare artificial-intelligence or document-conversion providers are not approved for the Cloudflare-only default configuration unless separately authorised as described in this DPA.

9.6 Senex-appointed Conditional Egress Providers. Where Senex uses a Senex-held provider account, key, workspace, or infrastructure account to process Customer Personal Data through anthropic_platform, modal_ingest, or any similar optional provider leg, that provider is a Senex-appointed conditional Sub-processor for the authorised feature and not a Customer-enabled Third-Party Service.

9.7 Versioned consent gate. Senex must not enable a Conditional Egress Feature unless Customer has accepted the current Feature DPA Terms for that feature and Senex has recorded a non-empty DPA Reference, current DPA version string, matching disclosure hash, accepted-by user, accepted timestamp, organisation identifier, and terms route shown to the user. A stale version, stale hash, missing DPA Reference, placeholder page, or "terms coming soon" label is not valid consent and must fail closed.

9.8 Current conditional feature terms. The current Feature DPA Terms as of 7 July 2026 are:

9.9 Revocation. Customer may revoke a Conditional Egress Feature where the Service makes revocation available, or by written notice to Senex. Revocation prevents future egress for the relevant feature but does not automatically delete Customer Data already processed, outputs already returned, or records retained under this DPA, provider terms, law, security logs, backups, or audit requirements.

10. International transfers

10.1 Senex will not make a Restricted Transfer of Customer Personal Data unless the transfer is:

• disclosed in this DPA or the Agreement;
• required to provide the Service as configured or instructed by Customer;
• required by law; or
• otherwise authorised in writing by Customer.

10.2 Where a Restricted Transfer is required, Senex will use an appropriate transfer safeguard under applicable Data Protection Laws. Depending on the origin of the data and the applicable regime, this may include the United Kingdom International Data Transfer Agreement, the United Kingdom Addendum to the European Union Standard Contractual Clauses, the European Union Standard Contractual Clauses, an adequacy decision or adequacy regulation, a Swiss transfer addendum, or another legally recognised transfer safeguard.

10.3 The Cloudflare-only default configuration uses Cloudflare as the only Approved Sub-processor. Cloudflare's Data Processing Addendum, transfer safeguards, and service-specific data-localisation capabilities apply to Cloudflare processing. The Service does not rely on a blanket European-Union-only processing claim for all Cloudflare operations.

10.4 Any future non-Cloudflare artificial-intelligence or document-conversion processing must be separately disclosed and authorised under section 8 or section 9 and must be supported by appropriate transfer safeguards before processing begins.

11. Assistance with data-subject rights

11.1 Taking into account the nature of the processing and the information available to Senex, Senex will provide reasonable assistance to Customer in responding to requests by data subjects to exercise rights under applicable Data Protection Laws.

11.2 During the pilot and early production period, assistance with deletion, access, correction, and similar requests may be handled manually.

11.3 Customer is responsible for deciding how to respond to a data-subject request. Senex will not respond directly to a data subject unless instructed by Customer or required by law.

11.4 If Senex receives a request directly from a data subject relating to Customer Personal Data, Senex will, where legally permitted, refer the request to Customer.

12. Security assistance, impact assessments, and regulator consultations

12.1 Taking into account the nature of the processing and the information available to Senex, Senex will provide reasonable assistance to Customer with:

• security of processing;
• Personal Data Breach assessment and notification;
• data-protection impact assessments;
• prior consultation with supervisory authorities, where required; and
• reasonable requests for information about Senex's processing of Customer Personal Data.

12.2 Senex may satisfy assistance requests by providing existing security documentation, technical descriptions, audit-trail exports, responses to reasonable questionnaires, or other compliance evidence.

13. Personal Data Breach notification

13.1 Senex will notify Customer without undue delay and, in any event, within 72 hours after becoming aware of a Personal Data Breach affecting Customer Personal Data.

13.2 Senex's initial notification may be preliminary and may be provided before Senex has completed its investigation.

13.3 To the extent reasonably available, Senex's notification will include:

• a description of the nature of the Personal Data Breach;
• the categories and approximate number of affected data subjects and records, where known;
• the likely consequences of the Personal Data Breach, where known;
• the measures taken or proposed to address the Personal Data Breach;
• measures proposed to mitigate possible adverse effects; and
• a contact point for further information.

13.4 Senex will provide further information in phases without undue further delay as it becomes reasonably available.

13.5 A notification under this section is not an admission of fault, liability, or legal responsibility.

14. Audit and inspection

14.1 Senex will make available to Customer information reasonably necessary to demonstrate Senex's compliance with this DPA.

14.2 Customer may audit Senex's compliance with this DPA no more than once in any 12-month period, unless a Personal Data Breach or material suspected non-compliance reasonably justifies an additional audit.

14.3 Before requesting an on-site or live systems audit, Customer must first use reasonable alternatives such as security documentation, written responses, audit-trail exports, compliance evidence, and remote review.

14.4 Any audit must be conducted:

• on reasonable prior written notice of at least 30 days, except in urgent circumstances;
• during normal business hours;
• in a manner that does not unreasonably disrupt Senex's business or the Service;
• subject to confidentiality obligations;
• by personnel or auditors who are suitably qualified and not competitors of Senex; and
• at Customer's cost, unless the audit reveals material non-compliance by Senex.

14.5 Senex is not required to disclose information that would compromise the security of the Service, disclose another customer's data, disclose confidential third-party information, or disclose source code.

15. Return and deletion

15.1 On termination or expiry of the Agreement, or on Customer's valid written deletion request, Senex will delete or return Customer Personal Data in accordance with Customer's reasonable instructions, subject to this section.

15.2 On the end or non-renewal of the Agreement, or on a valid written request to delete all of Customer's data, Senex will delete Customer documents and the data derived from them - including extracted text, retrieval chunks, search-index data, cached answers, question history, and conversation message content - within 30 days, unless a longer retention period is required by law or expressly agreed. This obligation is subject to sections 15.4, 15.8, 15.9, 15.10, and 15.11, which state where deletion is presently incomplete or qualified. Senex will complete the deletion by manual operator action where the automated path does not yet reach a class.

15.3 Short-lived cached answers expire 24 hours after they are created and are deleted by a daily eviction job.

15.4 Audit and security logs are retained for at least 365 days in a retention-protected audit archive for the applicable retention period, as further described in Schedule 2, section 10. These records may contain Customer Personal Data and will be deleted after the applicable retention period, subject to legal, security, dispute-resolution, or compliance requirements.

15.5 Senex may retain limited business records, support records, deletion confirmations, billing records, and legal records as necessary for legal, accounting, dispute-resolution, security, and compliance purposes.

15.6 Where Customer's stored data is encrypted with a customer-specific encryption key - that is, the classes listed in Schedule 2, section 2.1, and only those - Senex may use cryptographic deletion by destroying the relevant customer-specific key, rendering the encrypted data unreadable. Cryptographic deletion is not available for, and Senex does not rely on it for, any class in Schedule 2, section 2.2 (which is not encrypted under that key and is held in readable form) or section 2.5 (third-party model credentials, which are held under a shared platform key that survives destruction of the customer-specific key). Those classes are erased by deleting the stored records. For the third-party model credentials in section 2.5, that record deletion is not performed by the default automated routine under section 15.2; it is performed on Customer's request, by Customer through the Service's settings interface, or by the manual operator action described in section 15.9.

15.7 Data in backups, archives, or immutable logs may not be deleted immediately if deletion is technically impracticable or would undermine security, integrity, legal compliance, or disaster recovery. In that case, Senex will protect the data from active processing and delete it according to the applicable deletion cycle or retention period.

15.8 Deletion of an individual document is narrower than section 15.2. Deleting one document removes the stored file, its extracted text, its retrieval chunks, its entries in the by-meaning search index (section 14.1), and the derived working records produced from it, such as its parsing, cleanup, and enrichment outputs, its extracted entities, and its tag associations. It does not remove everything associated with that document - in particular it does not remove the retained document record, or the classification and redaction details held on it, described below. The following are stated without limitation:

• Removal from the keyword (lexical) index described in section 14.2 is attempted, but is not guaranteed. That removal is best-effort: if it fails, the failure is logged, it is not retried, and the deletion is still reported as successful. The document's text would then remain in the keyword index - which holds it verbatim and in readable form - indefinitely. Senex does not represent that removal from the keyword index always succeeds, and Customer should not rely on it as a guarantee.
• The document's own database record is retained, marked as deleted, rather than removed. That retained record holds the document's filename and metadata derived from it, including any classification details and any record of redactions applied to it. Filenames of this kind are held in readable form, as stated in Schedule 2, section 2.2.
• Answer text previously generated from that document may also be held in a short-lived cached answer or in conversation message content. A cached answer expires as stated in section 15.3. Where the answer text is held in conversation message content, deleting the document replaces that answer with a fixed placeholder recording that the source was deleted; the conversation itself, including the question that prompted the answer, is not removed by deleting the document, and conversation message content expires automatically 90 days after it is created, as stated in Schedule 5.

Senex is working to close these gaps. In the meantime, Customer may request deletion of a conversation's content, and of a retained document record, by written request under section 15.1.

15.9 Automated deletion under section 15.2 is presently incomplete, and Senex discloses this rather than rely on section 15.7. The Service's automated full-deletion routine does not currently remove everything within the scope of section 15.2. The omissions known to Senex are the following, stated without limitation:

• the keyword (lexical) index described in section 14.2. Because that index holds the verbatim text of Customer's documents in readable form, an automated full deletion that ran without further action would leave a readable copy of Customer's document text in the database; and
• the stored third-party model credentials described in Schedule 2, section 2.5. The automated routine preserves the stored credential unless the operator expressly directs otherwise, so an automated full deletion that ran without further action would leave Customer's third-party credential in the database, encrypted under a platform key that survives destruction of the customer-specific key.

These are defects, not design choices, and Senex does not rely on them. Because the list above is stated without limitation, Senex does not represent that it is exhaustive. Until the automated routine is corrected, Senex will remove each of the items listed above by manual operator action as part of every deletion under section 15.2, and will confirm removal in the deletion confirmation provided to Customer. Customer may request written confirmation that these steps were performed.

15.10 Cloudflare D1 recovery history. When Senex deletes a record from an active Cloudflare D1 database, that record is removed from the normal application query surface. Cloudflare D1 Time Travel is a continuously enabled point-in-time recovery mechanism and may retain a restorable database history for up to 30 days on Workers Paid plans or 7 days on Workers Free plans. Senex cannot disable or shorten that platform window.

Senex will not use deleted records held only in Time Travel history for normal Service processing. If Senex restores a database during the applicable recovery window, Senex will reapply still-valid deletion instructions or validate them against an erasure record before returning the restored database to normal production use.

A deletion confirmation may therefore distinguish between deletion from active systems and expiry of the provider-managed recovery-history window.

15.11 Legacy retention-protected audit-record exception. A limited set of audit objects created before Senex completes the #2496 audit-data-minimisation remediation may contain limited customer-content-bearing fields, including a question prefix, a document filename, or a free-text material non-public-information override reason.

Those affected objects are stored in a Cloudflare R2 audit bucket subject to an age-based bucket-lock retention rule. While the applicable rule remains in force, the affected objects cannot be selectively overwritten or deleted through normal object operations. The fields identified above may therefore remain technically readable to specifically authorised personnel until the relevant retention period expires, even after the corresponding active Customer record has been deleted.

Senex will: (a) maintain a certificate or attestation identifying the affected objects and their applicable expiry information; (b) restrict access to security, legal, compliance, incident-response, or audit purposes; (c) not use the retained content for normal product functionality, model training, marketing, or feature generation; (d) prevent new content-bearing audit writes through the remediation controls; and (e) delete the objects or allow them to expire promptly when the applicable retention protection ends.

The latest affected retention horizon is currently expected to end during July 2027. This is a bounded legacy exception and does not authorise new customer-content fields in the audit archive. Senex may retire this paragraph once the affected-object certificate is closed and all listed objects have expired or been deleted.

A deletion confirmation issued while an affected audit object remains must identify the exception and may not state that all copies of the relevant content have already been erased.

16. Liability

16.1 This section is intended to allocate contractual risk between the parties to the maximum extent permitted by law. It does not exclude or limit liability to the extent that liability cannot legally be excluded or limited.

16.2 The liability cap in the Agreement applies to all claims arising out of or relating to this DPA, and any liability under this DPA counts toward, and does not increase, that cap.

16.3 If the Agreement does not contain a liability cap, Senex's total aggregate liability arising out of or relating to this DPA is limited to the fees actually paid by Customer to Senex under the Agreement in the 12 months preceding the event giving rise to liability.

16.4 If Customer is using the Service under a free pilot, free trial, unpaid proof of concept, or other no-fee arrangement, Senex's total aggregate liability arising out of or relating to this DPA is limited to £100.

16.5 Senex is not liable for indirect, incidental, special, consequential, exemplary, punitive, or loss-of-profit damages, or for loss of revenue, loss of goodwill, loss of anticipated savings, or loss of business opportunity, whether arising in contract, tort, breach of statutory duty, or otherwise.

16.6 This DPA does not create any standalone indemnity by Senex in favour of Customer unless expressly stated in the Agreement.

16.7 Each party remains responsible for regulatory fines or penalties imposed directly on that party, except to the extent recovery from the other party is required by applicable law or expressly agreed in the Agreement.

17. Governing law and jurisdiction

17.1 This DPA is governed by the same law as the Agreement.

17.2 If the Agreement does not specify a governing law, this DPA is governed by the laws of England and Wales.

17.3 The courts specified in the Agreement have jurisdiction over disputes relating to this DPA.

17.4 If the Agreement does not specify courts or jurisdiction, the courts of England and Wales have exclusive jurisdiction over disputes relating to this DPA, subject to any mandatory rights of data subjects or supervisory authorities under applicable Data Protection Laws.

18. Changes to this DPA

18.1 Senex may update this DPA from time to time to reflect changes in law, the Service, security measures, or sub-processing arrangements.

18.2 Senex will not materially reduce the protection of Customer Personal Data under this DPA without Customer's consent or a lawful basis to do so.

18.3 Changes to Approved Sub-processors are governed by section 8.

19. Survival

Sections intended by their nature to survive termination, including confidentiality, deletion and retention, audit evidence, liability, governing law, and any provisions relating to retained records, survive termination or expiry of the Agreement.

Schedule 1 - Processing details

1. Subject matter

Senex provides a cloud-hosted research-intelligence software service that allows Customer's authorised users to upload investment-research documents, convert and index those documents, ask natural-language questions about them, and receive AI-assisted, cited, source-linked answers.

2. Duration

For the term of the Agreement, including any pilot, trial, subscription, renewal, support, offboarding, retention, deletion, and legally required retention periods.

3. Nature and purpose of processing

Senex may perform the following processing operations:

• receiving and storing Customer documents;
• converting Word documents and PDFs into text;
• breaking text into sections and building keyword and semantic search indexes;
• generating query and document embeddings;
• searching Customer Content by keyword and meaning;
• retrieving relevant passages in response to authorised-user questions;
• generating answers with citations and source links;
• storing question-and-answer history;
• creating and retaining audit records;
• authenticating and authorising users;
• securing, monitoring, troubleshooting, and maintaining the Service;
• processing operational metadata such as tenant identifiers, document identifiers, job states, and scheduling state;
• responding to support requests; and
• deleting, exporting, or returning Customer Content as instructed.

The purpose of the processing is solely to provide, secure, maintain, support, and improve the Service for Customer.

4. Categories of data subjects

Customer Personal Data may relate to:

• Customer's authorised users, employees, contractors, advisers, and representatives;
• individuals mentioned in Customer documents or prompts;
• individuals appearing in investment-research material uploaded by Customer; and
• other individuals whose Personal Data Customer chooses to include in Customer Content.

5. Categories of Personal Data

Customer Personal Data may include:

• account, login, identity, work-email, organisation, and access-control data;
• document content uploaded by Customer;
• Personal Data included in prompts, questions, answers, citations, and histories;
• retrieved passages and request metadata;
• activity, audit, access, security, and system-event data tied to authorised users;
• support communications relating to Customer's use of the Service; and
• any other Personal Data Customer includes in free-form uploaded documents or questions.

6. Special categories of data

The Service is not designed to require special category data, criminal-offence data, or other highly sensitive Personal Data. Customer is responsible for ensuring that any such data uploaded to the Service is lawful, necessary, proportionate, and appropriately protected.

7. Frequency of processing

Continuous during the term of the Agreement and as otherwise required for retention, deletion, security, support, and legal compliance.

Schedule 2 - Technical and organisational measures

Senex will maintain technical and organisational measures appropriate to the nature of the Service, including the following.

1. Encryption in transit

Data moving between Customer and the Service is transmitted over encrypted connections using modern transport-layer security.

2. Encryption at rest

2.1 Encryption at rest under a customer-specific key is applied to the following, and only the following. This is a closed list. Senex applies AES-256 authenticated encryption in its own application layer before the data is written:

• In object storage: uploaded documents as supplied by Customer; the extracted text, parsed document forms, and retrieval chunks derived from them; and the cropped table and figure images extracted from them.
• In the database: the generated answer and its citations, confidence data, compliance flags, evidence extracts, and usage records, as held in the query-result store; and conversation message content - the questions and answers shown in a conversation - and conversation titles, as held in the conversation store.

Three exclusions are stated expressly, because a reader would otherwise expect them to fall within the list above:

• The retrieval chunks named above are encrypted in object storage only. A second copy of the same chunk text - verbatim, and complete - is held in the database as lexical search terms, and that copy is not encrypted under the customer-specific key. Encryption of the object-storage copy must not be read as encryption of the text itself. Section 2.2 states this.
• Page images are not encrypted under a customer-specific key. The full-page images the Service renders from Customer's documents are written to object storage in readable form. The cropped table and figure images named above are encrypted; the full-page renders are not. They are addressed in section 2.2.
• Audit-record contents are not within this closed list. Some are encrypted under the customer-specific key and some are written in readable form. Section 2.4 states which, and Senex does not average the two into a single claim.

Third-party model credentials Customer supplies are encrypted at rest, but not under a customer-specific key. They are addressed separately in section 2.5 and are not within this section.

2.2 Everything else Senex stores - whether in the database or in object storage - is not encrypted under a customer-specific key. It is protected by the infrastructure provider's service-managed encryption at rest, and by the separation measures in section 5, but it is readable to a party with access to the store. This includes, without limitation:

• the full text of Customer's documents, held as readable lexical search terms. A verbatim copy of every retrieval chunk is written to the database to support keyword search. Section 2.1 encrypts the copy of that chunk held in object storage; it does not encrypt this second copy. Customer should assume the complete text of every ingested document is present in the database in readable form;
• the full-page images the Service renders from Customer's documents, held in object storage in readable form;
• machine-generated transcriptions of tables and figures extracted from Customer's documents;
• the original and cleaned document text produced by document-cleanup and enrichment features;
• the Service's market-abuse (MNPI) classification details, which include verbatim excerpts of the passages flagged in Customer's documents - that is, an excerpt of the very text the classification exists to protect - together with their offsets and severity;
• records of redactions Customer's staff apply, including the free-text reason given for each;
• document metadata extracted from Customer's documents, such as title, author, and headings; and the section headings and speaker names carried on individual retrieval chunks;
• prompt templates Customer authors, and their full version history, including superseded prompt text;
• the entity names on Customer's own redaction and market-abuse deny-list;
• question text, as held in the query-result store and the question-history store;
• document filenames and other Customer-supplied labels, and any tag or entity descriptions;
• derived search-index data, as described in section 14; and
• operational metadata, such as identifiers, statuses, timestamps, and model names.

2.3 Senex is working to reduce the scope of section 2.2 - in particular the lexical search terms and question text. Until it does, section 2.2 is the governing statement and section 2.1 must not be read as extending to anything not expressly listed in it. Where the two are in tension, section 2.2 prevails.

2.4 Audit records. Senex does not represent that audit-record contents are encrypted under a customer-specific key. The position is mixed, and Senex states both parts rather than averaging them into a single claim. The following is stated without limitation:

• Encrypted on the normal path. The audit record written for each request to the Service is encrypted under the customer-specific key whenever that key loads successfully. It is written without that encryption, in readable form, whenever the key cannot be loaded - including the window between provisioning a new customer and the first successful load of that customer's key, and during infrastructure incidents that prevent the key from loading - so that the audit trail itself cannot be suppressed by an encryption-layer failure. Senex logs each occurrence.
• Written in readable form always, not only on failure. The audit records produced by the document-cleanup, segment-cleanup, and market-abuse (MNPI) override operations are written in readable form on the normal path. This is not a fallback and does not depend on any key failing to load. Those records include, without limitation, the filename of the document concerned and the free-text reason an operator supplied to justify an override.

Senex is correcting the second class. Until it does, Customer should assume that audit records for those operations are readable to a party with access to the audit store.

2.5 Third-party model credentials. Where Customer supplies its own credentials for a third-party model provider, Senex encrypts them at rest with AES-256 authenticated encryption under a Senex-managed platform key, not under the customer-specific key described in section 2.1. Three consequences follow, and Senex states them rather than leave them to be inferred:

• the same platform key protects the stored credentials of every customer, so the separate-key measure in section 3 and the cross-customer owner check in section 4 do not apply to this class;
• destroying the customer-specific key does not render these credentials unreadable , so the cryptographic-deletion route in section 15.6 is not available for them. They are erased only by deleting the stored record. That deletion is not part of the default automated routine under section 15.2, which preserves the stored credential unless the operator expressly directs otherwise. Senex deletes the record on Customer's request, Customer may delete it at any time through the Service's settings interface, and its removal forms part of the manual operator action described in section 15.9; and
• Customer may avoid this class entirely by not supplying its own third-party credentials, in which case none are stored.

3. Customer-specific encryption keys

For the data classes listed in section 2.1 - and only those - each customer has a separate encryption key. That customer-specific key is itself encrypted under a master key controlled by Senex. This measure does not apply to the third-party model credentials described in section 2.5, which are held under a Senex-managed platform key shared across customers, nor to any class in section 2.2, which is not under a Senex-controlled application key at all.

4. Cross-customer owner check

Data encrypted under a customer-specific key as described in section 2.1 carries a cryptographic owner check tied to the relevant customer. If the Service attempts to read one customer's data with another customer's key, the check fails and no data is returned. This owner check is not present on the third-party model credentials described in section 2.5: they carry no such marker, and the shared platform key would decrypt a credential record irrespective of which customer it was stored against. Separation for that class rests on the per-customer database and infrastructure boundary described in section 5, not on cryptography.

5. Tenant isolation

Customer data is separated by customer, including separate logical databases, separate search indexes, separate document storage, and separate application instances or bindings per customer.

6. Data-localisation configuration and service-specific limits

For the Cloudflare-only default configuration, Senex configures Customer Content storage, audit archives, and D1 control-plane data for European Union jurisdiction where supported by the relevant Cloudflare service and confirmed in Senex's technical configuration. Worker-log storage is also European Union-resident, but by a different mechanism, stated in section 6.1.

This does not mean all Cloudflare processing is European-Union-only. Cloudflare edge compute, artificial-intelligence inference, vector search, key-value storage, queues, Durable Object compute other than the European-Union-pinned consolidation-scheduler and parser-pool-scheduler Durable Objects (see section 15), analytics, operational metadata, support, and administrative processing may operate on Cloudflare's global network or under service-specific regional controls and documented exceptions.

6.1 Components restricted to the European Union. Senex states the complete list of components for which it holds a residency guarantee, rather than a general assurance. The following, and only the following, are restricted to the European Union. The first four are pinned by a Cloudflare jurisdiction binding. The fifth rests on a different mechanism, and Senex identifies it rather than let Customer assume a binding exists:

• object storage, comprising every bucket holding Customer documents, parsed forms, page images, and audit archives;
• the per-customer databases holding Customer's structured records;
• the document-parsing compute containers; and
• the consolidation-scheduler and parser-pool-scheduler Durable Objects (see section 15).

The fifth, evidenced differently:

• worker-log storage. This is not pinned by a Cloudflare jurisdiction binding, and no such binding exists for it - these logs are delivered by Cloudflare's log-export mechanism rather than written by the Service itself. Its European Union residency rests instead on the configuration of that log-export job, which is set to deliver to a European Union storage endpoint. The guarantee is real, but its basis is different, and Senex states that so Customer verifies the right thing.

6.2 Components with no European Union guarantee. This list is stated without limitation, and Senex does not represent that it is exhaustive. The following components are not restricted to the European Union:

• vector search (the by-meaning index described in section 14.1). Cloudflare exposes no jurisdiction control for this service, so its location is not merely unrestricted but is not reported to Senex at all. Vector embeddings are derived from Customer's documents;
• artificial-intelligence inference, including the embedding and query-reformulation models;
• edge compute. Request handling executes at the Cloudflare location nearest the requester, globally. This is structural to the platform and is not configurable;
• key-value storage, which is globally replicated and holds short-lived operational state: the authentication key cache, wrapped (encrypted) customer keys, the redacted-entity list, sub-processor authorisation state, configuration snapshots, and an upload-deduplication entry that includes the document's filename. It does not hold document text, retrieval chunks, or generated answers;
• queues, which carry job metadata and a pointer to the stored document, together with the document's filename. Queue messages do not carry the contents of the document; and
• a shared platform database holding authentication, platform, and audit metadata. It holds no Customer document content.

6.3 Senex does not offer, and Customer should not rely on, a blanket European Union data-residency commitment. The position Senex does state is this: Customer's source documents, audit logs, per-customer structured records, and the document-parsing compute layer are restricted to the European Union by Cloudflare jurisdiction bindings; vector embeddings, artificial-intelligence inference, and edge request-handling execute without a regional guarantee; and a limited volume of platform metadata, which does not include document content, resides in a database that is not jurisdiction-restricted.

7. Access control

Access to the Service requires authenticated login through a single-sign-on access layer. Unauthenticated requests are rejected at the edge.

8. Personnel access restrictions

Senex restricts access to Customer Personal Data to authorised personnel with operational need. Infrastructure access is logged where practicable and subject to review.

9. Support access

Senex personnel do not normally access Customer Content through the product. Any support access to Customer Content should be requested by Customer, limited to the support purpose, and logged where practicable.

10. Retention-protected audit archive

The Service maintains audit records of security-relevant and customer-relevant activity, including user questions, answer activity, retrieval activity, and key-management events where applicable. Senex stores audit objects in a Cloudflare R2 bucket covered by an age-based bucket-lock rule configured to prevent overwrite or deletion during the applicable retention period. Changes to that bucket-lock configuration are restricted to privileged administrative access and are subject to Senex change-control and evidence requirements.

This is a bucket-level, administratively controlled retention measure. It is not represented as per-object compliance-mode write-once-read-many storage, a cryptographic hash chain, or a cryptographic append-only ledger.

Audit objects receive Cloudflare infrastructure encryption at rest. Senex application-layer encryption applies where implemented, subject to the bounded legacy exception in section 15.11. The encryption position for audit-record contents is mixed, and it is stated in Schedule 2, section 2.4: some audit records are encrypted under the customer-specific key and some are written in readable form. Senex does not represent that audit-record contents are encrypted under a customer-specific key as a class.

11. Customer audit export

Customer can export its own audit trail to support internal reviews, compliance requests, or regulator-facing evidence without requiring Senex engineering involvement.

12. Secure software practices

Senex follows a controlled deployment process and scans software dependencies for known vulnerabilities.

13. Retention controls

Customer documents and derived content are deleted according to Schedule 5. Audit and security logs are retained for at least 365 days in a retention-protected audit archive for the applicable retention period, as described in section 10.

14. Technical scope note - derived search indexes

The Service maintains two distinct search indexes over Customer's documents, and they have different at-rest characteristics.

14.1 By-meaning (semantic) index. The Service stores mathematical representations of text for by-meaning search. These do not reproduce the source text directly. They are separated by customer and protected by the infrastructure provider's service-managed encryption. In the Cloudflare-only default configuration, semantic search-index infrastructure may operate under Cloudflare's global service model.

14.2 Keyword (lexical) index. The Service also stores a keyword index in the customer's database. Unlike the by-meaning index, this index contains the verbatim text of Customer's documents in readable form - it is not a mathematical transformation, and the source text can be read directly from it. It is written for every ingested document, whether or not Customer has enabled keyword search. It is separated by customer and protected by the infrastructure provider's service-managed encryption, and it is not protected by the customer-specific key described in section 2.1. Senex draws this to Customer's attention specifically because a reader could otherwise assume, from section 14.1 alone, that derived indexes do not hold readable document text. They do.

Neither index is protected by the same Senex customer-specific key used for the classes listed in section 2.1.

15. Operational metadata

Queues and scheduling components may process operational metadata such as tenant identifiers, document identifiers, job states, debounce timers, and scheduling state. The consolidation-scheduler and parser-pool-scheduler Durable Objects that hold this scheduling state are configured for the European Union jurisdiction (a Cloudflare jurisdiction-restricted Durable Object namespace), consistent with the European Union jurisdiction applied to Customer Content, audit-archive, and control-plane storage. Queue messages and scheduler state are not intended to contain raw Customer Content. Certain transient document-processing components may process Customer Content temporarily to provide conversion, parsing, or encryption functions, but are not intended to persist Customer Content.

16. Roadmap items not included in the standard Service

Unless expressly agreed in an Order Form or amendment, the standard Service does not include:

• customer-managed master keys;
• bring-your-own-key artificial-intelligence providers;
• customer-controlled infrastructure deployment; or
• automated customer self-service deletion for all data classes.

Schedule 3 - Approved Sub-processors

The following Sub-processors are approved for the Cloudflare-only default configuration as of the Effective Date.

No non-Cloudflare artificial-intelligence model provider or non-Cloudflare document-conversion provider is approved for the Cloudflare-only default configuration under this Schedule.

Schedule 4 - Optional or future providers not approved by default

The following providers are not Approved Sub-processors for the Cloudflare-only default configuration unless separately authorised under section 8 or section 9, added to Schedule 3, enabled by Customer, or expressly agreed in an Order Form or amendment.

Senex will not send Customer Personal Data to OpenAI or Google artificial-intelligence services unless Customer expressly authorises that provider through an Order Form, written instruction, product setting, or amendment to this DPA.

Schedule 5 - Retention and deletion

D1 recovery-history qualification: Deletion from an active D1 table is effective at the normal query surface, but the deleted state may remain recoverable through Cloudflare D1 Time Travel for up to 30 days on Workers Paid plans or 7 days on Workers Free plans. The recovery history is not used for normal processing and expires according to Cloudflare's platform window, subject to the restore control in section 15.10.

Signature blocks

This DPA may be incorporated into the Agreement by reference, accepted electronically, or signed. Where Customer accepts this DPA electronically, the accepting person represents that they are authorised to accept this DPA, give the processing instructions set out in it, and bind the Customer legal entity identified in the acceptance record.

Senex

Senex Intelligence Ltd
By: ______________________________
Name: ____________________________
Title: _____________________________
Date: _____________________________

Customer

[Customer legal name]
By: ______________________________
Name: ____________________________
Title: _____________________________
Date: _____________________________