Sub-processors
In short: Seven parties can technically see something: Apple (purchases, and TestFlight where you use Device Verification), Cloudflare (website traffic and inbound mail routing), Google (the mailbox that inbound mail lands in), our host (the API, the queue and the build at rest), the model provider (screen content only), our email relay (notification mail), and our own audit machine. Your build binary reaches the audit machine, our host and — for Device Verification — Apple; it is never sent to the model provider. We give 30 days' notice before adding a sub-processor, and you can object.
1. What this page is
Where we process personal data on your behalf (see Privacy Policy, section 12), Article 28(4) GDPR requires us to tell you who else is involved. This is that list. It is exhaustive: if a company is not named here, it has no access to customer data in the ReadyAudit pipeline.
2. The boundary that matters most
Your build binary is never sent to the model provider.
Three parties hold it, and no others: the simulator .app
bundle travels from the macOS app to our API, where our host stores it at
rest for as long as the job is queued, and it is then installed on a
machine we own and control. Where you have enabled Device Verification, a
second copy reaches a physical device we own by way of Apple's TestFlight —
a distribution you initiate, from your own developer account, so Apple
holds it under your agreement rather than ours. It is not uploaded to the
model provider, not written to a cloud object store, and not shared with
any other party in the table below.
What the model provider receives is screen content: the accessibility tree of the screen currently on display, control labels and roles, and — where a judgement must be made visually — an image of that screen. That is a narrower surface than the build, and it is the minimum an audit can work from. Whatever your app renders during the run can be part of it, which is exactly why the Terms require a disposable demo account and non-production data.
3. The list
| Party | Role | What it can see | Location & transfer basis |
|---|---|---|---|
| Apple Inc. | App distribution, payment processing, merchant of record. Also TestFlight, where you have enabled Device Verification. | Your Apple Account, payment method and purchase history — none of which we see. We receive only a transaction identifier and a verification result. Where you invite us as a TestFlight tester, Apple additionally holds the build you distribute to us, under your own developer account — we receive it from Apple rather than sending it there. | United States and worldwide. Apple's own terms and transfer mechanisms apply; Apple is an independent controller for your purchase, not our processor. TestFlight distribution happens under your agreement with Apple, not ours. |
| Cloudflare, Inc. | DNS, TLS and static hosting for readyaudit.dev. Also Email Routing, which receives mail sent to our published addresses and forwards it. | Website request metadata: IP address, requested path, user agent. The site is static, so there is nothing else in the page traffic — no form data, no account, no analytics. Email Routing additionally sees the full content of any message you send us: sender address, subject, body and attachments, in transit. | Global edge network. EU Standard Contractual Clauses and the UK Addendum, under Cloudflare's Data Processing Addendum. |
| Google LLC | The mailbox that mail forwarded by Cloudflare Email Routing lands in, and where it is stored and read. | Everything in a message you send us and in our reply: your address, subject, body, attachments, and the thread history — held at rest until deleted. It sees nothing else: no build, no findings, no credentials, no purchase data. | United States and worldwide. EU Standard Contractual Clauses under Google's data processing terms; Google is also certified under the EU–US Data Privacy Framework. |
| Hetzner Online GmbH | Hosts the API, the job queue and the build at rest while queued. Not yet in service — selected, and named here in advance because you are entitled to know who will hold this before you buy. | Everything stored server-side: the uploaded build, the demo credentials, audit records, access logs. Each record is encrypted under its own AES-256-GCM key before it is written, wrapped with a master key held in the service environment on this same host — so the host is protected against a lost disk or a stray backup, not cryptographically excluded from the data. The boundary is stated in full. | Germany (EU) — processed within the EEA, so no transfer mechanism is required for this hop. |
| Anthropic PBC | Language model API used for the judgement layer of the audit. | Screen content only, as described in section 2 — accessibility tree, labels, roles, and screen images. Not the build. Not your credentials. Not your identity. | Commercial API tier, never a consumer subscription, configured so that never is what happens in respect of model training. SCCs where the transfer leaves the EEA or UK. |
| Brevo (Sendinblue SAS) | Transactional email relay. Not yet in service — selected, and named here in advance because you are entitled to know who will hold this before you buy. | What we hand over is the recipient address and the body of the one notification email per audit — no build, no findings, no credentials. What the relay then does to it is also processing, so: it rewrites the message as HTML, injects its own one-click unsubscribe link, and embeds a 1×1 tracking pixel on a domain it controls, so opening the message tells the relay that this address opened it, along with the IP address and browser or mail client that fetched the image. There is no setting on our plan that removes either one. If you use that unsubscribe link, the relay records your address on a suppression list of its own and stops delivering — a record that outlives our erasure, because it is theirs, not ours, and it is the mechanism by which honouring your opt-out works at all. Mail you send to us does not pass through here; it goes through Cloudflare Email Routing into the Google mailbox, two rows above. | the European Union (France). Our hop to the relay stays within the EEA, so no transfer mechanism is required for it; where the relay then delivers is determined by the address you gave us, and we make no claim about your own provider's location. The notification address is erased on our side the moment the send is attempted — on our side is the whole of that claim: the relay keeps its own send log, and its suppression list if you unsubscribe, under its own retention. |
| Our own audit machine | Runs the build and captures evidence. Hardware we own, in Türkiye. | Everything, for the duration of the run: the installed build, the screens, the credentials, the recordings. | Türkiye — no EU adequacy decision. Not a third party, and listed anyway because a sub-processor page that omits the machine with the most access is not honest. Physically controlled by us; no third-party administrative access. The transfer to it leaves the EEA and relies on the Standard Contractual Clauses and a transfer impact assessment — the reasoning is set out in full. |
4. Who is not on this list
We use no analytics provider, no advertising or attribution network, no
customer data platform, no CRM holding customer records, no session-recording
tool, no chat widget, no crash reporter that transmits off-device, and no
cloud object store for evidence.
Evidence is embedded_in_report, so no screenshot
or recording is ever written to an object store — there is nothing for a
storage provider to hold, and therefore none to name.
5. How we choose them
Before engaging a sub-processor we check that it offers a data processing agreement with terms at least as protective as ours, a lawful transfer mechanism where relevant, and a security posture appropriate to what it will hold. Each is bound by a written contract imposing the Article 28 obligations on it, and we remain liable to you for its performance.
6. Changes and your right to object
We give 30 days' notice on this page before a new sub-processor starts processing customer data, and we move the effective date at the top when we do. If you object on reasonable data protection grounds, write to info@readyaudit.dev within those 30 days. We will try to offer an alternative; if we cannot, you may stop using the service and we will return the value of any unspent credits through the process in the Refunds & purchases policy.
There is no email list to subscribe to for this — deliberately, since that would mean holding your address. Check this page, or ask us and we will tell you the current state.
An emergency replacement — a provider failing, or a security incident forcing a migration — may have to happen faster than 30 days. If that occurs we will say so here, explain why, and your objection right still applies after the fact.
Contact
Buğra Günay, Erzene Mahallesi, 113/28 Sokak No: 8/4, Bornova, İzmir, Türkiye.
One address handles everything — legal notices, privacy and data subject requests, support, security disclosure and accessibility feedback: info@readyaudit.dev. Put the subject in the first line and it reaches the right person.