simse Sub-processors

Effective date: 15 September 2026

Revised 27 September 2026 — Cloudflare's row now names the website-analytics leg: Cloudflare Web Analytics on simse.dev, only for visitors who allow analytics. It carries our own controller data about website visitors, not customer personal data, so it is recorded here for completeness and did not require the notice in Section 3. The same revision brings this page into line with Annex III of the Data Processing Agreement, which governs where the two differ: Cloudflare's row now says that it handles the full content of your traffic at its edge, where encryption in transit ends, that its backup custody includes the object store copied nightly since 26 September 2026, and that its addendum's acceptance for our account is not yet confirmed; three rows, not two, now carry that last-column qualification; the Anthropic entries and the connector row no longer say the assistant is not serving; and Section 5 names Tailscale. Section 7 records it.

Revised 15 September 2026 — an inference credential is now provisioned, so the statements that none existed and that the path was not serving have been corrected throughout. The credential is a consumer-subscription one, which carries no data processing addendum and no transfer instrument; the commitment to process customer content only under a commercial API credential is unchanged, and the platform holds no customer accounts.

We use a small number of outside companies to run simse. This page names every one of them, what it does for us, what data it touches, where it is, and what protects that data when it crosses a border.

This is the public counterpart to Annex III of our Data Processing Agreement. For a customer under that agreement, Annex III is the contractual list and this page mirrors it. If the two ever disagree, Annex III governs and we correct this page.

Schedule A — Entity particulars

These are the only blanks on this page. Everything else is decided. Each is completed at publication, together with the effective date above.

Wherever this page says "we", "us" or "simse", it means the entity named at A-1. simse is a product of Telor. Our privacy contact is privacy@telor.dev.

1. The list

Six companies. Each one processes your data only on our instructions, and we remain fully liable to you for what they do with it.

Each is covered by a written data processing agreement with obligations no less protective than the ones we owe you — except where the last column of a row says otherwise, in which case that row governs and this sentence does not apply to it. Today there are three such rows, and each is named there rather than left for you to find: Cloudflare, whose data processing addendum reaches every leg we use but whose acceptance for our account we have not yet confirmed and filed; Amazon Web Services, which delivers our sign-in, account, security and billing email; and Anthropic, the provider designated to generate every assistant response, whose agreement attaches to a commercial API account that we hold but that is unfunded and not in use.

Notes on the table

• "Where" is the primary processing region. Several of these companies run global infrastructure and may process data in transit through other regions, consistent with their agreement and the safeguard named above.
• Transfers. Where personal data originating in the EEA, the UK or Switzerland reaches a sub-processor in the United States, the transfer runs on the instrument in the last column. We rely on the Standard Contractual Clauses and the UK Addendum as the durable mechanism, not on the EU–US Data Privacy Framework. Where a sub-processor is additionally certified under that Framework, we treat it as an extra safeguard, not as the basis for the transfer.
• The Amazon Web Services row. This is the one row where we cannot tell you the agreement is in force, so we tell you that instead. The AWS GDPR Data Processing Addendum is a standing published instrument that attaches by accepting the AWS Customer Agreement — there is nothing to negotiate. What we have not yet done is confirm which account holds the verified sending identity for our mail domain and file the record of that agreement's state. Until we have, this page does not claim the transfer is covered, and we will not say it is. When the confirmation is filed we will update this row and record the change in Section 7. If it turns out that account is not ours, the company named on this row is the wrong one and we will correct it — that correction, not a silent edit, is what Section 7 is for.
• The Anthropic instrument, and the credential it depends on. The clauses in the last column are carried by the provider's data processing addendum, which its commercial terms incorporate and which takes effect on first access to the API under a commercial API account. They do not attach to consumer or subscription access to the same models: that class carries no addendum, no clauses, no processor relationship and no retention or training term. A credential of the second class is provisioned on our inference path, as of 2026-09-15. The key the platform reads for it was declared blank on purpose until then, in the deployment configuration that is our source of record for every credential the platform holds; a consumer-subscription credential has now been issued against it, and the path serves. We hold a commercial API key as well and it cannot serve — it has no credit balance — so the clauses in that column are still not in force, and we say so rather than let the column imply otherwise. No customer content has been sent to the provider: the platform holds no customer accounts. Our commitment is that customer content will be processed through this provider only under a commercial API credential governed by that addendum — clause 15.3 of the Data Processing Agreement states it as a condition, and Section 16.3 of the Terms of Service states the same fact from the retention side. This row is completed at publication alongside the effective date at the top of this page.
• What the inference provider keeps. Under a commercial API account, Anthropic deletes the inputs and outputs of an API request within 30 days. That window is a term of the commercial account, and ours is unfunded and not in use, so it is not a term we can tell you governs our calls. Under consumer or subscription access to the same models no retention term exists at all. Either way, because our outbound request carries no end-user identifier, a deletion request to us cannot be scoped to your requests at the provider. This is set out in full in Section 5 of our Privacy Policy and clause 15.3 of the DPA.
• The mail path. Every email we send leaves our cluster through our own dispatch service, which runs on Cloudflare, and is then handed to the provider for that kind of mail: Amazon Web Services for sign-in, account, security and billing mail; Resend for product and newsletter mail; Google Workspace for mail sent by a named person at simse. We name every provider we direct mail to, and Cloudflare is on this list because our dispatch service runs on its compute and therefore sees the full message.
• The backup path. Our databases are backed up continuously, and the copy is written off our own hardware to Cloudflare R2 — one storage bucket per database cluster, plus one for the analytics warehouse and one for the object store that holds your files. That is deliberate: a backup on the same machine as the database does not survive losing the machine. It also means Cloudflare holds a complete copy of everything those stores hold. Each bucket has its own retention window; Annex I, section D of the Data Processing Agreement gives the window for each store. Nothing removes one person from an archive that already exists — an archive is not edited, it expires. Section 6 says which stores this reaches and the one it does not.
• Certifications, and what we have actually collected. Stripe is certified PCI-DSS Level 1 and publishes SOC 2 Type II and ISO 27001. Cloudflare publishes SOC 2 Type II, ISO 27001 and ISO 27018, and is PCI-DSS certified. Google publishes SOC 2 Type II and ISO 27001, 27017 and 27018. Amazon Web Services publishes SOC 2 Type II and ISO 27001. Anthropic publishes a SOC 2 report. Resend publishes SOC 2 Type II. That list is what each company publishes. It is not a statement that we hold a copy: this is the first publication of this page, our first annual collection cycle runs from the effective date above, and we have not yet collected and filed a current report for every company here. We will not describe a report as collected before it is.

2. Before a company reaches this list

This is the standard we hold ourselves to, and Section 2.1 says where we have not met it. We assess every prospective sub-processor before any customer personal data flows to it. All of the following must be in place first:

• a written data processing agreement with obligations no less protective than the ones we owe you;
• a valid transfer mechanism for any restricted transfer, with a transfer impact assessment where the destination has no adequacy decision;
• a current security attestation — SOC 2 Type II or ISO 27001 at minimum, and PCI-DSS for anything touching payment data;
• a data-minimisation review, so the company receives only what its job needs;
• the company's own commitment to publish and notify changes to its sub-processors;
• contractual return-and-deletion of data on termination, with a deletion deadline.

We review every company on this page at least annually, and out of cycle on any material trigger — a security incident, a change of ownership or sub-processing, a lapsed certification, or a new category of data being shared. That annual cycle begins at the effective date above; no review under it has fallen due yet.

2.1 Where we have not met it

Two paths were switched on before that assessment was run. We have since run it on both, and this section records what it returned rather than only that it is now done.

Outbound transactional email — how a sign-in link reaches you. On the Cloudflare hop, which is our own dispatch service running on Cloudflare's compute, every criterion is met except one: confirmation that the agreement is accepted on that account, which we have not yet filed. On the Amazon Web Services hop, two are open: the agreement is identified but its acceptance for the sending account is not yet confirmed and filed, and we have not yet collected the current security attestation. Both are described on that row and in the notes above.

We considered suspending that path until the two close. We did not, because it carries one of the two ways into an account, and taking it down would take sign-in with it. That is a decision we made rather than a technicality, and this is where we record it.

Model inference. This is the row where the most is open, and we would rather set it out than average it into the sentence above. Anthropic's agreement and transfer clauses attach to a commercial API account on first use. We hold one and it has no credit balance, so it cannot serve; the credential provisioned on our inference path since 2026-09-15 is a consumer subscription, so that path serves but not under the instrument. The instrument is therefore identified rather than in force, and we do not represent this transfer as safeguarded. On top of that, the assessment itself was not done as a recorded step with a named approver before the first request was made, and the security report, which Anthropic publishes, has not been collected. The first is a contractual gap and the other two are gaps in our own process; all three are ours to close, and the first is the one that has to close before this page is published as written.

For the remaining three companies on this page, we hold the agreement and the transfer instrument for each, and each publishes the attestation named above. Our first annual collection cycle, which is where those reports get pulled and filed, runs from the effective date at the top of this page.

3. How we tell you about a change

This is clause 8.4, 8.5 and 8.6 of the Data Processing Agreement, stated here in the same terms.

Notice — at least 30 days. Before we engage a new sub-processor for customer personal data, or materially change what an existing one does, we give you at least 30 days' notice. Notice goes to the email address on your account, and this page is updated at the same time. There is no separate mailing list to join — your account email is the channel.

Objection — 14 days. You may object to a new sub-processor on reasonable, data-protection grounds by writing to privacy@telor.dev within 14 days of that notice. We will work with you in good faith to address the objection. If we cannot do so within 30 days of receiving it, you may terminate the affected part of the service on written notice, without penalty, and we will refund prepaid fees for the unused remainder of the term. An objection not raised within the 14-day window is taken as accepted.

Emergency replacement. If a sub-processor stops providing its service, or suffers a security event that disqualifies it, we may engage a replacement immediately and tell you without undue delay. The replacement is engaged on the same contractual terms, and your objection right runs from that notice.

Leaving the list. When we stop using a sub-processor, we confirm the return or certified deletion of the data it held within its contractual deadline, remove it from this page, and record the change in Section 7.

4. Third parties that are not sub-processors

Five kinds of recipient receive data derived from your content without being our sub-processors. They act on your instruction, at the moment you give it, not on ours — so there is no processing they perform on our behalf, and for one of them there is no fixed company for us to contract with at all. One qualification on "your instruction": on the raw API surface you choose which tools a request may use. In an assistant session you do not choose the tool set — we register it — so what you control there is whether to invoke a tool, not whether it is available. That qualification does not reach the third row: a connector is never registered by us, and exists only because you created it.

If the assistant's web tools are not used, the first two receive nothing; if you register no connector and install no plugin, the third and fourth do not arise at all. The fifth is bounded by what you put in the session workspace and what you ask the assistant to do, rather than by a setting we offer. We have no contract with any of them, and no control over what they do with a request they receive. Treat a web search or a web fetch the way you would treat typing the same thing into your own browser, and treat a connector or a plugin the way you would treat handing the same material to the company that runs it.

Why the connector host and the plugin vendor are not on the list in Section 1. Each is a fixed, named company — unlike a web-fetch target — so the reason they are absent is not that there is nobody to contract with. The reason is that you named them. It processes for your purposes on your instruction, under whatever agreement you hold with it; we neither chose it nor direct it, and we cannot bind it on your behalf. Listing it in Section 1 would tell you we vetted it and stand behind what it does, and we have not and do not. Section 5.5 of the Privacy Policy and clause 5.3 of the Data Processing Agreement draw the same line.

5. Companies we use that never touch your data

We use Atlassian Jira for internal issue tracking, GitHub, Inc. for source control and continuous integration, and Tailscale for the private network our operators use to reach our systems. Tailscale coordinates that network; the traffic on it is encrypted end to end between our own devices, so Tailscale does not see its content. Neither processes customer personal data: our repositories hold source code, and application secrets live outside them. Neither is a sub-processor. If either ever begins processing customer personal data, it moves onto the list in Section 1 first — with an agreement and a transfer mechanism in place before the data flows, and with the 30 days' notice in Section 3.

6. What stays inside simse

Not everything the platform does is sub-processed. The following run on our own hardware, inside our own cluster:

• Embeddings. The vectors used for search, retrieval and adaptive memory are computed in-cluster on hardware we own. Your text is not sent to a third party to be embedded.
• Every application database, the analytics warehouse, the vector store, the object store that holds your uploaded files, and the notification service. The notification service runs in our cluster, but the email it produces is delivered by the companies in Section 1 — see "The mail path" there.

One qualification, because it is the obvious gap in that second bullet. Running on our own hardware is not the same as staying on it. The backup archives of every application database, of the vector store and of the analytics warehouse are written offsite to Cloudflare R2, so a complete copy of each of those stores is held by a sub-processor. That is the Cloudflare row in Section 1 and the "backup path" note under it, and Annex I, section D of the Data Processing Agreement gives the retention window for each store. Since 26 September 2026 the object store that holds your uploaded files is copied offsite every night as well; the one store with no offsite copy is a short-lived key-value cache. The notification service is not an exception either — it keeps no store of its own, writing instead to the application database, so your notification and delivery records, and the permanently-retained bounce and unsubscribe register with the email addresses in it, are inside that database's offsite copy like everything else there. The embeddings above are a statement about computation — your text is not sent out to be embedded — and the vectors that computation produces are in the vector store, which is backed up offsite like the rest.

We do not sell personal data. We do not share it for advertising of any kind. No company on this page is an advertising network or a data broker, and none of them receives your data for its own purposes.

7. Change history

We record every addition, removal and material change here, alongside the notice described in Section 3.

8. Contact

Questions about anyone on this page, or about a change notice, go to privacy@telor.dev.

Related documents: the Privacy Policy, the Data Processing Agreement, the AI Transparency Notice, and the Cookie and Tracking Notice.