Security & trust
You're handing us a build and, sometimes, a test login. Here's exactly what happens to both — and how each claim on this page maps to real behavior in the product, not marketing.
We remove the uploaded build from storage as soon as your report is ready, and stamp the exact UTC deletion time into the report itself — you can read it in the app header ("Build deleted — … UTC"). If a run fails, the build is held only for a 72-hour retry window, then deleted the same way.
Use a disposable test account with fake data. Demo credentials live until this run reaches a terminal state — a delivered report or a failed run — and never longer than 72 hours. They are never written to logs or telemetry. Between submission and the run they sit inside the job record, which is encrypted before it reaches the disk under a key belonging to that run alone. The ceiling in that sentence is enforced by the server, not merely stated: a run that reaches no terminal state of its own accord is ended at 72 hours and its credentials are destroyed with it.
Your build, the job record with your credentials in it, the report and the credit ledger are each encrypted with their own AES-256-GCM key; only that key is wrapped with the host master key, so no two audits share a key. The format authenticates as well as encrypts, so a record that has been altered fails to open rather than opening as something slightly different — and a record we cannot read is reported as unreadable, never as empty. The boundary, stated plainly: the master key lives in the service environment on the same host as the data it unlocks, because there is no hardware security module or key-management service in front of it. That protects you 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 protect you against someone who has already taken control of the running host. If your threat model needs the stronger version, ask before buying rather than after.
Every screenshot and the frame from the moment a task failed are embedded in the report we hand you. The originals — including the screen recording the frame was cut from — are destroyed along with your build when the audit completes. We keep no copy, which also means we cannot re-send the evidence later: your report is it.
There are no accounts here, so there is nothing to log into and nothing to log out of. Your audit gets an unguessable address — 122 random bits, not a number anyone can count up to — and whoever holds that address can read the report. That is deliberate: it is what lets you forward your findings to a developer or a client without us issuing them credentials. The trade is real and it is yours to make: treat the link like the report itself, because anyone you send it to can read everything in it. We never publish these addresses, and nothing on this service will list your audits to anyone — the only way to reach a report is to already have its link. If you want one taken down, ask and we will erase it.
What survives an audit is the measurement: the finding rows (rule_id, verdict, severity, layer, module, category, framework, device_variant, environment, wcag_reference, run_timestamp, audit_id), the score and the coverage arithmetic. That record is what lets a second audit tell you which of your findings you actually fixed, and it is what the benchmark clause in the Terms aggregates. 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 your Device Token, so it is pseudonymous rather than anonymous; only the benchmark projection is de-identified, and you can have your audit excluded from that or erased entirely by asking.
The agent that drives your app will run only on a commercial API tier whose terms prohibit training on submitted content — never on a consumer subscription. That is a deliberate, load-bearing choice: a subscription would void this guarantee, so the constraint is written down before the layer ships rather than after. Your build and its contents are inputs to your audit and nothing else.
Audits run on a dedicated macOS user with FileVault on and no inbound network connections — the worker only polls out. Each run happens on a throwaway simulator clone that is erased and destroyed afterward, so nothing from one audit reaches the next.
Responsible disclosure is welcome. Email info@readyaudit.dev — we'll acknowledge and work with you on a fix.
Technical readiness assessment — not legal advice. Retention config v1.3.0.