Data Processing Agreement (DPA), ISMS Copilot Partner Embed

Effective Date: 2026-07-22.

This Data Processing Agreement (the "DPA") governs the processing of Personal Data in connection with the ISMS Copilot Partner Embed (the "Service"). It supplements the Partner Terms of Service and is a click-through agreement: it is entered into between the Partner accepting it (the entity that accepts these terms, identified in its ISMS Copilot partner account; the "Partner", Controller) and Better ISMS EURL (the entity operating ISMS Copilot; the "Processor", "ISMS Copilot", except that ISMS Copilot acts as an independent controller for its own usage and billing ledger under §7.2), whose contracting-entity and registered details are those stated in the partner account and any order documentation.

Scope. This DPA governs the Partner Embed program only, under which the Partner is the Controller of its end-users' personal data and ISMS Copilot is the Processor (save that ISMS Copilot is an independent controller for its own usage and billing ledger, §7.2). It is distinct from the DPA for the ISMS Copilot chat product, which governs personal data processed for ISMS Copilot's own direct users. In the embed, the Partner's end-users are the data subjects, and the disclosure duties toward those end-users sit with the Partner, save that ISMS Copilot retains its own controller transparency duty (Arts. 13 to 14 GDPR) for the §7.2 usage and billing ledger, discharged through the §6.4 end-user notice and ISMS Copilot's own privacy information.

0. Definitions

"Controller", "Processor", "Sub-processor", "Personal Data", "Processing", "Data Subject", "Personal Data Breach", and "Supervisory Authority" have the meanings given in the GDPR (Regulation (EU) 2016/679). "SCCs" means the Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914. "GDPR" means Regulation (EU) 2016/679. Where the Partner or its end-users are subject to the UK data-protection regime, the UK GDPR applies in parallel, and a UK restricted transfer (assessed by territorial scope and transfer role, not merely by the data subject's location) is covered by the UK International Data Transfer Addendum to the SCCs.

1. Roles and scope

1.1 The Partner is the Controller of the personal data of its end-users processed through the embed. ISMS Copilot is the Processor, acting only on the Partner's documented instructions (this DPA, the Service configuration, and the tier selected).

1.2 The AI model providers and infrastructure providers in the Sub-processor List are Sub-processors.

1.3 Subject matter: provision of an embeddable AI assistant. Duration: the term of the Partner subscription plus the retention periods in §7. Nature and purpose: processing end-user prompts to generate AI responses on GRC and information-security topics. Categories of data subjects: the Partner's end-users. Categories of personal data: whatever the end-user includes in prompts, plus a Partner-issued end-user identifier (sub) and usage metadata. By default the Partner must not send, and must instruct its end-users not to send, special-category data (Art. 9) or criminal-offence data (Art. 10). This prohibition is lifted only where the Partner has established a lawful condition, notified ISMS Copilot in writing, and the parties have agreed any addendum the relevant Sub-processor terms require. ISMS Copilot does not filter, detect, or specially handle Art. 9/10 data in prompts. As Processor, ISMS Copilot does not itself establish or rely on any Art. 9(2) / Art. 10 condition and has no independent lawful basis for such data; the Partner as Controller is solely responsible for establishing any condition and shall indemnify ISMS Copilot against third-party claims arising from Art. 9/10 data the Partner or its end-users introduce into prompts in breach of this §1.3.

2. Processor obligations (GDPR Art. 28(3))

ISMS Copilot shall:

(a) process the Personal Data only on the Partner's documented instructions, including with regard to transfers to a third country, unless required to do so by Union or Member State law to which ISMS Copilot is subject; in such a case ISMS Copilot shall inform the Partner of that legal requirement before processing, unless that law prohibits it on important grounds of public interest. ISMS Copilot shall immediately inform the Partner if, in its opinion, an instruction infringes the GDPR or other applicable data-protection law, in which case it may suspend the affected instruction until confirmed or withdrawn;

(b) ensure persons authorized to process are bound by confidentiality;

(c) implement the technical and organizational measures in §5 (Art. 32);

(d) respect the Sub-processor conditions in §3 (Art. 28(2) and (4));

(e) assist the Partner, taking into account the nature of processing, with data-subject-rights requests (§6) and with the Partner's Art. 32 to 36 obligations, including DPIA and prior-consultation support on request, limited to information within ISMS Copilot's possession as Processor;

(f) at the Partner's choice, delete or return all Personal Data it processes on the Partner's behalf at the end of provision, and delete existing copies, save that ISMS Copilot may retain Personal Data to the extent required by Union or Member State law, in which case §7.2 applies; ISMS Copilot shall not otherwise retain copies of the Personal Data it processes on the Partner's behalf, shall certify such deletion in writing on request, and shall instruct each Sub-processor to delete or return the Personal Data it processes on the Partner's behalf under the Art. 28(4) flow-down (§3.4). Retention by an AI model Sub-processor of certain content for its own trust-and-safety and legal-compliance purposes (for example the flagged-content and safety-score retention disclosed in the Sub-processor List) is that provider's own controller processing, determined by it and governed by its own terms and lawful basis; it is not Personal Data processed on the Partner's behalf under this DPA and is outside this deletion duty. The operative mechanism is §7. In V1 the return option is satisfied by the end-user data export in §6.2 plus the §7.3 usage export (not yet a full-dataset return format), and deletion by the §7.1 erasure executed on the Partner's documented offboarding instruction; an automated offboarding job and a full-dataset return format are on the roadmap (Annex II identifies them as planned, not yet built) and are not warranted as live automated controls. Erasure of a thread carrying confirmed-flagged moderation content is subject to the Annex II deletion-prevention safety control and is completed under the offboarding or legal-hold process, not by an unconditional automated delete;

(g) make available information necessary to demonstrate compliance and allow for and contribute to audits and inspections (§8);

(h) maintain a written record of all categories of processing carried out on behalf of the Partner in accordance with Art. 30(2) GDPR, and make it available to the Partner and to a Supervisory Authority on request.

3. Sub-processors

3.1 The Partner provides general authorization for the Sub-processors listed at the Partner Embed Sub-processor List as of the effective date.

3.2 Sub-processor changes and control-neutral routing.

Routing within the disclosed envelope (control-neutral: no advance notice, publication-only). The Partner's general authorization (§3.1) extends to ISMS Copilot routing or switching the AI processing of the Partner's traffic among the disclosed destinations in the Sub-processor List, namely the OpenRouter allowlist and its non-PRC underlying hosts, Anthropic, and Mistral (EU), and to moving a tier or cohort between those disclosed destinations over time, without advance notice, so long as the move does not materially weaken an applicable retention, training, publication, security, transfer, or jurisdiction control (see the assessment note and the material-control-change provision below). Such a control-neutral move within the disclosed envelope is control-neutral: no advance notice, publication-only, and is reflected in the Sub-processor List and the trust center. The fixed commitments that bound this routing freedom are that (a) end-user prompts are never routed to a PRC endpoint (the account-level ban on China-hosted inference and the code pin, §4.4 to §4.5), and (b) where the Partner has selected an EU / ADP path (Mistral, EU) for the model layer, that path stays EU and is not moved off the EU model provider. A control-neutral change is one that does not materially weaken the applicable retention, training, publication, security, transfer, or jurisdiction controls and does not expand the categories of Personal Data processed.

Assessment note (retention asymmetry, honestly stated). The premium pre-first-token fallback to Anthropic is a request-level failover disclosed at contract formation and is part of the accepted Service, not a later sub-processor change; Anthropic is an already-disclosed premium sub-processor named in the Sub-processor List. Anthropic's standard commercial retention is nonetheless higher than the zero-retention of the GLM-5.2 primary, so under a stricter reading a move that shifts processing from a zero-retention destination to Anthropic could be viewed as materially adverse. ISMS Copilot assesses the request-level fallback, and substitutions among already-disclosed destinations of equal-or-stronger control, as control-neutral on the basis that no new sub-processor is introduced, the categories of Personal Data are unchanged, the account-level controls, allowlist, PRC-blocklist, and transfer mechanisms are unchanged, and the ADP (Mistral, EU, zero-retention) path remains available to the Partner at any time as the stricter alternative. A sustained re-designation of an entire premium tier's primary from a zero-retention model to Anthropic's standard-retention path, by contrast, would weaken the retention control and is treated as a material control change requiring the 30-day advance notice and objection remedy below, not as control-neutral.

Changes that require advance notice. A genuinely new Sub-processor (one not already disclosed in the Sub-processor List) or a material control change (one that materially weakens the retention, training, publication, security, transfer, or jurisdiction controls, introduces a materially different transfer-risk posture, or expands the categories of Personal Data processed) triggers at least 30 days' advance notice via the partner console and the trust center, during which the Partner may object on reasonable data-protection grounds. Urgent-replacement exception. Where a replacement is necessary to address a security threat, a Sub-processor's cessation of service, or legal compulsion, ISMS Copilot may make the change on shorter notice, notifying the Partner promptly with reasons and, where feasible, before the replacement begins processing the Partner's traffic; the Partner retains the objection-and-termination remedy below in respect of the replacement Sub-processor. Objection and termination. If the Partner objects and the parties cannot resolve the objection in good faith within 30 days, the Partner may, as its sole remedy, terminate the affected tier or Service without penalty and without loss of prepaid but unused fees. Where the objected-to Sub-processor has not yet been appointed for the Partner's traffic (the ordinary case), ISMS Copilot shall not appoint it for that traffic. Where it has already been appointed under the urgent-replacement exception, ISMS Copilot shall, on a sustained objection, cease using it for the Partner's traffic and migrate that traffic to an alternative within a reasonable period, or, if no adequate alternative exists, the Partner may terminate as above; pending migration ISMS Copilot maintains the account-level safeguards (zero-retention, closed allowlist, Art. 28(4) flow-down) applicable to that Sub-processor. Objection to a control-neutral (publication-only) change. For a control-neutral change published without an advance notice period, the Partner may object at any time on reasonable data-protection grounds by contacting privacy@ismscopilot.com; the parties will work in good faith to resolve the objection, which may include making the ADP (Mistral, EU, zero-retention) path available for the affected processing, and where the objection cannot be resolved on reasonable data-protection grounds the Partner may terminate the affected tier or Service without penalty and without loss of prepaid but unused fees.

3.3 Tier-dependent sub-processing. The operative AI sub-processor depends on the Partner's tier (Sub-processor List). Changing tier changes the operative AI sub-processor; the Partner authorizes this by selecting the tier, and within a tier ISMS Copilot may route across the disclosed envelope on the control-neutral basis in §3.2.

On the Free, Starter and non-ADP economy tiers the model is z-ai/glm-4.7, served through OpenRouter, Inc. (US) and pinned in code to a closed non-PRC host subset (Cerebras Systems, Inc., United States; and Google Vertex, operated by Google LLC, United States or another non-PRC region), under the OpenRouter account-level controls (mandatory zero-retention, training-disallowed, publication-disallowed, closed allowlist, PRC-blocklist), so end-user prompts do not reach a PRC endpoint. This is the same routing posture as the ISMS Copilot chat product's Essential tier.

On the premium (Growth, Scale, Enterprise) non-ADP tiers the primary model is GLM-5.2, likewise an open-weights model of Chinese authorship, served through OpenRouter, Inc. (US) and pinned in code to a closed non-PRC host subset (Together AI, Inc.; Fireworks AI, Inc.; and DeepInfra, Inc., all United States) under the same OpenRouter account-level controls (mandatory zero-retention, training-disallowed, publication-disallowed, closed allowlist, PRC-blocklist), so premium end-user prompts likewise do not reach a PRC endpoint. Anthropic, PBC (United States) is retained as the pre-first-token fallback for the premium tiers (used, before any output token is streamed, where the primary is unavailable), under SCCs Module Three and Anthropic's standard commercial retention (no zero-retention: inputs and outputs ordinarily deleted up to ~30 days, safety-flagged content up to 2 years, safety-classification scores up to 7 years; no training). Mistral AI SAS (France, EU) remains the deeper circuit-breaker failover. Because the premium primary is now also a Chinese-authored open-weights model, the model-origin acknowledgment below applies to the premium tiers as well as the economy tiers.

Contractual acknowledgment (model origin). The economy tiers use an open-weights model of Chinese authorship (GLM-4.7) and the premium tiers use, as their primary model, a further open-weights model of Chinese authorship (GLM-5.2), each served only on a closed non-PRC host set (the pinned hosts above: Cerebras and Google Vertex for the economy model; Together AI, Fireworks AI, and DeepInfra for the premium model) selected by the providers' documented footprint and the account-level ban on China-hosted inference, not on an absolute per-request EU-region guarantee, under the disclosed controls; the model author does not receive end-user Personal Data when the weights are served on those hosts and is not, on that basis, a sub-processor of Personal Data. The Partner acknowledges this origin and hosting posture for both the economy and premium primary models; is responsible for assessing, and by selecting the economy or premium tier accepts responsibility for assessing, whether the routing is suitable for its own lawful basis, sector, and upstream obligations (some public-sector, health, defence, and enterprise contracts restrict Chinese-authored software); shall disclose the applicable data-path AI sub-processor, third country, and transfer mechanism in its own end-user notice as already required by §6.4; and shall not represent to end-users or third parties that the economy or premium model has no China-origin authorship. This acknowledgment is a Partner acknowledgment of a disclosed fact; it does not constitute a warranty by ISMS Copilot as to either model's provenance or the absence of any particular authorship beyond the hosting posture described, ISMS Copilot's only warranty being the reasonable-skill-and-care service warranty in ToS §2.1. Any indemnity for a Partner misrepresentation of the Service or its sub-processors runs under ToS §12.1. Because both the economy and premium primary models are Chinese-authored, a Partner that will not accept a Chinese-authored model on the data path cannot escape it merely by moving between the economy and premium tiers: its remedy is to select the ADP tier (Mistral, EU) (available on Growth and above, so a Free or Starter Partner takes a paid upgrade to reach it), to contract a US-hosted non-Chinese-authored model (the Anthropic path) as the primary in an order form, or, failing either, to terminate the affected tier without penalty. The Anthropic (US) provider is available on the premium tiers as the pre-first-token fallback but is not, by default, the primary.

3.4 Flow-down (Art. 28(4)). ISMS Copilot shall impose on each Sub-processor, by written contract, data-protection obligations that are the same as, or materially equivalent to and no less protective than, those set out in this DPA, in particular sufficient guarantees to implement appropriate technical and organisational measures and equivalent onward-transfer safeguards. Where a Sub-processor fails to fulfil those obligations, ISMS Copilot remains fully liable to the Partner for the performance of that Sub-processor's obligations.

4. International transfers

4.1 Better ISMS acts as data exporter for each transfer of Personal Data it makes directly to a Sub-processor established outside the EEA (the infrastructure sub-processors, OpenRouter, and Anthropic (the premium fallback)). Each such transfer relies on an appropriate Chapter V safeguard: ordinarily the SCCs, Module Three (processor to processor), completed in Annex III with the parties, categories of data, and safeguards, except where an adequacy basis applies (see below). For the onward legs reached only through OpenRouter (the economy GLM-4.7 hosts Cerebras and Google LLC / Vertex, and the premium GLM-5.2 hosts Together AI, Fireworks AI, and DeepInfra), OpenRouter, not Better ISMS, is the exporter under its own SCCs, and Better ISMS's guarantee is the Art. 28(4) flow-down (§3.4) plus the provider-layer safeguards in Annex III. The Partner-to-Better-ISMS link is intra-EEA where the Partner is EEA-established, and an inbound transfer into the EEA where the Partner is not; in neither case is it a Chapter V transfer out of the Union, so the Partner is not the data exporter of the outward legs. A UK restricted transfer is additionally covered by the UK International Data Transfer Addendum. The SCCs, where relied on, are incorporated into this DPA and prevail over any conflicting term.

OpenRouter's own executed SCCs for the Better-ISMS-to-OpenRouter leg are concluded on Module Two (controller-to-processor), reflecting OpenRouter's standard treatment of its customer as a controller, whereas the role-correct module for Better ISMS as a processor is Module Three. This module mismatch is carried as an acknowledged residual and does not reduce the data subject's protection, because Module Two binds the importer to the full controller-instructed processor obligation set (at least as onerous as Module Three) and Better ISMS separately holds the Partner's Art. 28(2) authorisation and flows down equivalent obligations under Art. 28(4). Better ISMS's position is to prefer Module Three where a provider offers it and to rely on OpenRouter's Module Two instrument for that leg meanwhile.

For AI inference reached through the OpenRouter aggregator the chain has two distinct links, which are not conflated: (i) the contractual chain, under which ISMS Copilot holds an executed DPA with OpenRouter that requires OpenRouter to bind each underlying model provider, by written agreement, to obligations no less protective than its own (Art. 28(4) flow-down) and to remain liable for those providers' acts and omissions (the Partner does not contract the underlying providers individually); and (ii) the Chapter V transfer mechanism for the onward leg to the underlying inference host, which sits at the underlying-provider layer, namely the SCCs for that provider, or, where the provider maintains EU-US Data Privacy Framework certification (Google Vertex, certified entity Google LLC), reliance on that certification as an adequacy basis (GDPR Art. 45) for the covered processing. This is distinct from, and additional to, the safeguard for the direct Better-ISMS-to-OpenRouter leg (which also leaves the EEA and relies on OpenRouter's own executed instrument, the Module Two residual in the paragraph above): both the direct leg and the onward host leg carry their own Chapter V basis. The Art. 28(4) flow-down is the contractual guarantee chain; it is not itself the Chapter V transfer mechanism.

4.2 For each non-EEA Sub-processor, ISMS Copilot has carried out a transfer impact assessment (TIA) and implemented supplementary technical and organisational measures where required, including the OpenRouter account-level zero-retention (no persistent retention beyond serving the request; transient in-memory caching only), training-disallowed, closed-allowlist, and PRC-blocklist controls as Schrems II-style supplementary measures, plus TLS 1.2+ in transit. Because OpenRouter does not pin the per-request inference region, the underlying-provider SCCs remain the operative transfer safeguard even for providers with an EU footprint. Where a provider's footprint in practice reaches a destination other than the assessed US footprint, ISMS Copilot extends this transfer impact assessment to that destination's laws and practices before relying on the routing. The TIA for the OpenRouter-mediated inference legs (Better ISMS to OpenRouter (US), onward to the economy GLM-4.7 hosts Cerebras (US) and Google LLC / Vertex, and to the premium GLM-5.2 hosts Together AI (US), Fireworks AI (US), and DeepInfra (US), whose documented footprint is US) is concluded for that US footprint: the SCCs plus supplementary measures provide an adequate level of protection, and the residual US-surveillance risk is assessed as low and acceptable, principally because zero-retention leaves no data at rest at the importer for a bulk-access request to reach and the content (GRC and information-security prompts plus a pseudonymous identifier) is of low foreign-intelligence value. The Anthropic premium fallback leg (Better ISMS to Anthropic (US), a direct transfer on SCCs Module Three) does not carry the zero-retention posture (Anthropic applies its standard commercial retention), so for that leg the TIA rests on the SCCs plus Anthropic's contractual no-training and limited-purpose retention, the same low foreign-intelligence value of GRC prompts, and the fallback-only (not primary, and pre-first-token) frequency of Anthropic's use; that leg is likewise assessed as low and acceptable on that basis. Transport encryption and zero-retention mitigate but do not eliminate an access risk while the data is being processed in clear text at the point of inference; the mitigation is real, not a claim of strict essential equivalence by technical measures alone. For Google LLC / Vertex the EU-US Data Privacy Framework (Art. 45 adequacy) is an additional basis where in force; the SCCs are an independent Art. 46 basis, so if the DPF adequacy decision were suspended the leg continues to rely on the SCCs as its Chapter V basis, subject to reassessing this transfer-impact assessment in light of the cause of the suspension. The DPF status is kept under a monthly monitoring commitment. The assessment is available to the Partner on request under §8.

4.3 The ADP tier (Mistral, EU) provides an EU inference path with no transfer of AI-model processing outside the EEA, available to Partners with data-residency constraints. Infrastructure and observability providers remain US-incorporated and process under SCCs (Sub-processor List), so ADP is EU for the model, moderation, and storage layers rather than literally EU end-to-end.

4.4 The economy (GLM) leg. Inference is pinned in code to a closed non-PRC host subset (Cerebras, US; Google Vertex, US or another non-PRC region; the region reflects the providers' documented footprint, not a per-request pin) under the OpenRouter account-level controls, with zero-retention (no persistent retention beyond serving the request; transient in-memory caching only), so there is no data-path transfer to the PRC; the economy inference leg (OpenRouter, Cerebras, Google; documented footprint US) is governed by the SCCs per §4.1 (Art. 28(4) flow-down) with a TIA per §4.2. The model author's own first-party PRC endpoint is excluded by both the code pin and the account-level PRC-blocklist. The model author (a PRC-domiciled entity) receives no Personal Data when the open weights are served on the non-PRC hosts, so it is not a sub-processor and there is no data-path transfer to the PRC. The residual is therefore a provenance question (open-weights software of PRC authorship, hosted in the US), not a transfer question; it is addressed by the §3.3 acknowledgment and the Partner's own sector assessment.

4.5 The premium (GLM-5.2) leg and the Anthropic fallback. On the premium tiers the primary inference is GLM-5.2, pinned in code to a closed non-PRC host subset (Together AI, Fireworks AI, DeepInfra; documented footprint US; the region reflects the providers' documented footprint, not a per-request pin) under the same OpenRouter account-level controls, with zero-retention (no persistent retention beyond serving the request; transient in-memory caching only), so, exactly as with the economy leg, there is no data-path transfer to the PRC and the model author (a PRC-domiciled entity) receives no Personal Data when the open weights are served on the non-PRC hosts. This premium GLM-5.2 inference leg (OpenRouter, Together AI, Fireworks AI, DeepInfra; documented footprint US) is governed by the SCCs per §4.1 (Art. 28(4) flow-down at the OpenRouter-to-host layer) and is covered by the concluded US-footprint transfer impact assessment in §4.2. The residual for the premium primary is likewise a provenance question (open-weights software of PRC authorship, hosted in the US), not a transfer question, addressed by the §3.3 acknowledgment. The Anthropic fallback (US) is a direct transfer for which Better ISMS is the exporter under SCCs Module Three; it operates under Anthropic's standard commercial retention (no zero-retention), so the zero-retention mitigation does not apply to that leg, and its TIA (§4.2) rests instead on the SCCs, Anthropic's contractual no-training and limited-purpose retention, the low foreign-intelligence value of GRC prompts, and its fallback-only, pre-first-token frequency of use.

5. Security measures (Art. 32)

Without limiting the Partner's own controls, ISMS Copilot maintains: end-user access gated by a Partner-signed HS256 token bound to a per-Partner secret (fail-closed; no token, no access); tenant isolation (data scoped per Partner and per end-user identifier); encryption in transit and at rest for stored end-user content; a service-role-only data layer (partner tables are not directly client-accessible); a per-reply cost bound and pool/workspace caps to limit abuse; an append-only usage ledger; moderation logging on identified traffic; regular backup; a documented incident-response process; and an operational kill switch. ISMS Copilot publishes its security documentation, and the SOC 2 Type II attestations of its infrastructure sub-processors (for example Supabase and AWS), at the trust center; Better ISMS's own certification programme (ISO/IEC 27001) is in progress. The binding technical and organizational measures are those set out in Annex II, confirmed against the live partner deployment.

6. Data-subject rights and end-user relationship

6.1 The Partner holds the end-user relationship and is first line for data-subject requests (access, erasure, portability, objection).

6.2 ISMS Copilot assists the Partner to fulfil requests: export of an end-user's partner_threads and partner_messages; erasure of that end-user's messages, threads, and moderation events; anonymization or pseudonymization of the partner_users row. Assistance is provided without undue delay and in any event within 10 days of a documented Partner request (or a shorter period where necessary to enable the Partner to meet a statutory Art. 12(3) deadline of which it has notified ISMS Copilot), unless a legal hold applies. Assistance that is reasonable in light of the nature of processing is provided at no charge; assistance that is excessive or manifestly unfounded in frequency or scope may be charged at ISMS Copilot's reasonable documented cost, notified in advance.

6.3 The Service does not carry out solely-automated decision-making producing legal or similarly significant effects within the meaning of Art. 22 GDPR, and ISMS Copilot makes no Art. 22 assessment on the Partner's behalf. The Partner shall not deploy the Service in a manner that produces such effects without carrying out its own Art. 22 assessment and implementing the required safeguards.

6.4 End-user disclosure. The Partner shall include in its own end-user privacy notice: that an AI assistant is provided by ISMS Copilot as processor; the applicable AI sub-processor, third country, and transfer mechanism by tier (§3.3); that ISMS Copilot retains a pseudonymised usage and billing record as an independent controller for statutory accounting periods (§7.2); and that responses are machine-generated and not legal or professional advice (ToS §2).

7. Retention and deletion (hybrid model)

7.1 On subscription end or offboarding, after a grace period of 30 days ISMS Copilot erases end-user partner_threads, partner_messages, and moderation_events, and deletes the partner_users row, except that where a field of that row is required for the §7.2 statutory ledger it is retained there as pseudonymised personal data under §7.2 rather than kept in the operational tables. Pseudonymisation is not deletion; only fields with a continuing legal basis are retained. In V1, partner offboarding erasure is not yet an automated job; it is executed as an operational process on the Partner's documented offboarding instruction, deleting partner_threads (with partner_messages removed by the ON DELETE CASCADE foreign key and the associated moderation_events cleared in the same process). A thread that carries confirmed-flagged moderation content is held by a deletion-prevention safety trigger and is erased under the offboarding or legal-hold process rather than by an unconditional delete. The automated offboarding job and configurable retention are on the roadmap; until built they are identified in Annex II as planned and are not represented as live automated controls.

7.2 ISMS Copilot retains the usage and billing ledger (partner_usage_events, partner_billing_periods) for 10 years to satisfy its own accounting and tax retention obligations under French law (Code de commerce Art. L123-22 and applicable tax law; the general tax floor is 6 years), acting for that purpose as an independent controller and not as the Partner's processor. Before the end of the §7.1 erasure process, all directly identifying end-user fields in the ledger are reduced to a referential-integrity-preserving hash. Because a hash that preserves referential integrity is pseudonymisation, not anonymisation (it remains Personal Data under Art. 4(5)), ISMS Copilot retains it on the Art. 6(1)(c) legal-obligation basis above rather than treating it as out of GDPR scope, and records that basis and the retention period in its Art. 30(1) record (the record it keeps as an independent controller for this processing, not the Art. 30(2) processor record it keeps on the Partner's behalf). The 10-year period justifies only the fields the accounting and tax obligation actually requires; granular operational telemetry in partner_usage_events that is not required for that obligation is kept only as long as necessary and on a shorter schedule, and where a directly identifying field can be irreversibly removed without breaking the statutory ledger it is deleted rather than hashed. ISMS Copilot does not rely on an anonymisation (out-of-scope) treatment of any hashed field: unless and until a field is evidenced as irreversible, it stays in GDPR scope on Art. 6(1)(c).

7.3 A final usage export is available on request within 30 days of termination.

8. Audit

ISMS Copilot makes available its security documentation, and the SOC 2 Type II attestations of its infrastructure sub-processors, via the trust center and, on the Partner's reasonable written request (ordinarily no more than once in any 12-month period, on 30 days' notice, under confidentiality, at the Partner's cost), contributes to and allows for audits and inspections conducted by the Partner or a mandated independent auditor. The frequency limit does not apply where an audit is required following a Personal Data Breach affecting Partner data or by a competent Supervisory Authority.

9. Breach notification

9.1 ISMS Copilot notifies the Partner without undue delay and in any event within 24 hours of becoming aware of a Personal Data Breach affecting Partner Personal Data.

9.2 The notification shall, to the extent known, describe the nature of the breach including the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed; and a contact point. Where the information cannot be provided at once, it may be provided in phases without further undue delay.

9.3 ISMS Copilot shall not notify data subjects or any Supervisory Authority on the Partner's behalf; the Partner remains responsible for its Art. 33/34 obligations as Controller.

10. Liability

10.1 Liability under this DPA is subject to the cap and exclusions in the Partner ToS (§9), which is the greater of (i) trailing-12-month fees or (ii) the EUR 500 floor (so the cap is never zero), and to the carve-outs below. As in ToS §9.1, the cap limits established liability only; it is not a liquidated sum or a payment promise, and no amount is owed absent a proven breach, damage, and causation.

10.2 The general exclusion of indirect or consequential loss and of reliance on AI output does not exclude or reduce liability for a Personal Data Breach or a breach of confidentiality. Such a breach is subject to a distinct sub-cap that is never lower than the general §10.1 cap; where an escalated figure is negotiated in an order form it is that figure, and where none is negotiated the sub-cap defaults to the §10.1 greater-of amount. The dol / faute lourde carve-outs (ToS §9.3) override any sub-cap.

10.3 Nothing in this DPA or the ToS limits either party's liability to a data subject under Art. 82 GDPR, or excludes liability that cannot be excluded by law. As between the parties, each party is liable for the share of any damage attributable to its own breach of this DPA or of the GDPR, and the party that has paid a data subject may recover from the other, under Art. 82(5), that other's part of the responsibility. Liability to the data subject under Art. 82(1) and (4) is uncapped; the Art. 82(5) inter-party contribution recourse between the parties is inside the §10.1 / ToS §9 cap, except that (i) where the contribution arises from a Personal Data Breach or breach of confidentiality it falls under the §10.2 breach sub-cap, and (ii) the dol / faute lourde carve-outs (ToS §9.3) override the cap in all cases.

10.4 The liability floor is the EUR 500 amount in ToS §9.1, aligned with ToS §9.1 to §9.2.

11. Governing law and precedence

This DPA is governed by French law. Disputes are subject to the exclusive jurisdiction of the competent French courts having jurisdiction over the Processor's registered seat, without prejudice to the governing law and forum required by the SCCs for matters within their scope. This DPA prevails over the ToS in respect of the processing of Personal Data; the ToS governs all other matters. Operative language: this DPA is provided in English as the authoritative version; a French Controller may request a French-prevailing version.

Annexes

Annexes I to III populate the party, processing, technical-measures, and sub-processor details for this DPA and support the Chapter V transfer instruments. The operative SCCs are not this click-through: for each direct non-EEA leg they are the instruments separately executed between Better ISMS and that Sub-processor (identified in Annex III); for the onward legs reached only through OpenRouter (the economy hosts Cerebras and Google LLC / Vertex, and the premium GLM-5.2 hosts Together AI, Fireworks AI, and DeepInfra) they are executed at the OpenRouter-to-provider layer, with Better ISMS relying on the Art. 28(4) flow-down (§4.1). Any UK Addendum rides on the same separately-executed instruments. Party-specific details are those captured at acceptance and in any order documentation; the technical measures are verified against the live partner deployment.

Annex I, parties and description of processing

A. Parties.

• Controller: the Partner, as identified in its ISMS Copilot partner account and any order documentation, including the Partner's data-protection contact and, where applicable, its DPO or Art. 27 representative.
• Processor: Better ISMS EURL (ISMS Copilot), represented by its gérant; registered details as stated in the order documentation; data-protection contact: privacy@ismscopilot.com.
• SCC roles for restricted transfers (§4.1). For the direct non-EEA transfers Better ISMS makes and contracts (the infrastructure sub-processors, OpenRouter, Anthropic (the premium fallback)), the data exporter is Better ISMS EURL and the importer is that sub-processor, on Module Three (processor-to-processor), except that OpenRouter's own executed instrument is on Module Two, carried as an acknowledged residual (§4.1). For the onward legs reached only through OpenRouter (the economy GLM-4.7 hosts Cerebras and Google LLC / Vertex, and the premium GLM-5.2 hosts Together AI, Fireworks AI, and DeepInfra), OpenRouter is the exporter and Better ISMS's guarantee is the Art. 28(4) flow-down. The Partner-to-Better-ISMS link is not a Chapter V transfer out of the Union (intra-EEA, or inbound to the EEA where the Partner is non-EEA), so the Partner is not the data exporter of the outward legs and Better ISMS is not a data importer under it.

B. Description of processing.

• Categories of data subjects: the Partner's end-users.
• Categories of personal data: end-user prompt content (free text, which may contain whatever the end-user enters); a Partner-issued end-user identifier (sub); thread, message, and usage metadata.
• Special-category / criminal-offence data: not permitted by default (§1.3); processed only under the §1.3 exception.
• Nature and purpose: provision of an embeddable AI assistant answering GRC and information-security questions, comprising processing prompts to generate AI responses, content moderation, and usage metering and billing.
• Frequency: continuous, for the duration of the subscription, per end-user interaction.
• Duration: the term of the Partner subscription plus the retention periods in §7 (operational data erased after the grace period; statutory ledger retained per §7.2).
• Sub-processor processing: as in Annex III.

C. Competent supervisory authority. The Controller's lead supervisory authority; where Better ISMS EURL acts as data exporter under the SCCs, the French CNIL is the exporter-side supervisory authority.

Annex II, technical and organizational measures (Art. 32 / SCC Annex II)

Drawn from the ISMS control set and the partner backend. The binding measures are those set out here and confirmed against the live partner deployment; a control identified as planned is not warranted as a live control until built.

• Access control and authentication. End-user access is gated by a Partner-signed HS256 token bound to a per-Partner secret (fail-closed: no valid token, no access). Tenant isolation scopes data per Partner and per end-user identifier. Row-Level Security, JWT validation, and route guards restrict data access; the partner data layer is service-role-only (partner tables are not directly client-accessible). Operators use MFA; service-role keys are treated as privileged access.
• Cryptography. TLS 1.2+ enforced on all communication paths; encryption at rest for stored end-user content (Supabase, EU region).
• Minimisation and masking in observability. The embed runs on the shared ISMS Copilot chat backend (labelled APP_MODE=partner / partner-embed) and inherits that backend's production Sentry configuration: sendDefaultPii: false and a beforeSend scrubber (control R-SEC-002) that redacts sensitive request headers and cookies and scrubs credentials (JWTs, API keys, bearer tokens) and sensitive keys from breadcrumbs, extra context, and exception message text before an event is transmitted. Sentry ingest is EU (Germany, ingest.de.sentry.io). No deliberate prompt or response logging; pseudonymous identifiers only in logs. A dedicated partner Sentry project is a planned later step; until then error telemetry shares the chat backend's Sentry project under the scrubbing above.
• Logging and monitoring. Structured logging; Sentry (EU ingest), Axiom, and security alerting; an append-only usage ledger; moderation events logged.
• Content moderation. All end-user prompts are screened via Mistral moderation (EU) on every tier, with moderation events recorded (audit-logging; non-blocking in V1).
• Availability, backup, and resilience. Supabase managed regular backup of the production database; restoration is not formally tested and is not warranted as a tested control. Multi-provider AI circuit-breaker failover; documented incident-response process; an operational kill switch.
• Abuse and capacity limits. Per-reply cost bound; pool and workspace caps; rate limiting; the tier allowance hard stop (HTTP 429).
• Secure development and change management. Secure-development lifecycle with test-first development and mandatory PR review; separation of development, test, and production environments; configuration as code; vulnerability management with Dependabot.
• Supplier management and onward transfers. Data-processing terms, SCCs, and the Art. 28(4) flow-down with each sub-processor (Annex III; §3.4, §4).
• Deletion. Retention and erasure per §7. In V1, erasure on offboarding is executed on the Partner's documented instruction (not an automated job), and partner_messages are removed by the ON DELETE CASCADE foreign key when a partner_thread is deleted; a deletion-prevention trigger blocks removal of a thread with confirmed-flagged content (handled under the offboarding or legal-hold process). An automated offboarding job and configurable retention are on the roadmap and are identified as planned until built; they are not warranted as live controls.

Annex III, sub-processor list (per-importer transfer basis)

The sub-processors are those disclosed in the Partner Embed Sub-processor List, incorporated here by reference. Per §4.1, Better ISMS is the data exporter for the direct legs below (the importers it contracts with); for the onward legs (the economy GLM-4.7 hosts Cerebras and Google LLC / Vertex, and the premium GLM-5.2 hosts Together AI, Fireworks AI, and DeepInfra, all reached only through OpenRouter) OpenRouter is the exporter and Better ISMS's guarantee is the Art. 28(4) flow-down.

Direct importers (Better ISMS = exporter; Module Three role-correct, except OpenRouter's own instrument, which is Module Two, carried as the §4.1 residual). Mistral AI SAS (France) appears in this table for completeness as an EU sub-processor with no Chapter V transfer (it is not a data importer of a restricted transfer).

Onward importers (OpenRouter's sub-processors, reached via the Art. 28(4) flow-down; OpenRouter, not Better ISMS, is the exporter for these legs).

Google Vertex DPF basis. The DPF-certified entity is Google LLC, whose certification is Active on the EU-US Data Privacy Framework participant list and covers Google LLC and its wholly-owned US subsidiaries, with Google Cloud Platform among the covered services, so Google Cloud / Vertex AI processing falls within Google LLC's DPF scope. Better ISMS does not rely on the DPF as the sole safeguard: SCCs (Module Three) are the primary and independent Art. 46 mechanism for Vertex, and the DPF is an additional Art. 45 adequacy layer where in force. If the DPF adequacy decision were suspended, the SCCs stand alone as the Chapter V basis, subject to reassessing the transfer-impact assessment (§4.2) in light of the cause of the suspension. The covered scope relied on is Vertex inference of end-user prompts on the pinned non-PRC, zero-retention host set (§4.4); the TIA conclusion is at §4.2.

• Economy- and premium-tier code pin: each GLM tier pins a closed non-PRC host subset (economy GLM-4.7: Cerebras, Google Vertex; premium GLM-5.2: Together AI, Fireworks AI, DeepInfra), layered on the account-level ban on China-hosted inference, with a zero-retention posture (no persistent retention beyond serving the request; transient in-memory caching only). The Anthropic premium fallback is a direct US leg outside this OpenRouter pin and outside its zero-retention posture (SCCs Module Three; standard commercial retention; no training).
• Not an end-user-data sub-processor: Stripe (partner billing only).

This Partner DPA is published by Better ISMS (ISMS Copilot) and is effective on Partner acceptance. Data-protection questions: privacy@ismscopilot.com.