TRIDENT

Security and data protection

Your homes, tenants and documents: held in London, seen only by your people.

Trident holds the details of real homes and the people who live in them. This page sets out where that data lives, who can see it, how it's backed up, and what we do if something goes wrong. It's written for the people who check a supplier before a contract is signed.

Send us your questionnaire

Where your data lives

  • Stored in London. The application runs on Google Cloud in London, and the database and document store are on Supabase in London. When you ask Trident to read a survey or certificate, that document is sent to Anthropic's AI service to pull out the readings, and the result is stored back in London.
  • Kept to your company. Each customer runs on its own database. On top of that, every request is tied to the signed-in person's company before anything runs, and a request that names another company's data is refused.
  • Documents stay private. Survey returns, certificates and photos sit in a private store, and each one opens through a short-lived link given only to someone allowed to see it.
  • Encrypted. Everything travels over HTTPS, and Google Cloud and Supabase encrypt everything they store.
  • Your data, your decisions. You are the data controller, and we process the data for you. You decide how long records are kept.

Who can see what

  • Named sign-in for every office user. Staff sign in with their own company Microsoft accounts, and only accounts from your own Microsoft directory are accepted. Access is checked on every action, so switching someone off in Trident stops them at their next click, and closing their Microsoft account stops them signing in again.
  • Roles, checked on every action. Each action is open only to the roles that need it. A variation can only be signed off in the name of someone whose limit covers its value; anything larger is refused, with the limit it needs.
  • Each crew member sees only their own jobs. Field accounts are made by your office, never by sign-up, and a phone signs in with a code sent by email. It holds only the homes that person is booked at, for three days ahead, and never a price, a vulnerability note, the office's notes or a key-safe code. Notifications on a locked screen never name a home or a resident.
  • A lost phone is wiped. Sign it out from the office. The next time it connects, its jobs and unsent work are wiped.
  • Your client and site teams see only their own contract. A client login opens one page, showing what that contract is waiting on. A site login sees only its own contract's programme. Neither can reach anything else.
  • Read-only logins for reporting. Managers who only need to report can have a login that reads but can't change anything, and never sees residents' contact details.

A record of every change

Every change on every home records who made it, when, and the reason where one is asked for. Overrides need the name of the person who owns the decision. Every action is logged with the name of the person who took it, and refusals are logged too. Logs never carry passwords, tokens or residents' contact details. When an auditor asks what happened to a home, the answer is already on the record.

Backed up every night, and the restore is tested

  • Every night all of Trident's data and every document are copied to separate storage in London that the database provider can't reach. Each night's copy is kept for 30 days, and a copy that fails its own check is never kept as a backup.
  • We test the restore rather than assume it works: the data rebuilt from a backup, every table checked against the original, and documents opened from the copy. We repeat the drill every quarter.
  • Our targets: lose no more than a day's work, and be back in use within four working hours.

Watched, and changed carefully

  • Alerts. We're alerted to server errors, failing or slow actions, and a backup that didn't run.
  • Every change tested. Each change to Trident passes automated tests and is put live by a person, never by a tool on its own. Updates to the live system go out outside your working day, each with a written plan to undo it.
  • No stored keys in our deploys. Our automated deploys hold no stored cloud keys: they sign in to Google Cloud for each run, and only from the approved branch.
  • Security fixes. High and critical security fixes are applied within 14 days. Problems can be reported to us privately, and we acknowledge them within two working days.
  • No customer data in our code. Automatic checks keep customer data and keys out of our code. We build and test on made-up homes, and our test copy of your system has residents' details masked. When we need to look at the live system to fix a problem, we use a read-only login that can't see residents' contact details or notes.

If something goes wrong

We contain it first: roll back the change, revoke the credential or lock the account. We tell you within 24 hours of knowing your data may have been affected, and give you what you need to decide on telling the ICO. Then we record what happened and what changed, and review our controls.

Who we use

SupplierWhat for
Google Cloud (London)Running the application, backups and logs
Supabase (London)The database and the document store
AnthropicReading uploaded documents, such as surveys and certificates, to pull out their readings
MicrosoftStaff sign-in, through your own Microsoft directory
Ideal Postcodes, postcodes.ioAddress and postcode lookups, to place homes on the map
GitHubOur code and automated tests. No customer data

Send us your questionnaire

If your procurement or IT team has a security questionnaire, send it over and we'll answer it in full. Email hello@trident-os.com or ring 07807 025270.