Data Processing Addendum
Roles, data categories, our obligations as processor, sub-processors, transfers and the technical measures. Applies to every plan by reference.
Read moreTrust centre · reviewed 2026-10-05
Trust, stated in checkable sentences
A security reviewer should not have to ask for the basics. This page states where your data lives, who can see it, what leaves your tenant, what we have not certified, and links the four documents procurement asks for. Where the honest answer is “not yet”, it says so.
Where your data lives
Hosting and retention
- Location
- Mumbai, India: a dedicated virtual server operated by us, one region. No content delivery network, no second region today.
- Enterprise option
- On-premise or air-gapped deployment with feature parity.
- Backups
- Encrypted before storage, every day, fourteen retained. A restore drill runs every week into a scratch database and checks tables, policies, indexes and row counts against production.
- Log retention
- System and security logs are kept for 180 days in India, as the CERT-In directions require, then deleted.
- Deletion
- Access, correction and erasure requests complete within 30 days; erasure reaches every row held for the subject, and backups expire on their own schedule.
How it is protected
Controls, as implemented
- In transit
- Traffic to the platform on its public domain is served over HTTPS (TLS).
- At rest
- Credentials and secrets in the vault are encrypted with AES-256-GCM. Backups are encrypted before they leave the server.
- Tenant isolation
- Every tenant’s rows are isolated by PostgreSQL row-level security, enforced in the database in addition to application-level checks.
- Identity
- Passkeys (WebAuthn) and two-factor authentication on every plan; single sign-on on Enterprise; access granted per feature; sessions visible to the workspace admin.
- Audit trail
- Administrative actions and every privacy operation (export, erasure, consent change) are written to a tamper-evident, hash-chained audit log.
- Releases
- Every deployment is health-gated with the previous image kept for an immediate rollback.
- Capture-time redaction
- Recognised credentials and secrets are redacted when a recording is captured, not when it is exported.
AI and your data
Test selection, locator healing, page analysis and document answers run on local open-source models inside the platform. No code, test data or prompt is sent to OpenAI, Anthropic, Google or Meta, and no customer data is used to train any model. Model outputs are never presented as confirmed findings: a security finding is confirmed only by the evidence attached to it, and a proposed heal waits for a person.
The one path that leaves the platform is the LLM testing surface, which forwards prompts to the provider whose API key you supply. Those calls run under your agreement with that provider; the platform records the call, the cost and the detector findings, and never stores your key in plain text.
Security testing you can defend
Active scans run only against targets whose ownership you have proven: a DNS record, a token file at a well-known path, a meta tag, an email or an API callback. Exploitation steps require an explicit, signed authorisation record for the target, are decided on the server rather than by an agent, and every skip or exploit decision is written to the audit log. A finding is reported as confirmed only with the request, the response and a proof of concept attached; everything else is an observation that never fails a gate.
International transfers, by your regime
India has no adequacy decision from the European Commission or the United Kingdom. The table lists the instrument we sign with you at contract stage; it is the same table the Data Processing Addendum carries.
| Your regime | Instrument we sign | Notes |
|---|---|---|
| United Kingdom (UK GDPR) | International Data Transfer Agreement, or the EU SCCs with the UK Addendum | A transfer risk assessment is completed with you; the Data (Use and Access) Act 2025 test applies from February 2026. |
| EU and EEA (GDPR) | Standard Contractual Clauses (Decision 2021/914), Module Two, controller to processor | A written transfer impact assessment is required; we provide our part, covering the Indian legal environment. |
| Canada (PIPEDA, Quebec Law 25) | This addendum plus a comparable-level-of-protection clause | Quebec requires a privacy impact assessment on your side before the transfer. |
| Japan (APPI) | An APPI-specific processing agreement | The EU clauses alone are not sufficient under the APPI. |
| Singapore (PDPA) | Transfer clauses in this addendum | The transfer limitation obligation is met by the recipient’s controls; the annex below is the evidence. |
| United States | None required by federal law | State privacy laws may require this addendum; no US law restricts the transfer to India. |
| India (DPDPA) | This addendum | No instrument is required for processing in India. |
What we have not certified
We hold no SOC 2 report and no ISO 27001 certificate. Our controls are aligned with the SOC 2 trust criteria, we answer security questionnaires in writing, and we share the evidence we hold. We publish this because an unheld certification on a vendor page is a false claim, and because a reviewer who finds the gap themselves stops trusting the rest of the page.
Documents for procurement
All public, all dated. None of them has to be requested.
Service levels
What we commit to on availability, maintenance and support response, by plan, and what we do not publish yet.
Read moreSub-processors
The two providers that process customer data today, what each sees and where, and how a change is announced.
Read moreVulnerability disclosure policy
How to report, what is in scope, our response targets and the safe harbour for good-faith research.
Read morePrivacy Policy
What we collect about you and your users, the legal basis, retention, your rights and the grievance route.
Read moreTerms of Service
The agreement every plan runs under, including the authorised-testing rules and section 5 on service levels.
Read moreAccessibility statement
Our own site’s conformance, stated as partial, with the gaps named and dated.
Read moreVendor evaluation checklist
Thirty questions a procurement, security or QA lead asks, with our own answers, including the five we cannot answer yes to.
Read moreStatus and disclosure
The status page shows the platform state without an account, so it can be read during an incident that affects sign-in. Security researchers can read the disclosure policy or fetch /.well-known/security.txt.
Questions security reviewers ask
Where is our data stored?
On a dedicated virtual server in Mumbai, India, operated by us, in one region. Enterprise customers can run the platform on-premise or air-gapped with feature parity. We do not use a content delivery network or a second region today.
Does any of our code, test data or prompts go to an external AI provider?
Not by default. Test selection, healing, analysis and document answers run on local open-source models inside the platform. The one exception is the LLM testing surface, which forwards prompts to the provider whose API key you supply, under your agreement with that provider. No customer data is used to train any model.
Are you SOC 2 or ISO 27001 certified?
No. We hold no SOC 2 report and no ISO 27001 certificate, and we say so rather than imply otherwise. Our controls are aligned with the SOC 2 trust criteria; we answer security questionnaires in writing and share the evidence we hold, including the vendor evaluation checklist with our own answers.
Will you sign a data processing agreement and transfer clauses?
Yes. The Data Processing Addendum applies to every plan by reference and is countersigned for Enterprise agreements. Transfer instruments (the UK IDTA or Addendum, the EU Standard Contractual Clauses with a transfer impact assessment, APPI terms for Japan) are signed with you at contract stage. No EU or UK representative under Article 27 has been appointed yet.
How do you stop someone scanning a system they do not own?
Active security tests run only against targets whose ownership has been proven by a DNS record, a token file at a well-known path, a meta tag, an email or an API callback. Exploitation steps need an explicit, signed authorisation record and are decided on the server, never by an agent on its own, and every decision is written to the audit log.
What happens to our data if we leave?
You export it first: recordings as Playwright, Selenium or Robot Framework code, API collections in open formats, load profiles as k6, JMeter or Locust, and your account data through the self-service export. After the retention period in the Privacy Policy we delete it, including from backups as they expire.
How do we report a security vulnerability?
Through the contact form with the topic set to security, or the address in our security.txt. The disclosure policy states the scope, the first-response targets (24 hours for critical issues) and the safe-harbour commitment. We do not run a paid bug bounty programme.
Do you have an uptime SLA?
Self-serve plans have no numeric uptime percentage, because we have not yet accumulated the audited uptime history that would make one honest. Enterprise agreements carry a contractual availability commitment with service credits. The public status page shows the platform state without an account.
Send us the questionnaire
Answers come in writing from the people who build the platform, within one business day, including the ones where the answer is not yet.