Terug naar Trust Center
Alleen in het Engels beschikbaar. Dit juridische document wordt in het Engels als gezaghebbende versie verstrekt. De interface van het Trust Center is vertaald naar uw taal.

2026-10-13: PostHog removed (sub-processor removal)

Documents touched: DPA §2.4 sub-processor table and Appendix B (Effective Date 2026-10-13); privacy policy (automatically collected data and analytics wording, analytics and monitoring providers, analytics retention, categories of third parties, analytics cookies; Effective Date 2026-10-13); RoPA (Activity #6 data categories, processors, retention and security measures, transfer tables, sub-processor table; Effective Date 2026-10-13); cookie policy (analytics sentence; Effective Date 2026-10-13); the sub-processor list on the Trust Center and its machine-readable summary (llms.txt).

  • What changed. ISMS Copilot no longer uses product analytics. PostHog (EU, Frankfurt) is no longer a sub-processor, and no replacement sub-processor is added. Error monitoring (Sentry, Germany) and cookieless, aggregate web analytics (Vercel) are unchanged. We do not set analytics cookies.
  • Classification. Sub-processor removal: publication-only notice under DPA §2.4. No new processing, sub-processor, category of personal data or transfer. Questions: privacy@ismscopilot.com.

2026-10-08: Axiom added for log storage (EU, 30 days)

Documents touched: DPA §2.4 and Appendix B (Effective Date 2026-10-08); RoPA (monitoring processors and retention); privacy policy (service providers); the sub-processor list on the Trust Center home page; the Aevral, API and embed sub-processor lists.

  • What changed. Application logs of our production services hosted on Fly.io (chat, API, embed, heyGRC and Aevral) are now copied to Axiom, Inc. and kept for 30 days in the EU (Frankfurt), so we can investigate security events beyond the few days the hosting provider keeps them. The logs hold pseudonymous identifiers and technical metadata, not chat or document content. Axiom's AI features are turned off for our account.
  • Classification. Control-neutral sub-processor addition under DPA §2.4: no new category of personal data, storage in the EU, retention within the log retention already published, and the same transfer mechanism (SCCs) as our existing error monitoring provider. Questions or objections: privacy@ismscopilot.com.

2026-10-08: What "zero retention" means under Advanced Data Protection (clarification, facts unchanged)

Documents touched: DPA Definitions ("Advanced Data Protection Mode"); privacy policy (AI Processing); RoPA (AI routing table note); the Data Residency section of the Trust Center home page (all languages); llms.txt. Effective Dates stay 2026-10-07.

  • What changed. Under Advanced Data Protection, zero retention refers to the AI provider: Mistral keeps no copy of your requests. The pages now also say that ISMS Copilot still stores your conversations in its own database according to your retention setting (minimum 1 day; in the DPA, privacy policy and RoPA, also that memories, workspace instructions and text extracted from files are not covered by that setting), and that deleted conversations can remain in our encrypted database backups for up to 90 days, as DPA §2.8 already states.
  • Classification. Editorial clarification. No change to processing, sub-processors, retention or transfers. Published per DPA §7.2.

2026-10-07: Connected AI tools section (privacy policy)

Documents touched: privacy policy (new "AI Tools Connected to Your Account (Account MCP)" section, new "Connected AI Tool Retention (Account MCP)" subsection, After Account Deletion line; Effective Date 2026-10-07).

  • What changed. The privacy policy now describes what happens when you connect an AI tool (for example Claude or ChatGPT) to your ISMS Copilot account by OAuth sign-in or a personal access token: what the tool receives at your instruction, the connection records and tool-call log we keep, legal basis, where they are processed, how long they are kept, how to disconnect, and that the tool's provider handles what you share with it under your own agreement with that provider.
  • Classification. Non-material clarification. No change to processing, sub-processors or transfers. Published with a new Effective Date, per DPA §7.2.

2026-10-07: Database backup wording (editorial, facts unchanged)

Documents touched: DPA §2.3, §3.1 and Appendix B (Effective Date updated to 2026-10-07); privacy policy (database and storage, heyGRC GitHub App transfer note, Advanced Data Protection transfers list; Effective Date 2026-10-07); RoPA (GitHub Actions row; Effective Date 2026-10-07); the 2026-10-02 entry of this change log.

  • What changed. Wording edited on 7 October 2026; the facts are unchanged. The database backup job continues to run on GitHub Actions, and the text no longer refers to moving it. The heyGRC GitHub App note in the privacy policy now states that GitHub Actions, used for the database backup job, is a separately listed sub-processor.
  • Classification. Editorial. No change to processing, sub-processors, retention or transfers. Published with a new Effective Date, per DPA §7.2.

2026-10-04: United States state privacy law terms (DPA §10; privacy policy US-state sections)

Documents touched: DPA (new §10, United States State Privacy Laws; Effective Date updated to 2026-10-04), privacy policy (California section intro paragraphs, sensitive-PI credential exception, new "Other US State Privacy Laws" subsection, notice section aligned with DPA §7.2, merge markers resolved, Effective Date 2026-10-04).

  • What changed. The DPA gains §10: for personal data a Customer entrusts to ISMS Copilot for processing on its behalf, ISMS Copilot acts as a service provider under the CCPA/CPRA and as a processor under the other Applicable US State Privacy Laws, and the section carries the statutory contract requirements: limited and specified purposes on documented instructions only, no sale or sharing, no retention, use or disclosure outside the direct business relationship (with the §2.1 safety and legal disclosures preserved), no independent use including no development, training or improvement of any AI model, combining only as the law expressly permits, compliance with all applicable CCPA provisions and regulations, notification and a right to stop and remediate, audit rights (§2.9), consumer-request and assessment assistance (§2.5, §2.7), deletion or return (§2.8; Aevral's 12-month post-uninstall retention per §1.7 unchanged), the same level of privacy protection with sub-processor flow-down (§2.4), breach notice per §2.6, and a certification of understanding. §10 states that sale or sharing opt-out signals (including the Global Privacy Control) do not change the processing because there is no sale or sharing. The privacy policy's California section now covers account data for all Better ISMS products (ISMS Copilot, heyGRC, Aevral), states the service-provider role for content customers authorize our products to process (API request content stays under the separate API DPA), keeps the voluntary extension of California rights regardless of thresholds, discloses the one CCPA sensitive-PI category we collect (account login credentials, for authentication only), and adds a subsection for other US state privacy laws with the processor position and appeal information. The privacy policy's notice section now distinguishes material changes (30 days email and in-app notice) from non-material protective changes (publication with a new Effective Date), matching DPA §7.2.
  • Why. US buyers, including Aevral customers, need the state-law service-provider terms in the vendor contract during procurement review, and the public privacy policy needed to say the same position.
  • Classification. The DPA section 10 and US-state additions are non-materially-adverse and protective. The privacy policy's notice section is restructured to match DPA §7.2 (material changes keep 30 days email and in-app notice; non-material protective changes are published with a new Effective Date); that restructure is the one part that is not purely additive. Notice for this package: Trust Center, Trust Center change log, in-app product changelogs, new Effective Dates, per DPA §7.2. No change to processing, sub-processors, retention or transfers.
  • Questions. privacy@ismscopilot.com.

2026-10-01: API isms-mini runs in global mode, and the API pages name GLM 5.3 (correction)

Documents touched: API Terms §0, §3.1, §3.2 and §5, API DPA §3.3, §4.2, §4.4 and Annex III, API Sub-processors (processing modes, AI model table, global-mode sections).

  • What was wrong. Since 1 September 2026 the isms-mini alias has been served by z-ai/glm-5.3-flash through OpenRouter, Inc. (United States), on the same closed host set as the global aliases (Together AI, US; Fireworks AI, US; Inceptron AB, Sweden), with zero retention and no training. Until today these pages still described isms-mini as EU mode on Mistral Small with no transfer outside the EEA. They also still named z-ai/glm-5.2 for the global aliases, which have served z-ai/glm-5.3 since the same date.
  • What the pages say now. isms-mini is a global-mode alias: a Chapter V transfer to the United States, with OpenRouter as the first importer, on Article 46 SCCs plus the supplementary measures already listed for global mode, and no Data Privacy Framework reliance. The global aliases name z-ai/glm-5.3. The EU aliases (isms-fast-eu, isms-thinking-eu) are unchanged: Mistral-hosted GLM 5.3 (zai-glm-5-3) in the EU, now served (the transitional "replacing glm-5-2" wording is removed). The pages also now say plainly that the -eu aliases currently serve a model of Chinese authorship. API Terms §0 now defines the bare aliases as isms-fast and isms-thinking, so the global-mode kill switch (API Terms §3.2) does not reach isms-mini.
  • Correction to the earlier entry. The 2026-10-01 EU-aliases entry below described isms-mini as unaffected; it had already moved to global mode on 1 September 2026.
  • No new sub-processor. OpenRouter, Together AI, Fireworks AI and Inceptron were already on the API sub-processor list for global mode. For isms-mini traffic, however, they replaced Mistral, which is a change that materially affects data handling (API Terms §1.2, API DPA §3.2).
  • Processing in the EU. To keep this kind of request in the EU, call isms-fast-eu or isms-thinking-eu instead of isms-mini. If you have questions about this change, contact privacy@ismscopilot.com..

2026-10-01: heyGRC named in the Terms; Google Drive Open with and daily checks; Google Limited Use wording

Documents touched: Terms §1(i), new §7(vii); privacy policy (Who This Is For, Optional Integrations, Google User Data); DPA §2.4 Customer-Activated table, Appendix B; RoPA (Google LLC row).

  • heyGRC in the Terms. The Terms now name heyGRC (the GitHub App, the console and its optional Google Drive connection) among the Services, and §7(vii) describes the optional Google Drive connection.
  • Open with. The organization owner or admin who connected Google Drive may turn on Open with, so files can be opened with heyGRC from Google Drive as well as picked in Google's file picker. It adds Google's drive.install permission, which only places heyGRC in Drive's Open with menu and gives no access to any file. File access stays per file (drive.file).
  • Daily checks. heyGRC checks linked Drive files once a day and re-reads only the ones that changed (previously re-read weekly). A file that keeps changing is checked less often, down to once a week.
  • Google user data. The privacy policy now carries both Google Limited Use statements (Google API Services User Data Policy and Google Workspace scopes), says who can connect, what is accessed and stored, and states that Google user data is not used to create, train or improve any AI model, generalized or personalized.
  • Why control-neutral. Same sub-processor (Google LLC), same file-access scope, same jurisdiction, transfer mechanism and retention. Google Drive remains a Customer-Activated Integration, so the 30-day advance-notice rule in DPA §2.4 does not apply.

2026-10-01: heyGRC GitHub App: product-specific processing, routing, recipients and retention

Documents touched: PRIVACY-POLICY.md (new "Pull-Request Review Data" category, heyGRC routing paragraph, GitHub under Optional Integrations, "Pull-Request Review Retention", heyGRC EU inference under EU-Only Processing Options, effective date), TERMS-OF-SERVICE.md (§1(i) Services and product-specific precedence, §1(ii), §1(iii), §6(i), §7 preamble, new §3(iv) and §7(vi), archive note, effective date), DATA-PROCESSING-AGREEMENT.md (§1.1, §1.2, §1.5, §1.6, §2.4, §2.8, Appendix A/B, effective date), REGISTER-OF-PROCESSING-ACTIVITIES.md (new Activity #13; GitHub row; Mistral purpose; effective date).

  • What this revision adds. Product-specific descriptions for the heyGRC GitHub App (pull-request compliance review, launched July 2026): what is sent to the model, the default and EU inference paths (both serving open-weights models developed by Z.AI, which hosts neither path and receives no data), /heygrc replies, GitHub as the Customer's own platform, and review retention with a 30-day post-uninstall deletion window.
  • GitHub. A customer-activated integration and a Customer-directed platform, not an ISMS Copilot sub-processor (no 30-day pre-notice; customer-side activation).
  • Mistral AI. Purpose extended to heyGRC EU inference (organization opt-in; existing sub-processor, no new engagement).
  • Why no advance notice. No new sub-processor is engaged and no existing control is weakened; the retention window is a new automatic deletion. Notice by Trust Center publication and this change log.

2026-10-01: heyGRC context layer (compliance context sent by your coding agent)

Documents touched: DPA §1.2, §1.5, §1.6, §2.1, §2.8, Appendix A, Appendix B; privacy policy "heyGRC Company Context", "After Account Deletion" and "heyGRC Audit Records"; RoPA Processing Activity #14 (internal register Activity #17).

  • What is added. An organization owner or admin can let the organization's own coding agent send heyGRC compliance context (policy sections, controls, vendors, risks, data categories) read from the organization's compliance platform and documents. heyGRC stores it in the EU with its version history, compiles it into short rules with exact quotes, and uses them in pull-request reviews.
  • Roles. ISMS Copilot is processor; the Customer is controller. The Customer's agent and the systems it reads are the Customer's own, not ISMS Copilot sub-processors. heyGRC fetches nothing from them on this path.
  • No new sub-processor. Compilation uses the providers already listed for heyGRC review: OpenRouter currently pinned to Together AI, Fireworks AI and Inceptron (rollback hosts documented in DPA §2.4, heyGRC AI processing) with in-request zero data retention, or Mistral AI (EU) for organizations with EU inference.
  • Retention. The current revision of each object is kept while the organization is active. Objects removed in the heyGRC console (a removed source, or an approved removal of an object deleted at the source) keep their current revision for up to 12 months so they can be restored; their text is then erased (once no stored review cites it), or sooner on the Customer's documented request (within 30 days) or about 30 days after the organization uninstalls heyGRC. An object deleted at the source stays in force, with its text, until an owner or admin approves the removal. A superseded revision is kept while a stored review cites it; its text is erased within a day of that review's deletion. A superseded revision that no review cites has its text erased 12 months after it was superseded, or once its rules are no longer in force if that is later (identifiers, hashes and timestamps kept). On the Customer's documented request, ISMS Copilot erases the text of named revisions within 30 days. This erasure does not reach review comments heyGRC has already posted on the Customer's GitHub pull requests; they stay in the Customer's repository, where the Customer can edit or delete them. Everything else is deleted about 30 days after uninstall by the daily purge; text is erased from every revision when a source reclassifies an object as secret. Records of held-change decisions (who decided, row state only) are kept on the Customer's behalf for up to 12 months, or until the organization is deleted if that comes first.
  • Audit records. Audit records of heyGRC API and console actions (who acted, when, which key and route, source IP address and user agent, and identifiers, hashes, counts and settings changed; never document content) are kept for up to 12 months from creation and then deleted automatically, including after the Customer's organization uninstalls heyGRC or the user's account is deleted. ISMS Copilot keeps them as controller for the security of the service (Art. 6(1)(f) GDPR), and shows them to the organization's owners and members while it is active.
  • Why no 30-day advance notice. No new sub-processor and no weakened control; the processing starts only when an owner or admin of the organization enables it. Notice by Trust Center publication and this change log.

2026-10-01: AI tools connected to Aevral

Documents touched: DPA §1.7 (new bullet "AI tools the Customer connects"); privacy policy (Aevral section).

  • Connecting an AI tool. Connecting an AI tool to Aevral through the Aevral MCP server is the customer's instruction to send that tool the data it asks for from the chosen organization (organization and repository names, scan and review results, findings including code excerpts, usage counts). The customer chooses the tool; its provider is not a sub-processor of ISMS Copilot.
  • What Aevral keeps. A record of each connection while connected and for 90 days after disconnect, and a 90-day log of tool calls without their content or results.

Documents touched (addition): RoPA Activity #12 (recipients, data and retention for AI tool connections).


2026-10-02: Sub-processor lists: database backup providers listed

Documents touched: DPA §2.3, §2.4, §3.1 and Appendix B; privacy policy (database and storage, international transfers); RoPA; the sub-processor lists on the trust center home page, for Aevral, the API and the Partner Embed.

  • What. A daily job, in use since 2026-03-09, copies our production database for an offsite backup. The job runs on GitHub Actions (GitHub, Inc.), on virtual machines in the United States. It encrypts the copy with AES-256 and uploads it to Backblaze B2 in the EU (Amsterdam), where the newest 90 daily copies are kept. Backblaze holds only encrypted copies and never the key. On GitHub's machine the copy is unencrypted while the job runs (at most 30 minutes), then deleted. The copy covers every product that shares the database (ISMS Copilot, heyGRC, Aevral, Partner Embed tables, API key hashes and usage ledger; no API Request Content, which is not stored), and every Customer, including those with Advanced Data Protection Mode enabled.
  • Safeguards. Backblaze and GitHub are listed, with location, safeguards and retention. The GitHub transfer relies on GitHub's EU-US Data Privacy Framework certification and Standard Contractual Clauses; the Backblaze storage relies on Backblaze's DPA with Standard Contractual Clauses, with encryption under a key Backblaze never holds.
  • Your options. You may object at any time on data-protection grounds by writing to privacy@ismscopilot.com (DPA §2.4; Partner DPA §3.2). Where your contract grants formal objection rights and we cannot resolve the objection, you may terminate the affected service without penalty.

Pages touched: trust center home page (Independent Penetration Test card, pentest badge, Legal Documents list); new /.well-known/security.txt.

  • Pentest scope. The NevaSec test (April 2026) covered ISMS Copilot only (web application, REST API, and AI backend). The home page now says so, and says that the test predates Aevral, does not cover Aevral, and that Aevral has not had an independent penetration test yet.
  • security.txt. https://trust.ismscopilot.com/.well-known/security.txt now serves an RFC 9116 file (contact contact@ismscopilot.com) instead of redirecting to the home page.
  • Aevral sub-processors. The home page Legal Documents list now links the Aevral sub-processor page. The list itself is unchanged.

2026-10-01: API EU aliases move to GLM 5.3 on Mistral (control-neutral, publication-only)

Documents touched: API Terms §3, API DPA sub-processor table, API Sub-processors (EU mode and the AI model table).

  • What changes. Mistral retires GLM 5.2 (zai-glm-5-2) on 31 October 2026. The fast and thinking EU aliases (isms-fast-eu, isms-thinking-eu) move from glm-5-2 to zai-glm-5-3, the Mistral-hosted GLM 5.3 open-weights model. The switch takes effect with the production release that follows this publication, and no later than 31 October 2026.
  • What does not change. Same sub-processor (Mistral AI SAS, France), same EU-bound endpoint (api.eu.mistral.ai), same zero-retention and no-training posture, no transfer outside the EEA, same price ($2.80 / $8.80 per million tokens). isms-mini is not affected by this change.
  • Why no 30-day advance notice. A model-version upgrade behind a stable alias with no new recipient and no weakened control (API Terms §1.2, API DPA §3). Notice by Trust Center publication and this change log.

2026-09-29: Editorial fixes to the Aevral text (no change in meaning)

Documents touched: DPA §1.6 and §1.7; privacy policy (Aevral section).

  • Link. The Aevral sub-processor list link now points to https://trust.ismscopilot.com/en/aevral/subprocessors; the old path redirected to the trust center home page.
  • Layout. In DPA §1.6 the paragraph on special category and criminal-offence data is separated from the Aevral bullet above it, so it reads as applying to all processing, as before the 2026-09-28 revision.

2026-09-28: Aevral added to the Terms, DPA, privacy policy and RoPA

Documents touched: Terms §1(i) and §1(ii); DPA §1.1, §1.2, §1.5, §1.6, new §1.7, Appendix B; privacy policy (new Aevral section); RoPA (new Activity #12).

  • Aevral in scope. The DPA, privacy policy and RoPA now cover Aevral, the Better ISMS code security product. For code and pull requests, ISMS Copilot is the customer's processor; for Aevral accounts and billing, it is controller.
  • Installing is accepting. Installing the Aevral GitHub App is use of the Services and accepts the Terms and DPA for the organization that installs it.
  • GitHub. GitHub is not a sub-processor for the Aevral and heyGRC GitHub Apps: it acts under the customer's own agreement with GitHub.
  • Carve-outs. Terms §1(iii), §6(i) and §7 state that Aevral is billed through Stripe for all customers and has no Advanced Data Protection Mode; its AI routing is described in DPA §1.7. The privacy policy gives Aevral an email path for data-subject rights.
  • Terms clean-up published with this revision. §8(ii) now excludes only indirect loss (direct loss stays under the §8(iii) cap); §10(ii) states the Product Liability Directive 2024/2853 application date correctly; the 2026-07-22 liability, consumer and product-liability changes, approved earlier, are published here for the first time.
  • Aevral retention. Data is kept while the App is installed and for 12 months after an uninstall, then deleted; deletion or return on request within 30 days at any time.
  • Effective dates. Terms, DPA, privacy policy and RoPA now carry the effective date 2026-09-28.
  • Why control-neutral. Aevral's infrastructure and AI providers were already on the sub-processor list. The Aevral list also names Tally, the form provider, which receives only what a user submits in an issue or contact form and no repository content. No change for ISMS Copilot chat customers.

2026-09-28: heyGRC Google Drive deletion terms; connection available to every heyGRC organization

Documents touched: DPA §2.4 Customer-Activated table, §2.8, Appendix B; privacy policy Google User Data retention; RoPA and sub-processors list (revoke qualifier).

  • Deletion on disconnect. DPA §2.8 now states what happens to Google Drive connection data: revoke at Google, immediate hard delete of the encrypted refresh token, Google account identity cleared, automatic end of the connection, normally within about 30 minutes, on uninstall or when the connecting admin leaves the organization, and the retention of documents already linked from Drive.
  • Availability. The Connect Google Drive control is now available to every heyGRC organization. It stays a Customer-Activated Integration: no data flows to Google unless an organization owner or admin connects Drive, so the 30-day advance-notice rule in DPA §2.4 does not apply. The 2026-09-26 entry said the control was limited to allowlisted organizations; that limit is lifted.
  • Why control-neutral. No new sub-processor, no new data category, no weaker control. The deletion text documents behaviour that was already live.

2026-09-26: heyGRC Google Drive as a Customer-Activated Integration

Documents touched: DPA §2.4 Customer-Activated table, §3.1, Appendix B; RoPA Customer-Activated table; privacy policy Optional Integrations and Google User Data (Limited Use); public sub-processors list.

  • What is added. Google LLC (Drive API, OAuth, Picker) is listed as a Customer-Activated Integration for heyGRC linked documents. An organization owner or admin connects Drive in the heyGRC console. Scope is drive.file (only files they pick). Disconnect revokes at Google and deletes the encrypted refresh token.
  • Why no 30-day advance notice. Customer-Activated Integrations are not subject to the 30-day rule in DPA §2.4: no customer data flows to Google unless that org admin connects Drive.
  • Limited Use. The privacy policy now carries the Google API Services User Data Policy / Limited Use disclosure required for the OAuth consent screen.
  • Notice. Trust Center publication, this change log, and the product-update channel. The in-product Connect Drive control remains server-gated until an org is allowlisted.

2026-09-01: ISO/IEC 27001 programme named as Better ISMS, not a product certificate (control-neutral honesty)

Documents touched: customer-facing DPA §2.9 and effective date, RoPA overview and effective date, Partner Embed DPA §5, API DPA §5. Source SHA 086eeecd3 (isms-copilot #2708).

  • Who is pursuing ISO 27001. The chat DPA previously said "ISMS Copilot will obtain ... (ISO 27001 in progress)". The applicant is Better ISMS. The programme is the ISMS, not a product certificate. Public status: https://trust.ismscopilot.com/en/iso-27001. Not certified today. No promise to obtain other certifications.
  • Effective date. Chat DPA and RoPA effective dates move to 2026-09-01 for this honesty rewrite. Non-materially-adverse under DPA §7.2: clarification of who the applicant is, not a processing or control change.
  • Embed and API DPAs. Same programme sentence: Better ISMS is pursuing ISO/IEC 27001:2022 for the ISMS, not certified today, not a product certification. We do not hold a company SOC 2.
  • Why control-neutral. No sub-processor change, no weakening of a control, no new processing. Notice by this change log and Trust Center publication.

2026-09-01: Chat AI models upgraded to the GLM-5.3 family (control-neutral, publication-only)

Chat (paid fast, paid think, and the free/logged-out tier including the over-quota overflow lane) is moving to the GLM-5.3 model family via a gradual rollout. Paid fast is a model-version swap on the same disclosed OpenRouter pin (Together AI, Fireworks AI, Inceptron); paid think moves from the disclosed xAI (ZDR) endpoint to that same pin (xAI stays disclosed and available as the operator rollback route); the free and overflow lanes move from GLM-4.7 to GLM-5.3-Flash on that pin. No new sub-processor: all recipients are already disclosed. The same in-request zero-retention (data_collection: deny, zdr: true) and OpenRouter account-level controls apply unchanged. Advanced Data Protection (Mistral, EU) remains available and suppresses the OpenRouter path entirely. Details: DPA Appendix B.


2026-07-31: API Zero Data Retention (ZDR) surface and error-path hardening (control-neutral / strengthening)

Documents touched: API DPA (§5, §7.1, Annex II logging, Annex III Sentry row), API Sub-processors (Retention lead, Sentry row).

  • ZDR for Request Content restated as the product commitment. Prompts and model outputs are not stored as customer records in the API data layer; usage and billing metadata remain under independent-controller §7.2. Upstream OpenRouter (account-level + in-request ZDR) and Mistral (EU ZDR agreement) unchanged in recipient set.
  • Error-path strengthening. Operational logs and Sentry are configured not to embed raw upstream provider error bodies that may echo prompt fragments; Sentry drops request bodies and continues credential scrubbing. No new sub-processor; residual risk reduced, not expanded.
  • Why no 30-day advance notice. Control-neutral / strengthening: no new recipient of Request Content, no weakened retention or transfer control. Notice by Trust Center publication and this change log. Product explanation: docs.ismscopilot.com/docs/api/zero-data-retention.

Documents added: the ISMS Copilot API legal set at API Terms, API DPA, and API Sub-processors, distinct from chat and Partner Embed.

  • Relationship. Customer is Controller of Request Content; ISMS Copilot is Processor; ISMS Copilot is independent controller of the usage and billing ledger.
  • Modes. EU aliases (-eu) use Mistral AI in the EU. Bare aliases use z-ai/glm-5.2 via OpenRouter (US), pinned in code to Together AI, Fireworks AI, and Inceptron AB (DeepInfra is not in the pin). Kill-switch can serve bare aliases on the EU path.
  • Billing. Prepaid credits (1 credit = 1 USD). Published schedule is source of rates. Some models bill at fixed schedule rates; others at cost times published markup. Complete and partial responses debit when metered; rejects without billable usage do not.
  • Present-tense posture. Public pages describe live controls only (three-host pin, error diagnostics may include prompt text, Sentry credential scrubbing, no persistent Request Content records in the API data layer). No public engineering roadmap language.
  • Transfers. Global path rests on Art. 46 SCCs plus supplementary measures (no DPF anchor on this pin). EU mode keeps AI-model processing in the EEA.

Documents touched: Partner DPA (§1.3), Partner Terms (§4.4), Partner Embed Sub-processors.

  • Special-category (Art. 9) and criminal-offence (Art. 10) data: the lift now requires the ADP tier. The default prohibition remains; it is lifted only where the Partner has an evidenced lawful condition, has notified ISMS Copilot in writing, and the workload is processed exclusively on the Advanced Data Protection tier (Mistral AI, EU, zero retention). The economy/OpenRouter routing path is never an authorised path for such data, with or without amendment. This aligns the Partner Embed with the chat product's DPA §4.2 posture (one technical control across products).
  • Premium GLM-5.2 host set corrected: DeepInfra replaced by Inceptron. DeepInfra was removed from the GLM-5.2 pin on 2026-07-23 (it lacked a publicly-verifiable SCC-bearing DPA and carried ~0% of GLM-5.2 traffic; it remains on the account allowlist for other models). The closed set is now Together AI (US), Fireworks AI (US), Inceptron AB (Sweden, EU). Strengthening / control-neutral: the recipient set narrows and an EU-jurisdiction host is added.
  • Why no advance notice: both changes strengthen controls (a stricter sensitive-data rule; a narrowed recipient set); no control is weakened and no new sub-processor is added. Notice by Trust Center publication and this change log; no partner had accepted the prior version.

2026-07-23: Special-category / criminal-offence data excluded from the default AI path; glm-5.2 provider set narrowed + in-request ZDR (effective 2026-07-23; control-neutral / strengthening)

Documents touched: customer-facing DATA-PROCESSING-AGREEMENT.md (new §4.2, Appendix B change-log entry, effective date 2026-07-23), PRIVACY-POLICY.md, REGISTER-OF-PROCESSING-ACTIVITIES.md.

  • Special category (Art 9) and criminal-offence (Art 10) data excluded from the default (non-ADP) AI routing path. The Privacy Policy and RoPA now state that such data is excluded from the default AI path; customers intending to process it with AI assistance must enable Advanced Data Protection Mode (Mistral, EU, zero-retention). ISMS Copilot does not warrant automatic detection or filtering of special-category content on the default path; the customer remains responsible for lawful basis and for enabling Advanced Data Protection Mode. Full routing and safeguard detail in DPA §4.2.
  • DeepInfra removed from the z-ai/glm-5.2 provider set. DeepInfra is removed from the closed provider list for glm-5.2 (chat, API, heyGRC review), leaving Together AI, Fireworks AI, and Inceptron; it was dropped for lacking a publicly-verifiable SCC-bearing DPA and carried ~0% of glm-5.2 traffic. DeepInfra remains on the account allowlist for other models.
  • In-request Zero Data Retention added to the glm-5.2 pins. The chat/partner-premium, API, and heyGRC review glm-5.2 pins now set data_collection:"deny" + zdr:true in the request itself, so zero-retention and no-training hold in-request and no longer rely on the OpenRouter account-level toggle alone.
  • Why control-neutral / strengthening. A provider is removed (narrowing the recipient set) and retention controls are strengthened; no control is weakened and no new sub-processor is added, so the 30-day advance-notice rule does not apply. Notice by Trust Center publication and this change log.

Documents added: the ISMS Copilot Partner Embed legal set, published as its own product-scoped Trust Center pages, distinct from the chat product's documents: Partner Terms of Service, Partner Data Processing Agreement, and Partner Embed Sub-processors.

  • What the Partner Embed is. The Partner Embed lets a Partner integrate the ISMS Copilot AI assistant into its own product for the Partner's own end-users. In that relationship the Partner is the Controller of its end-users' personal data and ISMS Copilot is the Processor (Art. 28 GDPR). This is a different relationship from the chat product, where ISMS Copilot's own users are the customers, so the Partner Embed has its own Terms, DPA, and sub-processor list at /embed/*. The chat product pages are unchanged.
  • Scope and posture. The Partner ToS covers the AI-output disclaimers, tiers and billing, availability, suspension, the liability cap (the greater of trailing-12-month fees or a EUR 500 floor, claim-gated, never nil), IP and licence, indemnity, confidentiality, trade controls, and the EU AI Act provider/deployer split. The Partner DPA covers the Art. 28(3) processor obligations, general sub-processor authorisation with control-neutral routing within the disclosed envelope (publication-only) and a 30-day advance-notice objection-and-termination remedy reserved for a genuinely new sub-processor or a material control change, international transfers (SCCs Module Three for direct non-EEA legs, OpenRouter as exporter for the onward economy (GLM-4.7) and premium (GLM-5.2) host legs via Art. 28(4) flow-down, EU-US Data Privacy Framework via Google LLC as an additional basis for Vertex), a concluded transfer impact assessment for the US inference legs, the hybrid retention model (operational erasure plus a statutory ledger on Art. 6(1)(c) pseudonymisation), breach notification within 24 hours, and the SCC Annexes.
  • Sub-processors (by tier). Infrastructure and observability (Supabase, Fly.io, Vercel, Sentry, Axiom) plus Mistral (EU) content moderation on every tier. The AI model by tier is: GLM-4.7 via OpenRouter pinned to a closed non-PRC host set (Cerebras, Google Vertex), mandatory zero-retention, on the economy tiers (Free, Starter); on the premium tiers (Growth, Scale, Enterprise) the primary is GLM-5.2, a further open-weights model of Chinese authorship, likewise via OpenRouter pinned to a closed non-PRC host set (Together AI, Fireworks AI, DeepInfra), mandatory zero-retention, with Anthropic (US) as the pre-first-token fallback (SCCs Module Three, standard commercial retention, no zero-retention) and Mistral (EU) as the deeper circuit-breaker failover; and Mistral (EU) on the ADP tier. End-user economy and premium prompts do not reach a PRC endpoint. Stripe processes partner billing data only and is not an end-user-data sub-processor.
  • Consistency with the chat Trust Center. The Partner Embed sub-processor naming, the economy- and premium-tier China posture (each model's first-party PRC endpoint named only as a blocked host), the OpenRouter mandatory-ZDR framing, and the Anthropic retention wording (ordinary deletion up to ~30 days, safety-flagged content up to 2 years, safety-classification scores up to 7 years, no training) mirror the chat product's customer-facing documents. Because both the economy (GLM-4.7) and premium (GLM-5.2) primary models are of Chinese authorship, the model-origin acknowledgment sits in the Partner DPA (§3.3) and ToS (§5) and is also surfaced on the public Partner Embed sub-processor list.
  • Sub-processor changes are control-neutral by default. Within the disclosed OpenRouter / Anthropic / Mistral envelope, ISMS Copilot may route or switch the Partner's AI traffic (and move a tier or cohort between destinations over time) publication-only, with no advance notice, provided prompts are never routed to a PRC endpoint and a selected EU / ADP (Mistral, EU) path stays EU. Only a genuinely new sub-processor or a material control change triggers 30-day advance notice plus the objection-and-termination remedy (Partner DPA §3.2), mirroring the chat DPA §2.4 model. Direct non-EEA legs are on SCCs Module Three; OpenRouter is the exporter for the onward economy (GLM-4.7) and premium (GLM-5.2) host legs via the Art. 28(4) flow-down; EU-US Data Privacy Framework via Google LLC is an additional basis for Vertex.

2026-07-21: xAI (Grok) activated as the default AI provider for paid chat Fast/Think and Beyond (effective 2026-07-21; control-neutral)

Documents touched: customer-facing DATA-PROCESSING-AGREEMENT.md, PRIVACY-POLICY.md, REGISTER-OF-PROCESSING-ACTIVITIES.md, TERMS-OF-SERVICE.md, and the standalone SUB-PROCESSOR-CHANGE-NOTICE-2026-07-21-XAI-GROK-DEFAULT.md; internal ai-system/ZDR-Provider-Tracker.md, data-protection/REGISTER-OF-PROCESSING-ACTIVITIES.md, and the ai-system/evidence/ captures.

  • xAI activated for paid Customer-Content, not added. xAI is already present on the OpenRouter account allowlist and already serves the public, logged-out risk-analysis demo through OpenRouter's "xAI (ZDR)" endpoint. This change documents that existing account state and activates the paid Customer-Content scope; it does not introduce a new provider to the account.
  • New default for paid Fast/Think/Beyond. For paid plans (Plus and above) with Advanced Data Protection off, the default AI provider for the chat Fast and Think modes and the Beyond assistant is now xAI (Grok models) via OpenRouter's "xAI (ZDR)" endpoint, replacing Anthropic as the default for those routes. Anthropic Claude is retained as the automatic pre-first-token failover (Opus for Think, Sonnet for Fast) and remains a disclosed sub-processor. Free, Essential, and null-plan glm-4.7 routing and Advanced Data Protection routing (Mistral, EU) are unchanged.
  • Why control-neutral. As configured and verified 2026-07-19, the "xAI (ZDR)" endpoint operates under mandatory OpenRouter account-level Zero Data Retention (stronger than the Anthropic standard-commercial-API retention it replaces), no-training (account-level training-disallowed plus xAI's published API no-training default), US (non-PRC) jurisdiction, and the same underlying-provider SCC transfer mechanism (xAI's published DPA, EU SCCs Modules 2/3, Irish-law, with OpenRouter's Article 28(4) flow-down). No control is weakened, no new category of personal data is introduced, and Advanced Data Protection (Mistral, EU, zero-retention) remains available to suppress the OpenRouter path entirely. Classified control-neutral under DPA §2.4(c).
  • Notice mechanism. Control-neutral, so notice is by publication in the Trust Center and this change log, with no advance notice period. Customers may object at any time via privacy@ismscopilot.com or enable Advanced Data Protection.
  • Location. OpenRouter publishes a United States footprint for xAI and does not pin the per-request inference region; the underlying-provider SCCs are the operative transfer safeguard. Customers needing a guaranteed EU destination should enable Advanced Data Protection (Mistral, Frankfurt).
  • Companion reconciliations shipped in the same publication. The RoPA sub-processor-change procedure and the "Record Maintenance" change-driven-updates bullet were reconciled to mirror the DPA §2.4 materially-adverse / control-neutral split; the closed-allowlist provider count was corrected to eight where it describes the full Customer-Content destination set (the seven glm-4.7 hosts remain seven for free-tier routing); the stale demo disclosure in RoPA Processing Activity #11 ("public business data only, never customer content") was corrected to reflect design intent rather than a semantic guarantee.

2026-07-19: Unified non-ADP AI-routing envelope, Anthropic retention correction, and the app-managed Plus trial (effective 2026-07-19; control-neutral)

Documents touched: customer-facing PRIVACY-POLICY.md, DATA-PROCESSING-AGREEMENT.md, REGISTER-OF-PROCESSING-ACTIVITIES.md, TERMS-OF-SERVICE.md.

  • Unified non-ADP routing envelope. The non-ADP AI-routing disclosure no longer differentiates by plan: any non-ADP plan (including Free) may be served by Anthropic under its standard commercial API terms or by the zero-retention OpenRouter allowlist, with Mistral (EU) as the failover. The specific provider serving a given request may vary by plan, rollout, and over time. Advanced Data Protection remains the guaranteed EU, zero-retention path. The unification is classified control-neutral under DPA §2.4 (no new sub-processor; no weakening of an existing control), so no advance notice period applies.
  • Anthropic retention corrected. The Anthropic retention statement now reflects its standard commercial API terms: inputs and outputs are ordinarily deleted within about 30 days; content flagged by Anthropic's safety systems may be retained up to 2 years and safety-classification scores up to 7 years; never used for model training.
  • App-managed Plus trial. A 7-day, no-card Plus trial is being introduced. When a trial starts, the account records a free-trial eligibility marker (one trial per account), kept for the life of the account under our legitimate interest in offering the one-time trial fairly and deleted when the account is deleted. The marker and the trial fields are included in the GDPR Art. 15 data export, and you can object at any time via privacy@ismscopilot.com. Trial AI traffic rides the same unified envelope; there is no separate trial carve-out.
  • Web search is live. The authenticated web-search disclosure (dedicated entry below) is effective as of this publication.

2026-07-19: Authenticated web-search Mistral bridge (Mistral web search uses Brave/US) and future Brave-direct notice package (effective 2026-07-19)

Documents touched: customer-facing PRIVACY-POLICY.md, DATA-PROCESSING-AGREEMENT.md, REGISTER-OF-PROCESSING-ACTIVITIES.md, TERMS-OF-SERVICE.md; internal data-protection/REGISTER-OF-PROCESSING-ACTIVITIES.md and data-protection/AUTHENTICATED-WEB-SEARCH-LAUNCH-DECISION-2026-07-13.md. The corresponding Trust Center pages, in-app changelog, customer email, and any help-center mirror must be synchronized when the notice is issued.

  • Product behavior disclosed. Eligible authenticated requests may use a conservative Mistral search-intent check. Search is visible through source provenance and can be disabled by personal and organization policy. Retrieval supplies the current/company-specific evidence; the answering AI reasons and writes using that evidence and separately maintained framework knowledge. Citations support review but are not a correctness guarantee.
  • Mistral bridge for non-ADP discovery. SEARCH_RETRIEVAL_PROVIDER defaults to Mistral for eligible ADP-off search. Mistral discovers provider-attested source URLs and its generated search prose is discarded. The EU Fly.io service exact-fetches referenced pages and passes bounded labeled extracts to the answer model already applicable to the conversation or Beyond run. No additional semantic grounding model receives the draft. Mistral's web search runs on Mistral's stateful Conversations/Agents endpoint, which Mistral excludes from its zero-retention posture, and uses Brave Search (Brave Software, Inc., United States) as its web-search sub-processor; the non-ADP query hop therefore goes Mistral (EU) to Brave (US), is not EU-only and not zero-retention, and standard (non-zero) retention applies. Authenticated web search fails closed under ADP (because Mistral web search is not EU-only or zero-retention), while exact user-selected page/document fetch remains available through EU Fly and the all-Mistral answer topology.
  • Exact fetch is EU and request-scoped. The same hardened Fly service fetches Mistral-attested URLs and exact URLs submitted in Beyond. Each selected public host receives ordinary outbound request metadata. Raw discovery responses, Mistral prose, page text, and search evidence are not persisted. The generated answer and displayed source links follow the existing conversation-retention setting.
  • The Brave-direct route is pending, dark, and not the launch default. This is separate from Brave's launch role as Mistral's web-search sub-processor described above. A proposed future direct Brave route (ISMS Copilot calling the Brave API itself, rather than reaching Brave via Mistral) would send only a bounded latest-request query and no files, memories, workspace context, account identifiers, or user/device identifiers. Brave operates in the United States on AWS, standard query logs may be retained up to 90 days, and SCCs are the transfer mechanism. Brave's DPA excludes Search Query Data from processor scope, so the documents disclose Brave as a limited recipient rather than representing the query processing as covered by Article 28 processor terms.
  • Notice classification and timing. The materially-adverse classification and 30-day advance-notice requirement apply to the future Brave-direct route only (ISMS Copilot calling the Brave API itself), which would create a new US recipient with a different retention and contractual posture under DPA §2.4. 2026-08-12 is the earliest possible activation of that future route only if the notice is actually published and emailed on 2026-07-13; otherwise the activation date moves to at least 30 days after actual notice. That future route also remains subject to founder acceptance of Brave's contract, Search Query Data carve-out, selected plan, and standard retention posture. The launch Mistral-mediated route (where Brave is reached only as Mistral's own web-search sub-processor and is not engaged by ISMS Copilot) is not classified as a materially-adverse baseline-processing change: it is a user-directed, customer-controllable feature (it fires only on the user's own search intent, is disabled under ADP, is controllable by personal and organization policy, and is shown via source provenance), and it is disclosed at launch through the Trust Center, DPA, and in-app changelog when the feature goes live.

Notice status: the Mistral/Fly launch disclosure is PUBLISHED effective 2026-07-19; the feature is live in production. Mistral web search is disclosed as not having the EU-only, zero-retention posture of other Mistral routes: it runs on Mistral's stateful Conversations/Agents endpoint and uses Brave (US) as its web-search sub-processor, so the non-ADP query hop reaches Brave (US) under standard retention. The founder-acceptance decision is the residual Mistral Additional-Product-Terms interpretation risk for persisted links/answers (see the internal launch decision record), not the search-hop location or retention, which are now known. The separate future Brave-direct notice package is not yet published or emailed; the direct-Brave route must remain disabled. The customer-facing documents and this entry were published on 2026-07-19, after the feature went live and the deployment and smoke-test gates recorded in the search launch-readiness document were met.

2026-06-23: Paid-plan AI routing may use the OpenRouter allowlist alongside Anthropic (effective 2026-06-23; control-neutral)

Documents touched: customer-facing DATA-PROCESSING-AGREEMENT.md, PRIVACY-POLICY.md, REGISTER-OF-PROCESSING-ACTIVITIES.md, TERMS-OF-SERVICE.md; internal ai-system/ZDR-Provider-Tracker.md and data-protection/VENDOR-DPA-OPENROUTER-2026-05-05.md. (The OpenRouter underlying-provider allowlist expansion from 4 to 7 and the §2.4 notice-mechanism amendment first noticed on 2026-05-26 are brought into effect together with this change on 2026-06-23, two days ahead of the previously published 2026-06-25 date; those providers have been on the operational allowlist since 2026-05-25, the change is control-neutral, and the objection / Advanced-Data-Protection rights are unchanged. The 2026-06-13 per-session-election proposal recorded below was superseded before publication and never took effect.)

  • Paid-plan routing broadened to mirror the free tier. For paid plans (Plus, Standard, Pro, Business) with Advanced Data Protection off, the closed 7-provider OpenRouter allowlist (Inceptron, DeepInfra, Cerebras, Google Vertex, Together AI, Fireworks AI, Nebius) becomes a permitted AI-routing destination alongside Anthropic, for any chat mode. A paid request may be served by Anthropic or by any allowlisted provider, and routing may move between them over time, with no further sub-processor change.
  • Anthropic is not removed. It remains a disclosed paid provider and the circuit-breaker failover context; it is simply no longer the sole paid path.
  • No new sub-processor; controls unchanged. OpenRouter and all seven underlying providers are already disclosed. The same account-level controls (mandatory Zero Data Retention, training-disallowed, publication-disallowed, allowlist, PRC-blocklist) and the same underlying-provider transfer mechanism (SCCs at the underlying-provider layer; DPF for Google Vertex) apply unchanged. Every allowlisted provider is equal to or stronger than Anthropic on retention, training, and jurisdiction.
  • Retention. Unchanged for any paid traffic still served by Anthropic (up to 30 days for abuse monitoring only, not training). Paid traffic served by an allowlisted provider is zero-retention.
  • EU residency. Advanced Data Protection remains the account-level EU-residency guarantee: enabling it routes all of the organization's AI processing to Mistral (EU, Frankfurt) and suppresses the OpenRouter path for every user, regardless of plan or mode.
  • Supersedes Amendment B. The 2026-06-13 Amendment B (a per-session end-user election gating paid-plan overflow routing) was never published or made operative and is superseded in full by this amendment, which replaces the per-session election model with the account-level routing approach above. The Amendment B entry below is retained for historical completeness only.
  • Classified control-neutral. Notice is via Trust Center publication and the in-app changelog, per DPA §2.4. The Customer may object at any time by emailing privacy@ismscopilot.com, and may keep all processing in the EU at any time by enabling Advanced Data Protection.

2026-06-13: DPA Pending Amendment B: OpenRouter scope expansion to paid-plan overflow routing (effective on publication; control-neutral; web-only)

Documents touched: customer-facing DATA-PROCESSING-AGREEMENT.md, PRIVACY-POLICY.md, TERMS-OF-SERVICE.md, REGISTER-OF-PROCESSING-ACTIVITIES.md; internal data-protection/TRANSFER-IMPACT-ASSESSMENT.md, data-protection/REGISTER-OF-PROCESSING-ACTIVITIES.md, and the new data-protection/SUB-PROCESSOR-CHANGE-NOTICE-2026-06-13-OVERFLOW-FALLBACK.md. (This amendment is independent of the 2026-05-26 DPA §2.4 amendment, which is effective 2026-06-25 under its own 30-day notice schedule.)

  • OpenRouter sub-processor scope expanded. The OpenRouter aggregator (already disclosed since 2026-04-27 for free / null-plan users, expanded 2026-05-28 to Essential) gains a third scope: serve paid plans (Plus, Standard, Pro, Business) with ADP off as overflow routing after the 4-hour token cap is reached, restricted to the same closed two-provider subset as Essential (Google Vertex and Cerebras). No new sub-processor is introduced; no new underlying provider; no change to account-level controls (mandatory ZDR, training-disallowed, publication-disallowed, allowlist, PRC-blocklist); no change to transfer mechanism (SCCs at the underlying-provider layer).
  • Activation is per-session, on explicit in-product end-user election. The overflow path does not auto-engage. When a paid-plan user hits the 4-hour token cap in the ISMS Copilot web app, an in-product card offers continuation on the faster overflow model OR continuation by upgrading to a higher-cap plan. The user must click Continue to elect overflow routing, which then applies for the rest of the current 4-hour window or until an additional overflow usage limit is reached, whichever comes first. The election expires automatically at the next 4-hour bin boundary and is re-prompted on the next over-cap request. Without the election, the request is rate-limited and Anthropic remains the only AI sub-processor for the remainder of the session.
  • Traffic from channels without an in-product election surface (such as Slack integrations) is EXCLUDED from the overflow path. Those channels do not provide an in-product election surface that meets the consent semantics above. Paid-plan users on such channels continue to receive the standard rate-limit message at the 4-hour cap; no overflow routing occurs from those requests in v1.
  • §2.4 control-neutral category clarified. The existing control-neutral category (whose listed examples are non-exhaustive) is clarified with a new (b) example: expanding an already-disclosed sub-processor's scope to serve an additional Customer cohort where the underlying-provider subset, account-level controls, and transfer mechanism remain unchanged, and where no Customer Personal Data flows under the expanded scope unless an explicit per-session end-user election is recorded. The OpenRouter overflow scope expansion is an instance of (b).
  • Existing routing unchanged. ADP path (Mistral, EU) is unchanged. Existing paid-plan routing under the cap (Anthropic, US, SCCs) is unchanged. Free-plan and Essential-plan OpenRouter routing is unchanged. Beyond mode (Plus+) is unchanged; over-cap Beyond requests downgrade to the normal flow with a new notice reason that surfaces the cap state and lets the overflow election flow handle the routing.
  • Classified control-neutral. ISMS Copilot classified this scope expansion as a control-neutral change under §2.4. The amendment becomes effective on publication (the dev-to-main release plus the trust-center mirror sync).

Notice mechanism for this change: in-app changelog (blue-point unread indicator) + Trust Center publication on the effective date + a clearly labeled entry in the next monthly product-changelog email. The change is classified as control-neutral under the new §2.4 (b) wording, so the 30-day advance-notification rule for materially-adverse changes does not apply. Customers may object at any time via privacy@ismscopilot.com. The durable EU-only opt-out (Advanced Data Protection Mode → Mistral, Frankfurt) remains available on every plan.

2026-05-26 — DPA §2.4 sub-processor-notice amendment + OpenRouter allowlist expansion (effective 2026-06-25)

Documents touched: PRIVACY-POLICY.md, DATA-PROCESSING-AGREEMENT.md, REGISTER-OF-PROCESSING-ACTIVITIES.md, TERMS-OF-SERVICE.md.

  • DPA §2.4 sub-processor notice mechanism amended. Aligned with industry norm (Anthropic, OpenAI, Vercel) by distinguishing materially-adverse sub-processor changes (which continue to get at least 30 days' advance notice by in-app announcement and email) from control-neutral changes (notified by Trust Center publication and in-app changelog). The privacy bar itself — zero data retention, no training on customer data, no PRC-jurisdiction infrastructure, Advanced Data Protection Mode available on every plan for EU-only processing — is unchanged. Privacy Policy §2 sub-processor paragraph updated to cross-reference the new §2.4 wording.
  • OpenRouter underlying-provider allowlist expanded from four to seven. Under the new §2.4 wording, this is the first control-neutral change: the named providers are now Inceptron, DeepInfra, Cerebras, Google Vertex (the original four) plus Together AI, Fireworks AI, and Nebius. Each addition was evaluated against the same privacy and jurisdiction bar applied to the original four: zero-retention posture for inference, no training on customer data, published DPA, non-PRC jurisdiction, public deployment-region disclosure. Together AI publishes default routing to North America inference data centers; Fireworks AI operates a multi-region fleet (US, EU Frankfurt + Iceland, APAC Tokyo only — no PRC or Hong Kong infrastructure); Nebius runs primary inference in Finland (EU) with US secondary. Region pinning at the per-provider layer is not exposed by OpenRouter's aggregator API; the §3.1.4 PRC-jurisdiction control relies on each provider's published default region NOT being PRC, verified provider-by-provider during this review.
  • Novita AI evaluated and not added. Novita's corporate HQ is recorded as US, but their public materials describe their inference infrastructure only as "20+ locations, 4+ continents" without naming any region. They do not publish a DPA, a sub-processor list, a governing-law clause in their ToS, or a sub-processor enumeration. For a control framed as a Schrems II-style supplementary measure (no Customer Content transits PRC infrastructure), public opacity makes the control unevidenceable. Re-evaluation requires a written commitment on regional pinning and a published DPA.
  • Account-level controls unchanged. Mandatory Zero Data Retention, Free/Paid Training Disallowed, Free Publication Disallowed, and the PRC-jurisdiction blocklist (Alibaba Cloud International, Baidu Qianfan, DeepSeek, Moonshot AI, Xiaomi, Z.AI) all remain in force.

Notice mechanism for this change: in-app changelog (blue-point unread indicator, visible from 2026-05-26 through 2026-06-25, the full 30-day objection window) + Trust Center publication on 2026-05-26 + a clearly labeled entry titled "Legal/privacy update: DPA amendment and OR allowlist notice" in the May 2026 monthly product-changelog email shipping in the first days of June. Both the DPA amendment and the OR allowlist expansion are effective 2026-06-25, giving customers 30 days to object via privacy@ismscopilot.com. A more detailed internal change record is available on request.

2026-04-29 — Terms of Service

Documents touched: TERMS-OF-SERVICE.md only.

  • Added §5(v) Customer Content confirming that, as between the user and ISMS Copilot, the user retains all rights to outputs they create, review, adapt, or publish using the Services. The clause includes four for-clarity carve-outs covering: (a) no rights granted over the Services or their underlying technology; (b) outputs may not be represented as official standards, certifications, or legal advice; (c) outputs may not be used to assert IP claims over content that infringes third-party rights or that was generated by inputting third-party copyrighted material; and (d) ISMS Copilot retains the existing abuse-detection / QA monitoring carve-out under §11(iii).
  • Closes a customer-raised gap on supplier-assurance IP-ownership clarity. The other three documents in this set are unchanged in this revision.

2026-04-27 — Multi-document update (Privacy Policy, DPA, RoPA, Terms)

Documents touched: PRIVACY-POLICY.md, DATA-PROCESSING-AGREEMENT.md, REGISTER-OF-PROCESSING-ACTIVITIES.md, TERMS-OF-SERVICE.md.

  • OpenRouter underlying providers named. The previous vague "United States" reference is replaced with a closed four-provider allowlist (Inceptron, DeepInfra, Cerebras, Google Vertex). Account-level controls are disclosed: mandatory Zero Data Retention; training disallowed (free + paid); publication disallowed (free); PRC-jurisdiction blocklist.
  • Active vs Reserved sub-processor split. OpenAI, X.AI, and Google Gemini are documented as Reserved — code paths exist but no user-facing flow invokes them — and their activation requires customer notice. The Privacy Policy lists Active sub-processors only.
  • Slack (heygrc bot) disclosed as a Customer-Activated Integration. Slack Technologies, Inc. only becomes a sub-processor for a customer's data when that customer's organisation owner explicitly installs the bot. The 30-day advance-notice rule for Active sub-processors does not apply because activation requires explicit customer-side action. New processing activity (RoPA #10), new data-subject category (Slack workspace users without ISMS Copilot accounts), and a ToS §7(iv) acknowledgment.
  • Anthropic retention factually corrected. The prior "zero retention" wording for Anthropic on the paid default path is replaced with the accurate 30-day commercial-API abuse-monitoring cache. Customers requiring zero retention are directed to enable Advanced Data Protection (Mistral, EU).
  • "No-training" wording tightened. Prior wording implied a signed bilateral addendum with Anthropic and Mistral. New wording reflects what is actually relied on: each provider's published commercial-API terms prohibit training on customer content.
  • Per-provider transfer-mechanism stack documented in DPA §3 (SCCs / SCCs + EU-US Data Privacy Framework / EU residency, depending on provider).
  • Moderation correction. Moderation always runs on Mistral (EU, zero retention), regardless of ADP. The Privacy Policy and DPA disclose the metadata-only retention scope of moderation_events and the thread-deletion lock for flagged threads (with the Article 17 email-mediated path for content within flagged threads).
  • ToS §11(iii) and §7(i) tightened — the prior "without anonymization and strict safeguards" carveout is removed, and the prior blanket EU-residency disclaimer is replaced with a factual routing description matching the Privacy Policy and DPA.
  • Advanced Data Protection (ADP) framed as the durable in-product opt-out for any user who needs fully EU-based AI processing.

A 30-day customer objection window for the OpenRouter sub-processor change runs through 2026-05-27.