Privacy Policy

Version: 2.6
Effective: 30 July 2026
Applies to: readyaudit.dev · the ReadyAudit macOS app · the audit service

In short: We process the build you upload, anything visible on its screens while the audit runs, and — only if you choose to give them — a demo login and a notification address. Your build is deleted when the audit completes, and the report records the exact UTC timestamp; the recordings, the source screenshots and the credentials go with it. What we do keep is the measurement itself — the finding rows, the score and the coverage arithmetic — because a later audit has to be able to tell you what you fixed. That record is linked to your audit, so it is pseudonymous rather than anonymous, and you can have it erased. There are no accounts, no analytics, no cookies, no advertising identifiers, and your build is never used to train a model. One thing is not ours to promise: the relay that carries the notification email adds its own unsubscribe link and an open-tracking pixel we cannot switch off, and section 6 says so plainly. Logs that record which IP called the API are kept for 30 days.

1. Who is responsible for your data

Buğra Günay (ReadyAudit), Erzene Mahallesi, 113/28 Sokak No: 8/4, Bornova, İzmir, Türkiye, is the controller for the processing described in this policy, within the meaning of Article 4(7) GDPR and the UK GDPR. Where you upload a build containing personal data belonging to your own users, you are the controller of that data and we act as your processor — section 12 sets out the terms that govern that relationship.

Data protection contact: info@readyaudit.dev. We have not appointed a Data Protection Officer; Article 37 GDPR does not require one for processing of this scale and nature, and appointing a nominal one would be theatre.

We have not yet appointed a representative in the Union. Article 27 GDPR requires one where a controller established outside the EU offers goods or services to data subjects in the EU. We are not going to pretend the question is comfortable: this site is written for buyers in the EU, it argues about EU law, and serving it already means processing EU visitors' IP addresses at the edge. Whether that is enough to constitute an "offering" before a single audit has been sold is arguable, and the argument is not one we are relying on. What is true is that no representative is appointed today. One will be named on this page before the first audit is accepted from an EU customer, and the exemption in Article 27(2) — occasional processing, no special categories, low risk — is not being claimed. We state this rather than omitting the clause, because a missing Article 27 line is exactly what it looks like.

2. The design principle behind this policy

Most privacy policies describe a system that was built first and explained afterwards. This one describes constraints that were chosen deliberately: there is no account system, no analytics on the website, no advertising or attribution SDK in the macOS app, and no persistent store of your build. That is not modesty. It is the shortest route to a policy we can keep.

The practical consequence is that most of the questions this document would otherwise have to answer — how to delete your profile, how to opt out of tracking, which ad networks receive your identifier — have no subject matter. One does: the notification email carries a tracking pixel our mail relay inserts and we cannot remove, so section 6 tells you what it does and how to stop it rather than pretending the question does not arise.

There is one thing we deliberately do not throw away, and it belongs here rather than buried in a table. An audit produces two different kinds of data: the evidence (your build, the recordings, the source screenshots, the credentials) and the measurement (the finding rows, the score, the coverage arithmetic). The evidence is destroyed with the run. The measurement is kept, because an audit you buy a second time is worth paying for only if it can tell you which findings you actually fixed. Section 3 lists exactly what that record contains, section 8 explains what is derived from it, and section 9 tells you how to have it erased.

3. What we process, why, and for how long

The table below is exhaustive for the audit service and the macOS app. If a category is not listed, we do not process it.

Processing register — ReadyAudit audit service and macOS app.
Data	Why	Legal basis (GDPR Art. 6)	Kept until
Your uploaded build (simulator `.app`, zipped)	To install and drive the app so the audit can be run at all.	6(1)(b) — performance of the contract you entered by spending a credit.	Deleted at `audit_completed`. A failed run holds it for a 72-hour retry window, then the same deletion applies.
Demo account credentials (optional)	To reach screens behind a sign-in wall. Held in the job record, used by the run and nothing else — see section 11 for how that is and is not protected.	6(1)(b).	`run_only` — Demo credentials live until this run reaches a terminal state — a delivered report or a failed run — and never longer than 72 hours. Never written to logs or the report.
Screen recordings and screenshots produced during the run	To capture what the app actually did, so a finding can be shown rather than asserted.	6(1)(b).	Evidence is `embedded_in_report` — it lives inside the document we deliver, and no server-side copy is retained after the run. The source recordings are destroyed with the build.
Findings — the measurement, kept after the run	To build your report; to tell you on a later audit which findings you fixed and which are new; and — de-identified — to produce category benchmarks.	6(1)(b) for your report and for comparing your own audits; 6(1)(f) legitimate interest for de-identified benchmarks (section 8).	Kept after the run. Unlike everything above it in this table, this record is not destroyed with your build. The fields are exhaustive — `rule_id, verdict, severity, layer, module, category, framework, device_variant, environment, wcag_reference, run_timestamp, audit_id` — and it contains none of the following: screenshots, video frames, element text, accessibility labels, credentials, build bytes, and any pointer that could retrieve a destroyed artifact. It is linked to your audit and Device Token, so it is pseudonymous, not anonymous. Erased on request; see section 9.
Device Token	A random UUID generated on your Mac and stored in your Keychain. It is how the server knows which credit balance is yours. It is not derived from any hardware identifier and does not identify you personally.	6(1)(b).	For as long as you have a balance or an audit history to look up. Deleting the app's Keychain item ends it — and, as section 9 warns, ends your access to the balance.
Apple transaction identifier	To verify with Apple that the purchase is real before crediting your balance, and to answer a support request about it later.	6(1)(b), and 6(1)(c) legal obligation where tax or accounting law requires a purchase record.	For the period the applicable accounting law requires.
Notification email address (optional)	To send you exactly one message when your audit is done. It is not a signup and creates no account.	6(1)(a) consent — you type it or you do not.	Erased the moment the send is attempted, whether the send succeeded or failed. There is no endpoint that can read it back. That is our copy; our mail relay keeps its own send log, and a suppression entry if you use the unsubscribe link it adds — section 6.
Support message and reply address	To answer you.	6(1)(b), or 6(1)(f) for pre-sales questions.	The API stores nothing — no row, no logged text. The message is relayed to our mailbox and lives there under section 6.
App version and macOS version	Attached to a support message so we do not have to ask you which build you are on.	6(1)(f) legitimate interest in answering support competently.	With the support message.
Server access logs (method, path, status, duration, client IP)	To keep the service up, and to detect and stop abuse.	6(1)(f) legitimate interest in security and availability.	30 days, then rotated out. Logs never contain your build, your credentials, your notification address or the text of a support message.

4. The macOS app specifically

The App Store privacy label for dev.readyaudit.mac and the PrivacyInfo.xcprivacy manifest inside the app declare four collected data types. All four are used for app functionality only, none of them is used for tracking, and all four are declared linked to your identity:

Device ID — the Keychain UUID described above, which doubles as the StoreKit appAccountToken so Apple can tie a purchase to a balance without telling us who you are.
Email address — optional, per audit, erased on send (section 3).
Other user content — the build you upload and the text of a support message.
Purchase history — the Apple transaction identifier, which we store so a credit cannot be redeemed twice and so we can answer a billing question later.

Why "linked" and not "not linked". Apple's label has one question that most apps answer casually, and the honest answer here is the unflattering one. We do not run accounts, so it is tempting to say there is no identity to link anything to. But if you give us a notification address, that address is stored on the same audit record as your Device Token, the build you uploaded and your transaction identifier, and nothing strips it first. Apple's own rule is that data covered by privacy law as personal data counts as linked, so all four types are declared linked — including the two that involve no e-mail at all, because on our side they sit in the same record as one that might. An earlier version of the manifest said "not linked". That was wrong, and it is recorded here rather than quietly corrected. If the notify address ever moves to storage that cannot be joined back to an audit, this answer changes in all three places at once or in none of them.

The app declares no tracking domains, contains no analytics SDK, no advertising SDK and no crash reporter that transmits off-device. Its only declared required-reason API use is UserDefaults, under reason CA92.1 — reading and writing settings for this app alone.

If Apple's label and this page ever disagree, treat it as a bug and tell us. The manifest, the App Store Connect labels and this section are three copies of one promise, and three copies is already one too many. Report the divergence to info@readyaudit.dev and we will correct whichever one is wrong.

5. The website specifically

readyaudit.dev sets no cookies, runs no analytics , embeds no third-party scripts, no social widgets, no chat bubble, no tag manager, no session recorder and no advertising pixel. Fonts are self-hosted, so loading a page makes no request to Google Fonts or any other third party. There is no form on the site that collects personal data.

You do not have to take our word for it: open the Network tab in your browser's developer tools and reload any page. Every request should be to readyaudit.dev. The cookies and tracking page explains the two exceptions — an infrastructure cookie our CDN may set for bot protection, and the tracking pixel our mail relay puts in the one notification email — and how to check for both.

6. Email we hold

Two kinds of email exist. The notification address attached to an audit is erased server-side on send (section 3). A support message you send us lives in our mailbox, because that is what a mailbox is. We keep support correspondence only for as long as it is useful for the matter it concerns and for any subsequent dispute about it, and we do not add support addresses to a marketing list — we do not operate one.

What our relay adds, which we do not control. We do not run a mail server. The notification is handed to a transactional relay, named on the sub-processor page, and it does not send our message unmodified: it converts the body to HTML, injects its own one-click unsubscribe link, and embeds a 1×1 tracking pixel on a domain it controls. Opening the message therefore tells the relay that this address opened it, with the IP address and mail client that fetched the image. There is no setting on our plan that removes either, so it is stated here instead of being left for you to find.

Two consequences worth knowing. Blocking remote images in your mail client stops the pixel and costs you nothing, because the report is in the app and the email is only a pointer to it. And if you use that unsubscribe link, the relay puts your address on a suppression list of its own and stops delivering — a record held under the relay's retention, not ours, which is the mechanism by which your opt-out is honoured at all. Our own erasure is unaffected and still happens on send; what we cannot do is reach into their logs, so we do not claim to.

7. What is sent to the model provider

Part of the audit is performed by a language model reached over a commercial API, operated by Anthropic PBC. This is the single most misunderstood part of the pipeline, so it is worth stating precisely:

Your build binary is never sent to the model provider. The .app bundle goes from our macOS app to our API, sits at rest with our host for as long as the job is queued, and is installed on a machine we control — three places, all named on the sub-processors page, and no others. Where you have enabled Device Verification, Apple also holds the build you distribute to us through TestFlight, under your own developer account. Beyond those, it goes nowhere. What is sent to the model provider is a textual description of the current screen — the accessibility tree, control labels and roles, and, where the screen must be judged visually, an image of it. This is the same material a person sitting in front of the app would see.

The API used is a commercial API tier, never a consumer subscription, and it is configured so that never is what happens with your content in respect of model training. We do not fine-tune, evaluate or otherwise reuse your build or its screens.

The honest limit. If a screen of your app is on the display while the audit runs, its contents can be part of what is sent. That is unavoidable — an audit that cannot see the screen cannot audit it. This is why the Terms require you to test with a disposable demo account and non-production data, and why you should not point ReadyAudit at an environment containing real customer records.

8. Benchmarks and research

Benchmarks are built from a projection of the retained finding record, not from the record itself. We take the rows described in section 3, strip the link to your audit and your Device Token in a one-way step, and aggregate only what is left — for example, the share of finance apps in a sample that fail a given contrast rule. Our legitimate interest under Article 6(1)(f) is in producing industry data that makes the product's claims checkable; weighed against it, the impact on you is minimal because the published output cannot be traced back to your app.

Which half is anonymous, stated precisely. Only the benchmark projection is de-identified (de_identified_aggregate). The finding record it is derived from stays linked to your audit (audit_id_and_device_token) and is therefore pseudonymous personal data for as long as we hold it — which means your rights in section 9 apply to it in full. We say this the unflattering way round on purpose: calling the stored rows "anonymous" would be convenient for us and would not be true.

prohibited is the rule: no individual customer, application, screen or finding is ever published or shared in identifiable form.

You can opt out, before or after the fact, at no cost. Email info@readyaudit.dev with your Apple transaction ID and we will exclude that audit's findings from every benchmark. There is no charge, no form and no consequence for your report or your credits. This is also your Article 21 right to object, exercised without argument.

9. Your rights, and how they work without an account

Where the GDPR or UK GDPR applies you have the right to access your data, to have it corrected, to have it erased, to restrict or object to processing, to data portability, and to withdraw consent at any time without affecting processing already carried out. Where the CCPA/CPRA applies you have the rights to know, delete, correct and opt out — and we do not sell or share personal information as those terms are defined, have never done so, and operate no cross-context behavioural advertising.

Because there is no account, we need a handle to find your data. Use your Apple transaction ID (visible in the app and in your Apple receipt) or your audit ID. Write to info@readyaudit.dev. We respond within 30 days, and will tell you before that if the request needs longer.

Two consequences of having no accounts, stated plainly. First, if you lose the Keychain item on your Mac, we cannot identify you from a name or an email — recovery goes through the Apple receipt and support, and it may fail. Second, an erasure request is partly already satisfied by the time most people ask: the build, the recordings, the screenshots and the credentials are gone with the run and there is nothing left to delete. What is still there, and what we will actually delete on request, is the finding record from section 3 — the rows, the score and the coverage arithmetic. Deleting it is irreversible and it costs you the ability to compare a future audit against this one, so we will tell you that before we do it, then do it if you still want it. The only thing we cannot delete is the purchase record we are obliged to keep for accounting. We will say exactly which of these applies to you rather than sending a form letter.

Under Article 77 GDPR you may complain to the supervisory authority in your own country of residence or place of work, or where you consider the infringement took place. That is the route to use, and you do not need to come to us first. Separately, because we are established in Türkiye, we are subject to the Turkish Personal Data Protection Authority (KVKK) under Turkish law; it is not a GDPR supervisory authority and complaining to it is not a substitute for the right above.

10. International transfers

The website is served by Cloudflare from a global edge network. The API and job queue will be operated in Germany (EU) by Hetzner Online GmbH — selected, but not yet in service, because the audit service is not accepting audits yet. Some of our sub-processors — notably the model provider and Apple — process data outside the EEA and the UK.

The audit machine is in Türkiye, and Türkiye is not covered by an EU adequacy decision. The machine that installs your build, drives it and captures the evidence is hardware we own, located in Türkiye. There is no European Commission decision under Article 45 GDPR finding that country adequate, so every transfer of customer data to it is a transfer to a third country. It is made under the European Commission's Standard Contractual Clauses, module three where we act as your processor, supported by a transfer impact assessment and by the fact that the data reaching the machine is deliberately minimal: a build you chose to send, a disposable demo login you chose to create, and screens rendered from non-production data the Terms require.

We are telling you this in the first paragraph rather than the last because it is the kind of fact a buyer is entitled to weigh before purchase, not discover during a vendor review. If your own compliance posture rules out third-country processing, say so before you buy — the answer today is that we cannot accommodate it, and we would rather lose the sale than discover the constraint after your build is already on the machine.

Where any other transfer leaves the EEA or the UK, it is likewise made under the Standard Contractual Clauses (and the UK International Data Transfer Addendum where the UK GDPR applies), or under an adequacy decision where one covers the recipient. The sub-processors page names each recipient, the country, and the transfer mechanism relied on.

11. How it is protected

In transit, TLS terminates at the edge and the API is not reachable in plaintext. At rest, every record the API writes is encrypted before it touches the disk — your build, the job payload including any demo credentials you gave us, the report, and the credit ledger. Each record gets its own AES-256-GCM key, and only that key is wrapped with the host's master key, so no two audits share a key. Authentication is part of the format: a record that has been altered fails to open rather than opening as something slightly different. Filesystem permissions still restrict the files to the service account, and the host volume is encrypted too, but neither of those is what the sentence above rests on any more.

What that does not protect against, stated plainly. The master key lives in the service's environment on the same host as the data it unlocks, because there is no hardware security module and no key-management service in front of it. So this defends your material against a lost disk, a stray backup, a snapshot, a decommissioned volume, and an operator opening files they have no business opening. It does not defend against someone who has already taken control of the running host — they would have both halves. Anyone whose threat model needs the stronger version should ask us before buying rather than after, and the security page carries the detail.

Your report link is the credential. There are no accounts, so your audit is reached by an unguessable address instead: 122 bits of randomness, which is not a number anyone arrives at by trying. Anyone holding that address can read that audit and its report, and that is deliberate — it is what lets you forward findings to a developer or a client without us issuing them an account. So the link deserves the same care as the report: whoever you send it to can read all of it. We never publish these addresses, and there is no endpoint on this service that lists your audits to anyone, so the only way to a report is to already hold its link. Ask us and we will erase the audit, which takes the link with it.

Access to production is limited to people who need it to operate the service. Deletion is performed by the state machine at audit_completed and stamped in your report, so it is checkable rather than promised.

No system is beyond compromise. If you believe you have found a vulnerability, write to info@readyaudit.dev. We do not threaten good-faith security researchers. The security page sets out the technical detail.

Breach notification. If a personal data breach occurs that is likely to result in a risk to individuals' rights and freedoms, we notify the competent supervisory authority within 72 hours of becoming aware of it, as Article 33 requires, and notify affected customers without undue delay where Article 34 applies. Where we are acting as your processor, we notify you without undue delay so that you can meet your own deadline.

12. When we are your processor

If your build or its screens contain personal data belonging to your users, we process it on your behalf. In that case, and to the extent Article 28 GDPR applies, the following terms bind us and form part of our contract with you:

We process that data only on your documented instructions — the audit you requested is the instruction — unless required otherwise by law, in which case we tell you first unless the law forbids it.
Everyone we allow to process it is bound by confidentiality.
We apply the measures in section 11.
We engage the sub-processors listed on the sub-processors page, and give 30 days' notice before adding one, with a route to object.
We assist you, so far as is reasonable, with data-subject requests, DPIAs and consultations with an authority.
We delete the data at audit_completed — deletion is the default here, not something you have to ask for at the end of a contract.
We make available the information reasonably needed to demonstrate the above, and will answer a security questionnaire.

Read this before you upload. The clean way to use ReadyAudit is to give it a build wired to a test environment and a disposable demo account, so that no real personal data is present at all and section 12 never has to do any work. We strongly recommend it. If you upload production data anyway, that is your decision as controller.

13. Children

ReadyAudit is a business tool sold to developers and agencies. It is not directed at children, and we do not knowingly process the personal data of anyone under 16. If you believe a child's data has reached us through an upload, write to info@readyaudit.dev and we will delete it.

14. Automated decision-making

The audit produces a score and a set of findings by applying rules and model judgement to your app. That is automated processing, but it produces no legal or similarly significant effect on any individual within the meaning of Article 22 — it is an assessment of software, not of a person. No decision about a person is made by the system.

15. Changes to this policy

We update this policy when the service changes. The version number and effective date at the top of the page always move together with the text; we do not edit silently. Material changes are announced on this page at least 14 days before they take effect, and the version in force when you spent a credit governs the processing of that audit.

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.