Incident Response, Legal Process and Record Retention Policy
In this document
Why this policy exists
Three things decide how much damage a bad day does: how fast a problem is found and told to the people it affects, how carefully a demand for data from an authority is checked, and how long records are kept, and where. This policy sets out all three, as they work today.
We are a small company, and we say plainly where something is done by hand rather than by a system. Our Security page describes the controls behind it.
Who this policy applies to, and our role
It covers the SorviAI service for every workspace not set up for the United Kingdom, and our own systems. For the data in your workspace you are the controller and we are your processor, so our duty is to tell you quickly and help you; for our own account, billing, support and website data we are the controller, and the duties are ours.
Part 1: Security incidents
We follow the incident lifecycle the common standards describe (ISO/IEC 27035 and NIST SP 800-61): prepare, detect, contain, recover and learn. We are not certified against either, and the steps are run by hand by our director and senior engineers.
- Detect. From error monitoring, from our hosting and network providers’ notices, and from reports to [email protected], which is read every working day, and around the clock for removal orders.
- Assess. We decide whether personal data or customer data is involved, and how serious it is: a low-severity event with no customer impact is recorded internally; anything that reaches customer data is treated as a possible personal data breach.
- Contain and recover. We stop the cause, restore service, and preserve the evidence. Our database backups allow recovery to any point in the previous seven days; no restore from backup has yet been tested, so we commit to no recovery time.
- Learn. We record what happened and what we changed, and tell affected customers the outcome.
Telling you, and the clocks that apply
| Who notifies | Whom | Deadline |
|---|---|---|
| We, as your processor | Your workspace administrators, and any contact you give us for this | Without undue delay, and within 48 hours of confirming a breach |
| You, as controller | Your supervisory authority | Within 72 hours of becoming aware, unless the breach is unlikely to result in a risk |
| You, as controller | The people affected | Without undue delay, where the breach is likely to result in a high risk to them |
| We, as controller of our own data | The ICO, and any other supervisory authority the law requires | Within 72 hours of becoming aware, unless unlikely to result in a risk |
We tell you what happened, which categories of your data and roughly how many people were involved, when it happened and when we found it, what we have done, the likely consequences, and what you need to do. Where we do not yet know something, we say so and follow up. Where information gives rise to a suspicion of a criminal offence that threatens someone’s life or safety, we tell the authorities of the country concerned promptly.
Part 2: Requests from authorities
We comply with valid legal process, and we check that it is valid first. The full rules are in our Abuse Policy; in short:
- A request must have a valid legal basis that binds us. We are a UK company, so requests reach us under UK law; a request from another country normally comes through the UK authorities under mutual legal assistance arrangements, or under an instrument that applies to us, such as an EU removal order.
- We disclose only what the request compels, and challenge one without a proper basis.
- We direct a request for your business records to you where we can, because you are the controller, and we tell you before we disclose unless the law forbids it.
- We do not transfer or give access to your data on a foreign request unless an international agreement or the law that applies to us requires it.
- Removal orders for terrorist content are acted on within one hour, as the Abuse Policy sets out.
Part 3: Record and log retention
Your records stay under your control: nothing in your workspace is deleted automatically, and you decide how long to keep it. This is what we keep, for how long, and where.
| Record | Purpose | How long | Where |
|---|---|---|---|
| Workspace data (your records and files) | Providing the service to you | Until you ask us to delete it; deleted from live systems within 30 days of your written request | DigitalOcean, London |
| Database backups | Recovering the service after a failure | Seven days, then overwritten | DigitalOcean, off-site at a location it does not publish |
| Audit log of actions in your workspace | Showing who changed what, and investigating incidents | For the life of the workspace | DigitalOcean, London, in your own database schema |
| Email send logs | Delivery troubleshooting, audit and abuse investigation | For the life of the workspace | DigitalOcean, London |
| Error reports and session replays | Finding and fixing faults | Up to 90 days, then deleted by Sentry | Sentry, EU region, Frankfurt |
| Sign-in session records | Keeping you signed in and showing your sessions | Until the session expires | DigitalOcean, London |
| Views and downloads of Nest public links | Letting the business see how its link was used, and detecting abuse | Until the link or the file is deleted | DigitalOcean, London |
| Support correspondence | Answering you, and defending legal claims | Six years from the last message | Microsoft 365, our support mailbox |
| Abuse, IPR and legal-request records | Showing the process was followed | Six years | Microsoft 365, our support mailbox |
| Our invoices and accounting records | Tax and company law | Six years | Stripe and our own accounts |
A backup is not an archive
Seven days of backups exist to recover the service, not to keep records. They cannot be searched or exported record by record, and they do not meet any retention duty you have under your own law.
Legal holds
Where an authority or a court requires us to preserve data, we preserve it for as long as required, even if it would otherwise be deleted, and we use it for nothing else.
Part 4: Evidence integrity and time
When we investigate, we keep copies of the logs and records involved, untouched, and note who handled them and when. Our audit log is read-only through every interface, but it is not yet tamper-evident, and an audit entry is not written in the same database transaction as the change it records. Timestamps come from our servers, whose clocks are managed by our hosting provider.
Changes to this policy
We update this policy when our process changes, and give workspace owners at least 30 days’ notice by email of a change that reduces your rights. This is the first published version. Every later version will be published here with its date, and earlier versions will be kept at this address.