Data Processing Agreement (DPA), ISMS Copilot API

Effective Date: 2026-07-26.

This Data Processing Agreement (the "DPA") governs the processing of Personal Data in connection with the ISMS Copilot API (the "Service"). It supplements the API Terms of Service and is a click-through agreement: it is entered into between the Customer accepting it (the entity that accepts these terms, identified in its ISMS Copilot API account; the "Customer", 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), a French company (European Union); data-protection contact: privacy@ismscopilot.com.

Scope. This DPA governs the ISMS Copilot API only, under which the Customer is the Controller of the personal data it sends in Requests 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 and the Partner Embed DPA. In the API, the individuals whose personal data the Customer includes in Requests are the data subjects, and the disclosure duties toward them sit with the Customer, save that ISMS Copilot retains its own controller transparency duty (Arts. 13 to 14 GDPR) for the §7.2 usage and billing ledger.

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. "Request Content" means the message content the Customer sends in a Request. "EU aliases" and "bare aliases" have the meanings in the Terms and §3. Where the Customer or its data subjects 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 Customer is the Controller of the personal data it includes in Request Content. ISMS Copilot is the Processor, acting only on the Customer's documented instructions (this DPA, the Service configuration, the API key used, and the model alias called).

1.2 ISMS Copilot is an independent controller for the billing and usage metadata it generates about the Customer's use of the API (token counts, cost, timestamps, model requested and served, status, and a key identifier), which it processes for metering, billing, fraud prevention, and its own statutory accounting and tax obligations (§7.2). It does not process that metadata on the Customer's behalf.

1.3 The AI model providers and the infrastructure providers that transit Request Content (Fly.io, Kong, OpenRouter and the pinned inference hosts) in the Sub-processor List are Sub-processors for Request Content. Supabase processes only API metadata (not Request Content). Sentry processes operational error telemetry and, when a provider error payload includes prompt fragments, may process Request Content on that path. Stripe processes only Customer billing data.

1.4 Subject matter: provision of an OpenAI-compatible AI API. Duration: the term of the Customer's use plus the retention periods in §7. Nature and purpose: processing Request Content to generate AI responses on GRC and information-security topics, with framework knowledge injected server-side. Categories of data subjects: the individuals whose personal data the Customer includes in Requests, together with, for the §7.2 ledger, the Customer's account administrators and API users. Categories of personal data: whatever the Customer includes in Request Content (free text), the model outputs generated in response, and the usage metadata in §1.2. By default the Customer must not send, and must instruct its own users not to send, special-category data (Art. 9) or criminal-offence data (Art. 10). This prohibition is lifted only where the Customer has established a lawful condition, notified ISMS Copilot in writing, and the parties have executed a written sensitive-data addendum expressly covering the relevant category, including any amendment the relevant Sub-processor's terms require (for example an OpenRouter sensitive-data amendment for the global-mode path). Absent all three, sending such data is a breach of these terms. ISMS Copilot does not filter, detect, or specially handle Art. 9/10 data in Requests. 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 Customer 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 Customer or its users introduce into Requests in breach of this §1.4.

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

ISMS Copilot shall:

(a) process the Request Content only on the Customer'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 Customer of that legal requirement before processing, unless that law prohibits it on important grounds of public interest. ISMS Copilot shall immediately inform the Customer 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 Customer, taking into account the nature of processing, with data-subject-rights requests (§6) and with the Customer's Art. 32 to 36 obligations, including DPIA and prior-consultation support on request, limited to information within ISMS Copilot's possession as Processor. Because ISMS Copilot does not store Request Content as a persistent customer record in its own API data layer (§7.1), most data-subject-rights assistance for Request Content is limited to confirming that non-retention; error diagnostics are treated as described in §7.1;

(f) at the Customer's choice, delete or return all Personal Data it processes on the Customer's behalf at the end of provision, and delete existing copies, save to the extent retention is required by Union or Member State law to which ISMS Copilot is subject (in which case it retains only what that law requires, for as long as it requires, and protects it). Because Request Content is not retained as a persistent customer record in ISMS Copilot's API data layer (§7.1), this duty is satisfied for that layer by non-retention of Request Content. ISMS Copilot shall instruct each Sub-processor to delete or return the Personal Data it processes on the Customer's behalf under the Art. 28(4) flow-down (§3.4), and shall confirm in writing on request the scope of that non-retention (API data layer; error diagnostics as described in §7.1). The §7.2 usage and billing ledger is ISMS Copilot's own independent-controller data (§1.2, §7.2), retained under statutory retention obligations; it is not Personal Data processed on the Customer's behalf and is not deleted on the Customer's processor instruction. Data-subject rights in respect of that ledger are handled under §6.5;

(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 Customer in accordance with Art. 30(2) GDPR, kept separately from the Art. 30(1) record ISMS Copilot maintains as an independent controller for the §7.2 ledger, and make it available to the Customer and to a Supervisory Authority on request.

3. Sub-processors

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

3.2 ISMS Copilot will give at least 30 days' notice of any intended addition or replacement of a Sub-processor for Request Content, via the account and the trust center; the Customer may object on reasonable data-protection grounds within that period. 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 Customer promptly with reasons and, where feasible, before the replacement begins processing the Customer's traffic; the Customer retains the objection-and-termination remedy below in respect of the replacement Sub-processor. If the Customer objects and the parties cannot resolve the objection in good faith within 30 days, the Customer may, as its sole remedy, terminate the affected Service without penalty and be refunded any unused prepaid balance. Where the objected-to Sub-processor has not yet been appointed for the Customer's traffic, 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 Customer's traffic and migrate that traffic to an alternative within a reasonable period, or, if no adequate alternative exists, the Customer may terminate as above.

3.3 Mode-dependent sub-processing. The operative AI sub-processor depends on the model alias the Customer calls (§3 of the Terms; Sub-processor List). Calling a -eu alias routes Request Content to Mistral AI in the EU with no transfer of AI-model processing outside the EEA. Calling a bare alias routes Request Content in global mode to z-ai/glm-5.2, served through OpenRouter, Inc. (US) and pinned in code to a closed three-host set (Together AI, Inc. and Fireworks AI, Inc., United States; and Inceptron AB, Sweden, EU), under the OpenRouter account-level controls (mandatory zero-retention, training-disallowed, publication-disallowed, closed allowlist, PRC-blocklist) and in-request zero-retention flags, so the Service is configured not to route Request Content to Z.AI or to another provider under PRC jurisdiction. This is a control based on the closed host pin, the account-level PRC-blocklist, and the providers' documented footprints; OpenRouter does not provide an absolute per-request physical-region attestation, so it is not an absolute physical-location guarantee. As an exceptional operational kill switch, ISMS Copilot may serve bare-alias Requests on the EU/Mistral path instead (ToS §3.2), which is a more protective destination. The Customer selects the mode per Request by the alias; the objection remedy in §3.2 on the global-mode path is, in practice, to use the -eu aliases or to leave.

Contractual acknowledgment (model origin). The global-mode model is an open-weights model of Chinese authorship (z-ai/glm-5.2), served only on the closed non-PRC three-host set above (two US, one EU) 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 Request Content when the weights are served on those hosts and is not, on that basis, a sub-processor of Personal Data. The Customer acknowledges this origin and hosting posture; is responsible for assessing, and by calling the bare aliases 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 reflect the applicable data-path sub-processor, third country, and transfer mechanism by mode where it discloses sub-processors to its own end-users; and shall not represent to end-users or third parties that the global-mode model has no China-origin authorship. This acknowledgment is a Customer acknowledgment of a disclosed fact; it does not constitute a warranty by ISMS Copilot as to the model's provenance beyond the hosting posture described, ISMS Copilot's only warranty being the reasonable-skill-and-care service warranty in ToS §2.1.

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 Customer for the performance of that Sub-processor's obligations. The Art. 28(4) flow-down is the contractual guarantee chain; it is not itself the Chapter V transfer mechanism (§4).

4. International transfers

4.1 In EU mode (-eu aliases) there is no transfer of AI-model processing outside the EEA: Request Content is processed by Mistral AI in the EU. The infrastructure and observability sub-processors (Sub-processor List) that support both modes are US-incorporated entities operating EU deployments; to the extent a US-incorporated entity can access EU-stored or EU-processed data, that access is treated as a restricted transfer and covered by the SCCs.

4.2 In global mode (bare aliases) Request Content is transferred to the United States. 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 and OpenRouter, Inc.). Each such direct transfer relies on the SCCs, with the module set per leg (Annex I, Annex III): Module Three (processor to processor) for legs that transit Request Content in the ordinary path (Fly.io, Kong); Module Two (controller to processor) for legs that process only ISMS Copilot's independent-controller data (Supabase); OpenRouter's executed instrument is Module Two (see §4.3); and Sentry is Module Three where an error path carries Request Content and Module Two for operational telemetry that does not. For the onward legs reached only through OpenRouter (Together AI, Fireworks AI, and Inceptron), OpenRouter, not Better ISMS, is the exporter under its own instrument, and Better ISMS's guarantee is the Art. 28(4) flow-down (§3.4) plus the provider-layer safeguards (§4.7). The Customer-to-Better-ISMS link is intra-EEA where the Customer is EEA-established, and an inbound transfer into the EEA where the Customer is not; in neither case is it a Chapter V transfer out of the Union, so the Customer is not the data exporter of the outward legs. A UK restricted transfer is additionally covered by the UK International Data Transfer Addendum.

4.3 First-hop SCC module. OpenRouter's own executed SCCs for the Better-ISMS-to-OpenRouter leg are concluded on Module Two (controller-to-processor), reflecting OpenRouter's standard customer instrument. Better ISMS acts as a processor of Request Content for the Customer and holds the Customer's Art. 28(2) authorisation and Art. 28(4) flow-down. Module Two binds OpenRouter to the controller-instructed processor obligation set under those SCCs.

4.4 No Data Privacy Framework anchor on the global-mode pin. Unlike the ISMS Copilot chat and Partner Embed economy paths, the API global-mode host pin includes no EU-US Data Privacy Framework-certified host and no EU-primary host (the DPF-certified and EU-primary hosts on the wider OpenRouter allowlist do not serve z-ai/glm-5.2). The global-mode transfer therefore rests entirely on the Article 46 SCCs plus the supplementary measures in §4.5, and not on any Article 45 adequacy basis. This is a narrower Chapter V footing than the chat and embed paths, and it is disclosed here rather than smoothed over.

4.5 Transfer risk and supplementary measures. For the non-EEA transfers, ISMS Copilot carries out a transfer impact assessment and implements supplementary technical, contractual, and organisational measures, including: the OpenRouter account-level zero-retention (no persistent retention beyond serving the Request; transient in-memory caching only), training-disallowed, publication-disallowed, closed-allowlist, and PRC-blocklist controls as Schrems II-style supplementary measures; the code-enforced closed three-host pin as the disclosure boundary; and TLS in transit. Because OpenRouter does not pin the per-request inference region, the underlying-provider SCCs remain the operative transfer safeguard even for the EU host in the pin. The measures reduce, but a request served in global mode requires cleartext at the aggregator and at the serving host to be processed, so transport and short-retention measures reduce rather than eliminate the exposure of content while it is being processed; the SCCs plus these measures are the safeguards relied upon, and a Customer requiring EU-only processing should use the -eu aliases. ISMS Copilot's own transfer assessment does not replace the Customer's own Art. 35 DPIA for its use case.

4.6 OpenRouter as a US processing surface. OpenRouter, Inc. is not treated as a mere pass-through router: it is a United States importer that first receives Request Content and that maintains its own US-region hosting and request-metadata surface, and it is assessed as a US transfer in its own right, distinct from the underlying hosts.

4.7 Onward hosts. For onward legs reached only through OpenRouter, OpenRouter is the exporter and is required to procure each host's transfer instrument under its onward-transfer obligation (SCC Clause 8.8). Better ISMS's Art. 28(4) flow-down is the same-obligations chain alongside that ground. Together AI and Fireworks AI publish DPAs relied upon through the OpenRouter chain, together with account-level and in-request zero-retention controls. Inceptron AB is established in Sweden (EU); the OpenRouter-to-Inceptron hop is intra-EEA. A Customer requiring EU-only AI-model processing should use the -eu aliases.

5. Security measures (Art. 32)

Without limiting the Customer's own controls, ISMS Copilot maintains: API access gated by a bearer key validated against a stored SHA-256 hash (fail-closed; no valid key, no access), with a paying-account gate and a prepaid-credit and per-key spending-limit gate; no persistent storage of Request Content or model outputs as customer records in its own API data layer; on error paths a provider error body may appear in operational logs or Sentry and may include prompt text (§7.1, Annex II); Sentry scrubs credential material from error telemetry; free-text prompt content is not guaranteed to be stripped; a service-role-only data layer for the API metadata tables (private.api_*), which are not directly client-accessible; encryption in transit (TLS) and encryption at rest for the metadata it does store; per-Request cost accounting and per-key spending limits to bound abuse; an append-only usage and credit-transaction ledger; edge rate limiting at the API gateway; a documented incident-response process; and an operational kill switch for global mode. ISMS Copilot publishes its security documentation at the trust center and references the SOC 2 Type II attestations held by its infrastructure sub-processors (for example Supabase and AWS), which are available on request subject to the relevant vendor's confidentiality restrictions. The binding technical and organizational measures are those set out in Annex II.

6. Data-subject rights and end-user relationship

6.1 The Customer holds the relationship with the individuals whose personal data it includes in Requests and is first line for data-subject requests (access, rectification, erasure, portability, objection).

6.2 ISMS Copilot assists the Customer to fulfil requests to the extent the nature of the API allows. Because ISMS Copilot does not retain Request Content or model outputs as persistent customer records in its own API data layer (§7.1), there is generally no stored Request Content for it to access, rectify, export, or erase; the assistance ISMS Copilot can provide as Processor is confirmation of that non-retention (error diagnostics as described in §7.1). Assistance is provided without undue delay and in any event within 10 days of a documented Customer request (or a shorter period where necessary to enable the Customer to meet a statutory Art. 12(3) deadline of which it has notified ISMS Copilot), unless a legal hold applies.

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 Customer's behalf. The Customer 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 Customer disclosure. Where the Customer surfaces the Service to natural persons, the Customer shall include in its own privacy information: that an AI service is provided by ISMS Copilot as processor; the applicable AI sub-processor, third country, and transfer mechanism by mode (§3.3, §4); that ISMS Copilot retains a usage and billing record as an independent controller on the purpose-specific legal bases and retention periods in §7.2; and that responses are machine-generated and not legal or professional advice (ToS §2).

6.5 ISMS Copilot's own controller processing (usage ledger). For the §7.2 usage and billing ledger, ISMS Copilot is an independent controller and owes its own Arts. 13 to 22 duties to the affected individuals (typically the Customer's account administrators and API users), which it discharges through its API privacy information. A data subject may exercise access, rectification, erasure, restriction, objection, and portability rights in respect of that ledger directly with ISMS Copilot at privacy@ismscopilot.com. Those rights are subject to the statutory accounting and tax retention obligations in §7.2 (records ISMS Copilot is legally required to keep are retained for the statutory period), and ISMS Copilot responds within the Art. 12(3) timeframe. This is separate from the Customer's own controller duties to its data subjects for Request Content.

7. Retention and deletion

7.1 Request Content and outputs. ISMS Copilot does not store Request Content or model outputs as persistent customer records in its own API data layer; its processing of Request Content for inference is transient. A provider error response can include prompt text; those payloads may appear in operational logs or Sentry. Sentry scrubs credential material from error telemetry. Free-text prompt content is not guaranteed to be stripped from logs or Sentry. Confirmation of non-retention under §2(f) covers the API data layer and does not claim that error diagnostics are free of Request Content. On the global-mode path, OpenRouter is configured for zero data retention on zero-retention endpoints (no persistent retention of Request Content beyond serving the Request; transient in-memory caching may occur during processing). On the EU-mode path, Mistral processes under its EU zero-retention posture. That non-retention of Request Content as a customer record is what satisfies the §2(f) deletion duty for the API data layer.

7.2 Usage and billing ledger (independent controller). ISMS Copilot processes the usage and billing metadata (in its private.api_* tables: token counts, cost, model requested and served, status, duration, timestamps, and a key identifier and account/organisation identifier) as an independent controller, and applies a purpose-specific legal basis and retention period to each category rather than a single blanket basis:

• Accounting and invoice records required by French commercial law: Art. 6(1)(c) (legal obligation), retained for ten years (Code de commerce Art. L123-22), limited to the fields the accounting obligation actually requires (the statutory basis and period attach only to those fields, not to the whole usage ledger).
• Tax records: Art. 6(1)(c) (legal obligation), retained for the applicable statutory tax period (generally six years, Livre des procédures fiscales Art. L102 B), limited to the required fields.
• Service metering and prepaid-credit accounting (drawing down the balance, showing usage): Art. 6(1)(b) where the individual is party to the API contract, otherwise Art. 6(1)(f); retained for as long as needed for metering, billing disputes, and service operation, and at least as long as any linked statutory accounting or tax record requires.
• Fraud and security telemetry: Art. 6(1)(f) (legitimate interest, with a documented balancing assessment); retained for as long as needed for security, fraud prevention, and abuse investigation.

Field-level minimisation applies: where a directly identifying field can be irreversibly removed without breaking a record ISMS Copilot is legally required to keep, it is deleted; where such a field must be preserved only for referential integrity of the statutory ledger, it is reduced to a referential-integrity-preserving hash. Because such a hash is pseudonymisation, not anonymisation (the data remains Personal Data under Art. 4(5)), it stays within GDPR scope on the basis above; ISMS Copilot does not treat any hashed field as out of scope. ISMS Copilot records each basis, category, and retention period in its Art. 30(1) record.

7.3 The API key hash itself is deleted on key revocation (a revoked key is rejected on the next Request); ledger rows referencing a key identifier survive per §7.2.

8. Audit

ISMS Copilot makes available its security documentation, and references the SOC 2 Type II attestations held by its infrastructure sub-processors (available on request subject to vendor confidentiality restrictions), via the trust center and, on the Customer's reasonable written request (ordinarily no more than once in any 12-month period, on 30 days' notice, under confidentiality, at the Customer's cost), contributes to and allows for audits and inspections conducted by the Customer or a mandated independent auditor. The frequency and cost limits do not apply, and a shorter notice period applies, where an audit is required following a Personal Data Breach affecting Customer data, on reasonable evidence of a material failure by ISMS Copilot to comply with this DPA, or by a competent Supervisory Authority; where an audit reveals such a material non-compliance, ISMS Copilot bears the reasonable costs of that audit.

9. Breach notification

9.1 ISMS Copilot notifies the Customer without undue delay and in any event within 24 hours of becoming aware of a Personal Data Breach affecting the Customer's 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 Customer's behalf; the Customer 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 API 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 apply to, and does not exclude or reduce, liability for a Personal Data Breach or a breach of confidentiality; such liability is recoverable subject only to the §10.1 cap. Where an order form negotiates a higher figure for Personal Data Breach or confidentiality liability, that higher figure applies. The dol / faute lourde carve-outs (ToS §9.2) override the cap in all cases.

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 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, to the extent such contribution may lawfully be limited, inside the §10.1 / ToS §9 cap, except that (i) where the contribution arises from a Personal Data Breach or breach of confidentiality the §10.2 treatment applies, and (ii) the dol / faute lourde carve-outs override the cap in all cases. Nothing in this clause reduces a party's Art. 82 responsibility corresponding to its own part in the processing.

11. Governing law and precedence

This DPA is governed by French law. Disputes are subject to the jurisdiction of the competent French courts; where both parties contract as commerçants, the competent Tribunal de commerce having jurisdiction over the Processor's registered seat (Art. 48 CPC), and otherwise the court designated by the ordinary rules of jurisdiction. This mirrors ToS §10.1 and is 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 (Together AI, Fireworks AI, Inceptron) OpenRouter procures each host's transfer instrument under its onward-transfer obligation (SCC Clause 8.8), and Better ISMS's Art. 28(4) flow-down sits alongside that chain (§4.7). Any UK Addendum rides on the same instruments. Party-specific details are those captured at acceptance and in any order documentation; the technical measures are those in Annex II.

Annex I, parties and description of processing

A. Parties.

• Controller: the Customer, as identified in its ISMS Copilot API account and any order documentation, including the Customer's data-protection contact and, where applicable, its DPO or Art. 27 representative.
• Processor: Better ISMS EURL (ISMS Copilot), a French company (European Union); data-protection contact: privacy@ismscopilot.com. ISMS Copilot's independent-controller processing of the §7.2 usage ledger is described in its API privacy information.
• SCC roles for restricted transfers (§4). For the direct non-EEA transfers Better ISMS makes and contracts, the data exporter is Better ISMS EURL and the importer is that sub-processor: Module Three for Fly.io and Kong (Request Content in transit/process); Module Two for Supabase (independent-controller metadata only); OpenRouter Module Two per the executed instrument (§4.3); Sentry Module Three where an error path carries Request Content, otherwise Module Two for operational telemetry. For the onward legs reached only through OpenRouter (Together AI, Fireworks AI, Inceptron), OpenRouter is the exporter. The Customer-to-Better-ISMS link is not a Chapter V transfer out of the Union (intra-EEA, or inbound to the EEA where the Customer is non-EEA).

B. Description of processing.

• Categories of data subjects: the individuals whose personal data the Customer includes in Request Content; and, for the §7.2 ledger, the Customer's account administrators and API users.
• Categories of personal data (Request Content record, processor): Request Content free text, which may contain whatever the Customer enters, and the model outputs generated in response.
• Categories of personal data (usage-ledger record, independent controller): token counts, cost, model requested and served, status, duration, timestamps, a key identifier, and an account/organisation identifier.
• Special-category / criminal-offence data: not permitted by default (§1.4); processed only under the §1.4 exception.
• Nature and purpose: provision of an OpenAI-compatible AI API answering GRC and information-security questions, comprising processing Request Content to generate AI responses with server-side framework-knowledge injection, and usage metering and billing.
• Frequency: continuous, for the duration of the Customer's use, per Request.
• Duration: Request Content is not persistently stored (§7.1); the statutory ledger is retained per §7.2.
• Sub-processor processing: as in Annex III.

C. Competent supervisory authority. The Customer'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 API backend. The binding measures are those set out here.

• Access control and authentication. API access is gated by a bearer key validated against a stored SHA-256 hash (fail-closed: no valid key, no access), a paying-account gate, and a prepaid-credit and per-key spending-limit gate. The plaintext key is shown once at creation and is not recoverable. The API metadata layer is service-role-only (the private.api_* tables are not directly client-accessible). Service-role keys are treated as privileged access.
• Cryptography. TLS enforced on all communication paths; encryption at rest for the metadata stored (Supabase, EU region).
• Data minimisation. No persistent storage of Request Content or model outputs as customer records (§7.1); usage metadata only. The injected framework knowledge is Better ISMS content.
• Logging and monitoring. Structured operational logging; Sentry error monitoring; an append-only usage and credit-transaction ledger. Provider error payloads may appear in logs or Sentry and may include prompt text. Sentry scrubs credential material from error telemetry; free-text prompt content is not guaranteed to be stripped (§7.1).
• Availability and resilience. Managed database with automated backup; a documented incident-response process; the global-mode kill switch (reverting bare aliases to the EU/Mistral path).
• Abuse and capacity limits. Per-Request cost accounting; per-key daily/weekly/monthly spending limits; edge rate limiting at the API gateway; prepaid-balance hard stop.
• Secure development and change management. Secure-development lifecycle with mandatory PR review; separation of development, test, and production environments; configuration as code; dependency vulnerability management.
• 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); OpenRouter account-level and in-request zero-retention controls for the global-mode path.
• Testing and evaluation (Art. 32(1)(d)). Security review, dependency and configuration monitoring, and verification of access and provider-pin controls.
• Deletion. Non-retention of Request Content as customer records per §7.1; statutory-ledger retention and pseudonymisation per §7.2; API-key hash deletion on revocation.

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

The sub-processors are those disclosed in the API Sub-processor List, incorporated here by reference. Per §4, Better ISMS is the data exporter for the direct legs below; for the onward legs (Together AI, Fireworks AI, Inceptron, 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).

Onward importers (OpenRouter's sub-processors; OpenRouter is the exporter). No host in this pin is EU-US Data Privacy Framework-certified (§4.4).

• Global-mode code pin: closed three-host set above, code-enforced, never widened without a fresh sub-processor notice; account-level and in-request zero-retention; ban on China-hosted inference.
• Not a Request Content sub-processor: Stripe (Customer billing / credit top-up only).

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