How we keep your data safe

This is the short version, written for the person setting the product up. The full statement — including the controls we do not have yet — is on our security page, and it is the version to send to a buyer's security questionnaire. Where the two differ, the security page is authoritative; it renders from the same definitions this page does.

Tenant isolation

Every record in the database carries an org_id, and every query filters on it server-side. Tenants cannot see each other's data, even with a crafted URL, and there are no cross-tenant joins. Every request is scoped to one organisation before any data is read.

Encryption

• In transit: TLS 1.2 or higher.
• At rest: AES-256.
• Database connections use TLS with a pinned provider CA.
• Passwords are hashed with bcrypt.
• API keys and secrets are held as environment variables, never in the codebase.

Where the data lives

The application runs on Render, in Render’s Frankfurt region. The database is Aiven managed MySQL, reached over TLS. Both are within the European Economic Area.

Hosting and the database are within the European Economic Area. Not every sub-processor is: payments are processed by Stripe in the United States under the UK Addendum to the EU Standard Contractual Clauses. The sub-processor table on our GDPR page lists every third party that touches your data and where each one processes it, and it is the authoritative list.

We do not state Aiven's cluster region on this page. Our service configuration pins the application's region and nothing else in our deployment records the database region, so the sub-processor table says it is being confirmed with the provider rather than naming a city we cannot evidence.

Backups

Backups are encrypted and taken daily. They expire automatically on a rolling window set by our database provider, which means a record deleted from the live platform remains inside unexpired backups until the last backup containing it rolls off. Backups are never used to restore deleted customer records to the live platform. We are confirming the exact retention window with the provider and will publish it here once it is confirmed.

Access control

Every account carries one of four roles: Owner, Admin, Editor and Viewer. Owner is the account that created the workspace and is the only role with billing and workspace-deletion rights. Sessions are signed server-side, so the session cookie cannot be edited or forged in the browser.

Be aware of the limit here, because your security questionnaire will ask and we would rather you heard it from us: role-based restrictions are not yet enforced across the product. Anyone you invite can reach every module. Roles today describe intent and drive the interface; they are not an access-control boundary. Invite accordingly, and see Inviting team members.

There is no self-service password policy, session timeout, login-attempt limit, lockout duration or IP allowlist. Any screen offering those settings is not connected to anything — we are removing it rather than leaving you to configure a control that does not run.

What we do not have yet

We publish this rather than leave you to discover it, because your security questionnaire will ask.

• Two-factor authentication is not available today, on any plan. Earlier versions of our documentation said otherwise; that was wrong.
• CSRF tokens on state-changing requests are not implemented today.
• Our Content-Security-Policy permits inline script; it is not nonce-based.
• We have not published a completed third-party penetration test, and no SOC 2 report has been issued. The current status of each certification is listed on the security page.

Incidents

Incidents that affect customers are written up on accolade.live/status and emailed to account admins. We do not publish a detection-to-notice commitment, because there is no monitoring in place that would trigger one and a target nobody can keep is worse than none. The status page also explains what it does and does not measure — in particular, it publishes no uptime percentage, because nothing records availability history yet.

Your side of it

• Use the narrowest role that lets somebody do their job, and deactivate leavers rather than sharing a login.
• Set the Check-In Staff Access Window so door staff do not keep a live login all year.
• Keep the Activity Log on, with failed logins, permission changes and data exports all logged.
• Take an export before anything irreversible — see Exporting and deleting your data.

For data-protection questions, including a Data Processing Agreement, contact privacy@accolade.live. The role split between you as controller and us as processor is set out in the GDPR overview.