Security you can check

Data and hosting

• Microsoft Azure, Central US. The database, file storage for run artifacts and test emails, encryption keys, email sending and logs are in that region. SpinUI is operated by an EU company, Digiport OÜ, established in Estonia. Data is stored in the United States.
• Cloudflare in front. Traffic passes through Cloudflare for DNS, TLS, a web application firewall and DDoS protection. The Azure origin accepts only requests that come through Cloudflare.
• Separate by organization. Every customer-owned record carries an organization ID and is filtered by it. Files are stored under per-organization prefixes and served only through the app. An agency’s client workspaces are separate organizations, and someone sees two of them only as a member of both.
• Tested, not assumed. An automated cross-tenant test suite tries to read and write across organizations. It must fail to cross. Tested on every change.
• Encrypted in transit and at rest. HTTPS from your browser and runners to the service. Azure encrypts the database and file storage at rest.
• Secrets. Secrets and webhook URLs are encrypted with a key derived separately for each organization, and the key ring is encrypted by a key in Azure Key Vault with purge protection on. Secrets are masked in logs, results and agent output. Passwords are salted and hashed, and access tokens are stored hashed.
• No database passwords. The service reaches its database, storage and Key Vault through Azure managed identities. The database accepts no password logins, and storage accepts no shared keys.
• Browser protections. The app sends a strict Content-Security-Policy with no inline scripts, cannot be framed by other sites, and sends HSTS for one year.
• Backups. The production database has automatic Azure backups with point-in-time recovery for the last seven days. Backup copies are kept in a second United States region. SpinUI has a written restore procedure, and an automated drill restores a local copy and checks it.

Access and accounts

• Two-step sign-in. Users can turn on two-step sign-in with an authenticator app. It is required for every SpinUI Super Admin, the accounts that run the platform, and it is switched on in production.
• Roles. Organization roles include a read-only Viewer. Sensitive actions ask you to sign in again if your session is not recent.
• Tokens you control. API, CLI, recorder and agent tokens are stored hashed, shown once, scoped, expiring and revocable.
• Share links. A public share link opens one run report and nothing else. It lasts at most thirty days, can be revoked at any time, is stored only as a hash and is rate limited. Public share links are off unless the platform switch for them is turned on.
• Abuse controls. The service rate-limits sign-in, APIs, trigger URLs, runner and mail endpoints, and new accounts must verify their email address before use.
• Audit trail. Security-relevant and administrative actions are logged. SpinUI staff access to customer organizations is limited to Super Admins and goes through an audited operator mode.

The recorder

SpinUI Recorder redacts password and hidden fields, and fields that look sensitive such as one-time codes, in your browser before anything is sent. You pick a stored secret in SpinUI instead. It takes no screenshots, does not read your browsing history, does not read back or upload your cookies or passwords, and has no analytics or tracking code. One limit: a card-number field without an autocomplete value is not redacted, so do not record pages with real card data. See the recorder section of the privacy policy.

Runners and network

• Hosted runs cannot reach private addresses. Tests that run inside SpinUI go through an egress guard that refuses private, loopback and cloud-metadata addresses. The guard checks the address a connection really goes to, not only the one the page asked for. It also blocks service workers and requests that are not http or https.
• Tests cannot read server settings. A test reads variables from your secrets and runner settings. It cannot read the server’s own environment variables, such as keys, tokens and connection strings.
• Private runners only connect out. To talk to SpinUI, a private runner uses outbound HTTPS to your SpinUI address only. It opens no listening port, so you open no inbound ports.
• What a private runner holds. Its credential is limited to your organization and to work addressed to that runner. It receives the secrets a test needs only for that run, in memory, and does not write them to its disk or logs. It has no access to SpinUI’s database, storage or keys, or to other customers’ data.
• Your control. On Windows the installer restricts the runner’s data folder to administrators and its own service account, and its credential is protected with Windows DPAPI. Updates are checked against a SHA-256 checksum from your SpinUI server. You can revoke a runner in Settings at any time.

AI

• Minimised extracts only. Each AI feature sends a small extract, such as step labels, page paths, titles and short text snippets, to Anthropic. The privacy policy lists what each feature sends.
• Never sent. Screenshots, videos, traces, secrets, password values, cookies and test emails.
• Typed field values are sent for suggested checks only if an organization admin turns that on. It is off by default.
• No training, no logging. Under our commercial terms, Anthropic may not use the data to train its models, and SpinUI does not log AI request or response bodies. Anthropic deletes inputs and outputs within thirty days, unless it must keep them longer, for example to enforce its usage policies.
• People approve changes. AI and connected coding agents only propose changes, and a person approves each one. An agent can never change your suites, schedules, environments, secrets, members or plan.

Your data, your control

• Delete in the app. Admins can delete tests, recordings and other test content at any time.
• Retention that cleans up. Run artifacts expire after seven, fourteen or thirty days, depending on the plan. Raw test emails are removed after seventy-two hours. The privacy policy lists every period.
• Export on request. Before an organization is deleted, we provide an export file of its test content and run history.
• Deletion on request. An organization Admin emails support@spinui.com from their account address. The request can be withdrawn during a seven-day waiting period, and deletion is completed within thirty days of the request. On request, we confirm the deletion in writing.

Compliance documents

• Data Processing Addendum. The DPA sets out how SpinUI handles personal data on your behalf, including the security measures in its Annex II, and a notice of security incidents within seventy-two hours.
• Sub-processors. The companies that process data for us are on the sub-processors page. We give thirty days’ notice of a new one.
• Privacy policy. The privacy policy covers what we collect, how long we keep it and your rights, including a section on the recorder.
• Security review. We ran an internal security review of the whole service before launch and fixed every blocking finding.
• Security questionnaires. Send us your security questionnaire through the contact page and we will complete it.
• Service status. status.spinui.com checks SpinUI every five minutes and lists incidents and planned maintenance.

Reporting a vulnerability

Email support@spinui.com with what you found and how to reproduce it. Please do not access other people’s data or disrupt the service while you test. We read every report.