Providers, data and retention
What is stored, where, who else handles it, and for how long. It states what is true today, including what is missing. For how organisations are kept apart and how people sign in, see Security.
Where data lives
The database is in London (AWS eu-west-2, through Supabase). Backups are the database provider's.
Who is responsible for what (UK GDPR)
- Your organisation is the controller (it decides why and how the data is used) of what it adds (domains, suppliers, software and device lists, member email addresses) and we, as the processor, handle it only on your instructions.
- We are the controller of the details people send through the front-page request form, and of sign-in records kept for security.
- We do not sell data or show advertising. What one organisation adds is never shown to another; the database enforces this and a test checks it on every change.
Providers that handle data
| Provider | What it does | What it receives | Where |
|---|---|---|---|
| Supabase | Database, sign-in, file storage for supplier evidence, and the vault that holds integration keys | Everything an organisation adds or the product stores for it, including member email addresses | London (AWS eu-west-2, through Supabase) |
| Vercel | Runs the web application and its scheduled jobs | Requests and responses in transit; operational logs. No customer data is stored there | Set by the operator for the deployment |
| Resend (optional) | Sends the weekly email and supplier emails | Recipient address, subject and the text of the email | The provider's own regions (not chosen by us) |
| Anthropic (optional) | Optional drafting aids (detection queries, a plain explanation of a block batch) and tagging of public articles | Public article text and indicators the person selects. Switched off unless the operator sets a key | The provider's own regions (not chosen by us) |
| Threat-intelligence sources you switch on (optional) | Reputation lookups and enrichment (for example VirusTotal, AbuseIPDB, GreyNoise, urlscan) | The single indicator being looked up (an address, domain, link or file hash), never other company data | Each source's own |
How long data is kept
| Data | Kept | Deleted automatically? |
|---|---|---|
| Sign-in log (time, address, browser) | 90 days | Yes |
| Saved answers from external reputation sources | 7 days | Yes |
| Rate-limit counters | 1 day | Yes |
| Closed access requests from the front page | 90 days | Yes |
| Feed run history (when each feed ran and what happened) | 90 days | Yes |
| Indicators (addresses, domains, links, hashes) from the feeds, with their sightings | Until 30 days after they expire; never while a block request refers to them | Yes |
| Indicators that have no expiry date, with their sightings | Until 365 days after any feed last reported them; never while a block request refers to them | Yes |
| How each item's score moved | 180 days | Yes |
| Daily risk level and score for each organisation (board history) | 800 days | Yes |
| Exposures that were fixed (when they opened and closed) | 800 days after they were fixed | Yes |
| Saved shift handover notes | 400 days | Yes |
| This clean-up's own run log | 180 days | Yes |
| Audit log of changes in an organisation | Kept; no deletion schedule (an owner decision is needed) | Not yet |
| Threat items with their scores, notes and workflow | Kept; no deletion schedule yet (people's notes and ownership hang on them) | Not yet |
| Leak, breach, lookalike and supplier findings | Kept until reviewed or the item is removed; no deletion schedule yet | Not yet |
An organisation can ask in writing for its data to be returned or deleted when it leaves.
What is not in place yet
- No security certification (SOC 2, ISO 27001, Cyber Essentials). We have tested it ourselves; no external penetration test has been done yet.
- No signed data processing agreement template yet; a draft is being prepared for legal review.
- Backups are provided by the database provider. A restore has not been rehearsed and no recovery time is promised.
- No single sign-on (signing in through your company's identity system, using SAML or OIDC). People sign in by email link or an owner-created password, with an authenticator app required if the organisation turns it on.
- An owner can download everything held about their organisation (Settings, Export your data), but there is no button to delete an organisation: deletion is done on request, and backups keep deleted rows until they age out.
- The audit log (the record of who changed what) can be exported as CSV or JSON lines, for example into a security monitoring tool. Its entries are chained, so a change to a past entry is detected and shown on the Audit log page; a database administrator could still alter the table, and the check would then fail. It does not yet record every kind of change.
Questions
For a security questionnaire or a data processing question, use the request form. To report a vulnerability, see the security contact file.