Trust

Security Incident Response

What happens if data held in Alevate is lost or exposed — who acts, in what order, and who gets told when. Last updated 12 August 2026.

What counts as an incident

Anything that puts data we hold at risk of being seen, changed or lost by somebody who should not have it. In practice:

A credential exposed — a database URL, an API key, an access token.
A device holding data or credentials lost, stolen or compromised.
One business’s books becoming visible to another.
An account accessed by somebody who is not its owner.
Data lost or corrupted, including by our own mistake.
A supplier we depend on reporting a breach of their own.

A suspected incident is treated as an incident until it is shown not to be. Nobody needs to be certain before raising one.

Who is responsible

The director of Alevate Books owns every incident, decides when one is declared and when it is closed, and is the person who signs the notifications. That responsibility is not delegated. Contact for anything urgent, at any hour: support@alevatebooks.com.

Contain first

The first action is always to stop the bleeding, before anybody writes an email about it. An hour spent drafting a notice is an hour a stolen credential is still valid.

Revoke or rotate whatever was exposed — keys, tokens, passwords.
Suspend the account or the access path being abused.
Where a shop connection is implicated, disconnect it, which drops its token.
Preserve the evidence. Logs and database state are captured before anything is cleaned up, because a tidied system cannot be investigated.

Then work out the size of it

Once contained, we establish what was actually reachable: whose data, which fields, over what period, and whether it was read or only exposed. Access to records is logged, which is what makes that question answerable rather than a matter of opinion.

Then tell people

We tell affected businesses without undue delay, and in any case within 72 hours of becoming aware. The clock starts when we know something has happened — not when we have finished understanding it. A first message that says “this is what we know, this is what we are doing, we will tell you more by this time” goes out rather than waiting for a complete account.

Depending on what happened, we also tell:

Shopify, where data reached through a shop connection is involved.
The relevant data protection authority, where the law requires it, within the period that law sets.
The individuals affected, where there is a high risk to them — normally through the business whose customers they are, since that is who they have a relationship with.

We do not wait for certainty to say something has gone wrong, and we do not describe an incident as smaller than it is.

Recover

Where data is lost or corrupted we restore from backup. Backups are taken nightly, encrypted, and held off-site, and a weekly job restores the most recent one into a throwaway database and checks the accounting still balances — so the recovery path is exercised on a schedule rather than first attempted during an emergency.

Afterwards

Every incident gets a written review: what happened, how it was found, how long each stage took, and what change stops it recurring. The change is the point — a review that produces only a description has not finished. Anything not fixed immediately is recorded with an owner and a date.

We also review this policy at least once a year, and after any incident that showed it to be wrong.

If you have found something

Tell us at support@alevatebooks.com with enough detail to reproduce it. We will confirm we have it, keep you informed, and will not pursue anybody who reports a genuine problem in good faith.