This is a superseded version. It is kept at a permanent address so the text in force on a past date can be produced. It is not the current policy — read the current sub-processors instead.

Sub-processors — version 1.9
In effect from 2026-09-24. Supersedes version 1.8. Previous versions remain available at /legal/subprocessors/versions/.

Sub-processors

Version 1.9 · In effect from 24 September 2026 · supersedes 1.8

Aporta Systems, LLC uses the providers below to deliver the Service. Each is engaged under a written data processing agreement, and we remain responsible to our customers for what each of them does.

For two of them that sentence needs a qualifier, and we would rather give it here than let the sentence cover something it does not. The Google LLC row below covers two parts of the Service, and both are switched off for every customer. For the first, answering a question through Google’s Gemini model, we have now opened the account and read that provider’s published terms, and the row below is filled from them. What we have not established is whether the written agreement those terms describe has been accepted on our particular account: it is a document that takes effect when a customer accepts it or when it is written into the contract, rather than simply by using the service, and we have not confirmed which of those happened for us. We are checking, and we say so here rather than letting the promise above stand unqualified.

For the second, the delivery of your sealed export into your own storage, the qualifier is wider, and it covers the Microsoft Corporation row as well. We have registered our application with both providers, but we have not yet read which of each provider’s terms govern our application’s calls into your storage, or whether a data processing agreement reaches them. Until we have, we cannot tell you which written agreement covers that purpose, and we would rather say so than let the sentence above answer for it.

We are listing this provider before we turn the feature on instead of on the day we turn it on, so that you can see it coming and object before it starts rather than after.

We give customers at least thirty days’ notice before we add or replace a provider, and a right to object on reasonable data protection grounds. This version adds no provider and replaces none. It gives two providers already on this list, Google LLC and Microsoft Corporation, a second purpose: delivering your sealed export into your own storage.

Provider What it does for us What personal data it can reach Location
Cloudflare, Inc. Edge compute; storage of audit records; DNS and email routing; cookieless analytics on this website and in the Aporta dashboard Encrypted audit records; tokenized content in transit. Prompt text is present unencrypted at the edge for the moment detection runs. Analytics on this website and in the dashboard are aggregate only, with no cookie and no visitor identifier. United States
Modal Labs, Inc. Second-tier detection Prompt text and extracted attachment text, in the clear, at the moment of detection. Processed in memory and not retained. A customer can turn this tier off. United States
Turso (ChiselStrike, Inc.) Per-customer vault and metadata databases Encrypted token-to-value mappings; account metadata; and, where a customer connects an export destination, the encrypted credential for it United States
WorkOS, Inc. Sign-in, directory and role assignment Names, work email addresses, role assignments. No prompt content. United States
Resend (Plus Five Five, Inc.) Delivers one message, and only one: the email telling your administrators that browsers are waiting to be enrolled The work email addresses of those administrators, because they are the recipients — which also tells this provider your domain. The message itself carries a count of how many browsers are waiting and how long the oldest has waited. No employee names, no prompt content, no token mappings, no audit records, no account identifiers. Delivery metadata is held by the provider under its own terms. United States
Microsoft Corporation Business email, document storage and support correspondence. A second purpose, separate from the first: delivering your sealed export into your own OneDrive, when you connect it. We write it into one app folder there, at your direction, using a credential we hold. The permission we ask for is Files.ReadWrite.AppFolder, which reaches that one folder and nothing else in your OneDrive, with offline_access so the connection outlasts the hour an access token lives. This is built and not switched on for any customer, and no request has been made to Microsoft for it for any customer. For email and documents: contact details, and anything personal included in correspondence, contracts or support requests. No prompt content, token maps or audit records. For the export delivery: your sealed export file. It holds your audit record, your token map and any tokenized file copies you chose to keep, all encrypted before the file leaves us. It opens with your recovery code, and Microsoft is given no key that opens it. If your organisation has left its vault key with us rather than holding it itself, we can open the file, and the file says so in its own header. Some of it is not encrypted, because a reader needs it before a key is typed: the file name, which carries our identifier for your organisation and the dates the export covers; a short header on each part, carrying that identifier, your organisation’s name as it appears on your Aporta account, the period, when the part was sealed, and internal storage references that include a device identifier and delivery times; and a list of the parts with their sizes, fingerprints and record counts. Microsoft also sees the file’s size and when it arrives. Email and documents: United States. Export delivery: wherever Microsoft stores your own OneDrive. That is set by your agreement with Microsoft and your account’s settings, not by us.
Stripe, LLC Payment processing and billing Billing contact name and email, subscription and invoice records. Card details go to Stripe directly and are never held by us. No prompt content. United States
Twilio Inc. Operational alerting by text message to our own staff, so that someone is reached when an internal check needs attention. It carries no part of the Service you use. The mobile numbers of the Aporta personnel who receive those alerts, because they are the recipients, and with them this provider’s own message log — a record of who was messaged and when, which is a second surface beyond the message itself. This row is here because the account and the credential exist, not because a message has been sent: as of this version none has been, and no part of our system calls the channel yet. We are not making a statement here about what this provider does not receive. The rule that would make such a statement true is not yet built into the product, and we would rather list a provider plainly than describe a limit that nothing checks. United States (Twilio US1 Region), confirmed in the Twilio Console on 16 September 2026. This provider’s data protection terms do not name a processing location; it depends on the region an account uses, and we checked ours.
Google LLC Answers a question for you when the AI tool you were using is not working. Aporta supports five named tools and blocks or redirects the rest; when our support for one of them breaks, or the tool itself is down, we can answer you through Google’s Gemini model on our own account rather than yours. This is the one place in the Service where we would send your text to an AI provider ourselves. Everywhere else, your text goes from your browser to the tool you chose, under the account you hold with it. This is switched off for every customer. It has never been on in the service our customers use, and nothing from any customer has ever been sent to this provider. We have switched it on in our own test environment, which carries no customer content. A second purpose, separate from the one above: delivering your sealed export into your own Google Drive, when you connect it. We write it into your Drive, at your direction, using a credential we hold. The permission we ask for is drive.file, which reaches only files our application created and nothing else in your Drive. This is built and not switched on for any customer, and no request has been made to Google for it for any customer. What is said above about the answer being switched off is about the answer alone. When it is on: the text of that one request, as it stands after the extension has replaced the values we detected with placeholders — and after we check it a second time at our own edge and refuse to send anything at all if we still find a value in it. We are not telling you that the text we send contains no personal data. We are telling you our detectors found none in it. Detection is not perfect; this dramatically reduces inadvertent exposure rather than preventing it, and this row is where that distinction matters most. The answer comes back with the placeholders still in it. We send the same text twice for each answer — once so the provider can price the request, once to get the answer — along with a fixed instruction of ours that contains nothing of yours. We do not send attachments, earlier messages in the conversation, your token mappings, your audit records, or your name, your employer or any account identifier; the request goes on our key. What this provider records of its own accord, we have now read, and we would rather you heard it from us. It keeps the prompt, anything sent with it, and the answer for fifty-five days, to check its own usage rules — and where something is flagged, authorised staff there may read it. That is the provider’s published policy, not a setting we can turn off, and it is the same fifty-five days whether or not anything is ever flagged. Separately, the provider keeps the technical record of the call — how many words were charged, the network address it came from — on its own account rather than on ours, which is the same arrangement our payment processor has and is worth naming for the same reason. For the export delivery: your sealed export file, and none of what this cell says above applies to it. The file holds your audit record, your token map and any tokenized file copies you chose to keep, all encrypted before the file leaves us. It opens with your recovery code, and Google is given no key that opens it. If your organisation has left its vault key with us rather than holding it itself, we can open the file, and the file says so in its own header. Some of it is not encrypted, because a reader needs it before a key is typed: the file name, which carries our identifier for your organisation and the dates the export covers; a short header on each part, carrying that identifier, your organisation’s name as it appears on your Aporta account, the period, when the part was sealed, and internal storage references that include a device identifier and delivery times; and a list of the parts with their sizes, fingerprints and record counts. Google also sees the file’s size and when it arrives. Not restricted to any country, and not something we can set. We read this provider’s terms on 23 September 2026: they allow it to process the data in any country where it or its own providers have facilities, and there is no region or residency setting on this product for us to choose. Every other row on this list says United States because we either checked our own configuration or read it in the provider’s terms. This one says what its terms actually permit, which is a worse answer than we would like. For the export delivery the answer above does not apply: the file is stored wherever Google stores your own Drive. That is set by your agreement with Google and your account’s settings, not by us.
Amazon Web Services, Inc. Key management. It holds the key that wraps each customer’s data keys — the keys that protect the vault, the audit record, and the credential for your export destination (described below). It holds none of the data those keys protect. In use in production since 24 September 2026. Key material, and one identifier. The wrapping key is generated inside the provider’s hardware and cannot be exported. We send it a data key to wrap or unwrap and nothing else: no prompt content, no token mappings, no audit records, no names and no email addresses. Each request carries our identifier for your organisation (an opaque account ID, not its name), the purpose of the key, and its version. That is how the provider checks a key is used only for what it was issued for, and it means the provider can see which customer’s keys are used and how often. One of those purposes tells the provider that your organisation has connected an export destination, and the call pattern shows how often exports run; it does not tell the provider which storage service you use. Those identifiers appear in the call records kept on our own account with the provider. United States (us-east-1)

One planned use of two providers already on this list

This is not switched on for any customer and nothing has been sent, and we are describing it before it runs — for the same reason we listed the two providers above before we switched them on.

Your sealed export — the copy of your record that opens without us — is meant to arrive on a schedule rather than only when you ask for it. The destination is your own Google Drive or your own Microsoft OneDrive, connected by you and disconnectable by you. It is your storage, under your agreement with that provider.

That does not take either provider off this list for this purpose, and both rows above say so. Your export passes through the provider’s interface, on a connection we hold, into storage the provider keeps for you, and we hold a credential that can write there. We treat Google and Microsoft as our sub-processors for this delivery. That is our own determination, made on 24 September 2026, and not a conclusion from counsel. The rows above say what the file lets each provider reach: its contents are encrypted and its name and part headers are not.

What it would cost you to know anyway, because it is the honest part: to put a file in your storage we have to hold a credential that lets us write to it, for as long as you leave the connection on. We do not read anything else in it, and the permission we ask for is the narrowest each provider offers.

We hold one refresh token per connected provider, encrypted under a key specific to you that is wrapped by the key-management provider above; where we record the account name you connected with, it is encrypted too. Which provider, when it was connected, by whom (an identifier, not an email address) and when it was last renewed are stored unencrypted. With Google the permission reaches only files our application created; with Microsoft, only one app folder. Disconnecting or leaving ends our ability to use the token: disconnecting deletes our copy, and leaving destroys the key that opens it. When you disconnect Google we also ask Google to revoke the permission, and we tell you it was revoked only when Google confirms it. Microsoft gives applications no way to revoke this permission, so you remove it in your Microsoft account. Destroying the key when you leave does not revoke the permission at either provider; you remove it in that account.

We have registered the applications with both providers. The code that calls them is written but not switched on, and no request has been made to either provider for any customer. This page will say so until that changes.

Three things worth saying plainly

One provider on this list is listed before it has received anything from a customer, and on purpose. Google LLC is here for two features, both switched off for every customer, and this paragraph is about the first: the answer through its Gemini model. We built it, we have decided to turn it on, and we have not turned it on for any customer. It is on only in our own test environment, which carries no customer content. We are publishing the row now rather than on the day we switch it on for one reason: a list that gains a provider the same week your text starts going to it gives you no useful chance to object. If you sign with us after today, this provider is on the list you were given, and turning the feature on is not us adding something to it afterwards. If you are already a customer when we turn it on, you get at least thirty days’ notice and a right to object first.

Two of the answers on that row are worse than we would like — where the data may be processed, and how long it is kept — and they are in the row above rather than here, where they belong.

What is left before we turn it on is the account work rather than the reading: confirm the written agreement is in force on our account, point the provider’s notices at a mailbox we watch, ask it what retention options this product actually offers, and publish the matching change to our Privacy Policy.

The part of that we want to be unambiguous: when it is on, your text — the part our detectors did not flag — leaves Aporta and goes to Google under our account. That is a real thing being sent to a real company, not a theoretical capability. Being modest about it would be the dishonest direction, so the row above describes it in full.

Three of these were listed for something other than running the Service. Microsoft holds our email and documents, and once the export delivery is switched on it would also carry that part of the Service for anyone who connects OneDrive; Stripe holds our billing; Twilio carries alerts to our own staff. Personal data reaches all three. They are listed for the same reason as the providers that run the Service — a provider holding your correspondence or your invoices is handling your personal data as surely as one running our servers, and a list covering only the second would be a list chosen to look short.

Our payment processor is not purely acting on our instructions. Stripe uses payment data on its own account for fraud prevention and regulatory compliance, as its own terms describe. That is true of every payment processor and is rarely said out loud.

Their vendors

The chain does not end here.

Our second-tier detection provider operates no physical infrastructure of its own. It schedules work across a pool of cloud providers it publishes. Our configuration fixes the country that work runs in. It does not fix which provider runs it.

The mobile carriers that deliver a text message sit outside the chain we watch. Our messaging provider’s terms state that the telecommunications providers it uses are not its sub-processors. So those carriers do not appear on the list it publishes, and it owes us no notice if they change. That is a limit on what we can see rather than a criticism of the provider — the handset end of a text message is carried by networks that no vendor list enumerates — and we would rather tell you where our visibility stops than let a watched list read as though it covered the whole path.

Each of the others engages its own vendors under its own terms.

Notice we receive, compared with notice we give

We promise our customers thirty days. Five of these providers give us less.

Provider Notice we receive
Microsoft Six months for customer data; thirty days for sub-processors supporting AI features
Amazon Web Services Thirty days
Stripe Thirty days
Cloudflare Thirty days
WorkOS Fourteen days, by updating a page we are responsible for checking
Turso Ten days, by email — and silence for ten days counts as agreement
Modal Thirty days, but it may replace a provider urgently and tell us afterwards
Resend Fourteen days, in writing — and silence for fourteen days counts as agreement
Twilio No fixed period at all. Its terms name no number of days; the whole commitment is to tell us as soon as is reasonably practicable. It does offer a way to subscribe to those notices on the page where it lists its own providers. The right to object runs “during the applicable notice period” — a window defined by reference to a period that is not itself defined — and silence before that window ends counts as agreement
Google Thirty days, and genuinely before the change rather than a window to complain after it. Read from its terms on 23 September 2026. It is also the only provider here that has to send us that notice by email rather than publish it on a page we are responsible for checking. Two things that are not improvements and we are not going to bury them: if we object, the only thing we can do is leave — there is no way for us to refuse one of its providers and keep the service; and the notice arrives at an address we have to designate, which we have not yet done

So for a change that starts in one of those five chains, we cannot give you the thirty days we promise. We would give you what we have, as soon as we have it. For one of them we cannot tell you in advance how much that will be, because its terms fix no period to measure. We would rather say that than promise a chain of notice we cannot enforce.

A note on the newest row, because a good number in that table can hide a bad one elsewhere. Google’s thirty days is the strongest notice term of any provider here except Microsoft’s. It is also the provider whose terms let it process the data in any country, whose objection right is exit rather than refusal, and which commits to no fixed period at all for telling us about a security incident — its promise there is to tell us “promptly and without undue delay”, which is not a deadline. Being at the top of one column does not put a provider at the top of the others, and we would rather point that out than let the table imply it.

The Google and Microsoft entries in that table were read for the purposes each provider was first listed for: the Gemini answer, and our own email and documents. Neither has been read for the export delivery, and we do not assume the same terms govern it.

Not on this list

Software stores. Our extension is distributed through the Chrome Web Store and Microsoft Edge Add-ons. They host a package and report install counts. No prompt content, token map or audit record reaches either, and the relationship each has with someone installing the extension is its own, not one we direct. They matter to us — they gate every release — but they are not sub-processors and we would rather not pad this list with names that hold nothing.

Google appears above and here, for two different things, and we do not want that read as one. The Chrome Web Store hosts our extension and receives no prompt content. The row in the list above covers two different engagements entirely — answering a question through Google’s Gemini model on our account, which does receive your text, and delivering your sealed export into your own Drive, which receives that file. Neither softens the other. The same is true of Microsoft, which runs our email, would deliver your export into your own OneDrive once that is switched on, and is also an extension store.

Questions

privacy@aportasystems.com

Changelog

1.9 — 24 September 2026. Corrects this page’s version history, corrects two statements 1.8 made, and records a change in what four providers do. No provider was added or removed.

Earlier versions of this page said that versions 1.6 and 1.7 had been published. They were drafted and replaced on 23 September 2026 before either one was published. This changelog now says so, and so do the entries for 1.0 and 1.3 below.

Two things 1.8 said were wrong, and we are correcting them here rather than editing 1.8. It said each request to Amazon Web Services carries the name of the customer organisation. It does not: it carries our identifier for your organisation, an opaque account ID, not its name. And it said we had written none of the code for the scheduled delivery of your export. That code is now written. It is not switched on for any customer, and no request has been made to Google or Microsoft for it.

What changed at Amazon Web Services. From 24 September 2026 it is in use in production, not only in staging. It now wraps a third kind of key as well as the ones for the vault and the audit record: the key that protects the credential for your export destination, described under One planned use of two providers already on this list. It still holds none of the data those keys protect. One of the purposes it sees tells it that your organisation has connected an export destination, and the row says so. That section now also says what we store about that credential, what is encrypted and what is not, and what disconnecting and leaving do and do not undo.

What changed at Google and Microsoft. Both rows gain a second purpose: delivering your sealed export into your own Google Drive or your own OneDrive, at your direction, using a credential we hold. This version adds a purpose to two providers already on this list. It adds no provider and replaces none. Version 1.8 described the delivery without saying whether it made either provider our sub-processor. It does. That is our own determination, made by our founder on 24 September 2026, and not a conclusion from counsel. Each row now gives the permission we ask for, says what the file lets the provider reach (its contents are encrypted, and its name and part headers are not), and says where it is stored. The opening of this page gains a second qualifier, because we have not yet read which of either provider’s terms govern this purpose, and the notice comparison says its Google and Microsoft entries were not read for it. The delivery is built and not switched on for any customer, and no request has been made to either provider for it for any customer.

What changed at Turso. The row now says that, where you connect an export destination, the encrypted credential for it is kept in your database there. The section on the export delivery already described that credential. The Turso row did not.

Two smaller corrections. The Google row said the answer through Gemini had never been on. We have now switched it on in our own test environment, which carries no customer content, so the row now says it has never been on in the service our customers use and that nothing from any customer has been sent. And Three things worth saying plainly counted “the five that run the Service”, a number this list had outgrown. It now says “the providers that run the Service”.

1.8 — 23 September 2026. Adds Amazon Web Services, Inc., which holds the key that wraps each customer’s data keys. It is in our staging environment only: production does not use it, and no customer’s data depends on it today. We are listing it from the day the key and the credential exist rather than from the day production depends on it — the same rule we applied to the two providers added before it.

One thing in this row is worth naming rather than leaving a careful reader to find it. Every request we make to this provider carries the name of the customer organisation the key belongs to, along with the purpose and the version of the key. That is how the provider checks a key is used only for what it was issued for, and it is why this row says key material and one identifier rather than key material only. The provider cannot read anything the key protects — no prompt text, no token mappings, no audit records — but it can see which customer’s keys are used and how often. The notice comparison above gains no row: this provider was already named there, against a date that had not arrived until today.

This version also describes something that does not exist yet, under One planned use of two providers already on this list: the scheduled delivery of your sealed export into your own Drive or OneDrive. We have registered the applications with both providers and written none of the code. We would rather you read it here first than find it in a changelog after it starts.

1.6 and 1.7 — not published. Both were earlier versions of the change that added Google LLC. Both were written and then replaced on 23 September 2026 before being published, so neither is held in the archive of previous versions. That change was first published as part of 1.8, and the next paragraphs describe it.

Also in 1.8: Google LLC. Google will answer a question for you through its Gemini model, on our account rather than yours, when the AI tool you were using is not working. This is the one place in the Service where we would send your text to an AI provider ourselves, rather than your browser sending it to the tool you chose. What we send is text our detectors did not flag. That is a smaller claim than text with nothing personal in it: detection is not perfect, and on this row that distinction is the whole point. Google was already named further down this page as an extension store. That is a separate engagement, and neither row qualifies the other. We read Google’s published terms before listing it. Three of the answers they give are worse than we would like. Where the data may be processed: that provider’s terms allow any country where it or its own providers have facilities, and there is no setting on this product for us to narrow it — so this is the only row on the list that does not say United States. How long it keeps what we send: fifty-five days, for prompts, anything sent with them, and the answers, so that it can check its own usage rules, with authorised staff able to read anything flagged. And the technical record of each call — how many words were charged, the network address — is kept by that provider on its own account rather than ours, the same arrangement our payment processor has.

One of the answers is better than we expected and it is in the notice table. That provider gives thirty days’ notice before it adds one of its own providers, in advance of the change rather than as a window to complain afterwards, and it has to send that notice to us by email rather than publish it somewhere we have to check. That is the strongest notice term here after Microsoft’s. It does not make the row a good one overall: if we object, our only option is to leave, and its promise on security incidents fixes no period at all. The comparison table now says five providers give us less than the thirty days we promise you — the same five as before, with nothing left unmeasured.

What is still open, said plainly. The written agreement that governs this provider takes effect on acceptance or by being written into the contract, not simply by using the service, and we have not confirmed which of those happened on our account — so the opening sentence of this page carries a qualifier for this one row until we have. The notices above arrive at an address we have to designate and we have not designated one. The feature is still switched off, has never been on, and nothing has been sent to this provider. Nothing changes for any other provider on this list.

1.5 — 16 September 2026. Fills the one cell version 1.4 published unfilled: Twilio’s location is the United States (Twilio US1 Region), confirmed in the Twilio Console on 16 September 2026. Its data protection terms do not name a processing location, so we confirmed the region our own account uses rather than filling the cell from what is usual. No provider was added or removed, and nothing about what reaches Twilio changes, so the notice comparison above is unchanged and no new thirty-day objection window opens.

1.4 — 14 September 2026. Adds Twilio Inc., which carries operational alerts by text message to our own staff. It is listed from the day its account and credential exist rather than from the day it is first used, and the row says so. Two of the things this version records are not improvements. Its terms set no notice period for a change among its own providers, which is why the comparison above moves from four providers to five and why its entry there carries no number of days; and the mobile carriers that actually deliver a message are outside the chain we watch, which is now stated under Their vendors. One cell on the new row — where processing happens — is published unfilled, because the terms we read did not answer it and we would rather show you the gap than close it with an assumption.

1.3 — not published. This version was prepared on 10 September 2026 and replaced before it was published, so it is not held in the archive. Its one change was first published in 1.4: it corrects our payment processor’s legal name from Stripe, Inc. to Stripe, LLC. Stripe converted the entity on 3 January 2026 and records the change on its own service-providers page; this list had carried the former name since the row was added on 4 September. Nothing about what Stripe does, or what reaches it, changes. No provider was added or removed, so the notice period in the comparison above is unchanged and no new thirty-day objection window opens.

1.2 — 10 September 2026. Adds Resend (Plus Five Five, Inc.), which delivers the enrollment notice described in its row. It has been wired into the Service since that notice was built and appeared on no earlier version of this list; it was found on 9 September 2026 by reading our own code, which is not how a gap in this page should be found. Its location and notice period were taken from its data processing addendum rather than from what is usual, and the notice comparison above changes from three providers to four as a result.

1.1 — 4 September 2026. Added Stripe, Inc. (payment processing) on wiring billing. Added Microsoft Corporation (business email, document storage, support correspondence). Recorded cookieless analytics, on this website and in the dashboard, under Cloudflare’s existing entry. Added the notice comparison above.

1.0 — not published on this site. It was the first version of this list, dated 4 September 2026. The first version published here was 1.1, so 1.0 is not held in the archive.

Generated from docs/governance/legal/subprocessors.md. The source of truth is the governance register in the application repository, not this page.