Security and trust
Built to be examined
You are buying a system whose purpose is to stand up to scrutiny, so the platform holding your evidence should survive the same questions.
This summary covers the key points rather than the whole picture: email sales@puretrace.co.uk with whatever your assurance process needs and we will answer in writing.
This page was last reviewed in October 2026.
At a glance
The short version
The main points, for anyone short of time, each linked to where it is explained below.
- 01Where you need itYour data is hosted in the region your jurisdiction and regulator require, under the data protection law that applies to you. For United Kingdom clients that is Amazon Web Services in London.
- 02Tested on every changeYour data is separated from every other organisation's in the database itself as well as in the application, and both separations are tested automatically on every change.
- 03Append-onlyThe audit trail is append-only and tamper-detecting. Nobody can edit or delete an entry, including administrators and us.
- 04On every entryEvery audit entry records who, what changed, from what to what, when, the role held at the time and the line of defence.
- 05Enforced, no exceptionsEvery user signs in with a password and an authenticator app. There are no exceptions.
- 06Enforced on the serverSessions end after thirty minutes idle and twelve hours in total, enforced on the server.
- 07Enforced in softwareSegregation of duties is enforced by the software: nobody responds to their own breach, approves their own pack step or closes their own action.
- 08Working identity onlyThe platform holds working identity only: name, work email address, role and a record of activity in the system.
- 09NeverYour data never trains anything, and no model makes a risk judgement anywhere in the system.
- 10Completed August 2026An independent penetration test of the PureTrace web application, carried out by a CREST-accredited firm, was completed in August 2026. The attestation letter is available on request as part of due diligence.
Where your data lives
We host the platform and your data in the region your jurisdiction and regulatory obligations require, and we handle them under the data protection law that applies to you, such as the UK GDPR. Our clients today are in the United Kingdom, and for them the platform runs on Amazon Web Services in London, so their data stays there. If your obligations sit elsewhere, tell us early and we host where you need us to.
Data is encrypted in transit (at the public edge) and at rest (in the database).
Your data cannot reach another organisation
Every record carries the identity of the organisation it belongs to, and two separate mechanisms use it to keep organisations apart. The first is in the application, which scopes every request to your organisation before it reaches the data. The second is in the database itself, where PostgreSQL row-level security is switched on for every table holding client data; the application account cannot bypass it, and it denies by default.
The second layer matters because a defect in the software is always possible: even then, it could not expose another organisation's register, because the database refuses regardless. To keep this true, an automated test attempts to read across organisations on every change we make, and a change that manages to does not land.
No record editing without a clear log
Every change writes an entry recording who made it, what changed, from what to what, when, the role they held and the line of defence they acted in.
The record only ever grows: nothing in the system can edit or remove an entry, and that holds for administrators (and for us) as much as for your users. It is closer to a bank statement than a document: entries accumulate, and none can be quietly rewritten. Each entry is linked to the one before, so one changed after the fact stands out and a check shows where. An auditor gets a full log of evidence rather than an assurance.
Access and authentication
Everyone signs in with a password and a code from an authenticator app. There is no way to switch the second factor off, and nobody (including an administrator) can reset their own, because a second factor that can be switched off for convenience is not a second factor.
Sessions time out after thirty minutes of inactivity and end after twelve hours regardless. Both limits are enforced by the server rather than the browser, in line with current NIST guidance.
There are five roles, and each sees a unique screen. A role can cover one unit or all of them, and asking for something outside your role produces a refusal. Our own staff sign in separately (to set up your environment and deal with support tickets) and cannot read your register, controls, indicators or committee packs.
Segregation of duties, enforced rather than asserted
These refusals are a security control as much as a governance one, and the platform enforces them on the server.
- Whoever submitted a breaching value cannot write its response, and nor can the author of the original submission.
- Whoever compiled a committee pack cannot approve any step of it, and no one person clears two steps of the same pack.
- Whoever requests closure of a remediation action cannot approve it.
- Nobody grants themselves a role, deactivates their own account or resets their own second factor. Nobody, at any level, edits or deletes an audit entry.
The data we hold is narrow
PureTrace is designed to run on business data rather than personal data. What it holds about your people is narrow: their working identity, meaning name, work email address, role and a record of what they did in the system.
Your data runs your platform and nothing else. It never trains anything, and no model makes a risk judgement anywhere in the system. Email from the platform is transactional only (invitations, security notifications and workflow reminders); there is no path for anything else.
It is kept for the term of the contract. On exit it is returned to you in the formats you need and then deleted, on the timetable the contract sets. The audit record is the exception. The platform cannot edit or remove an audit entry, for us as much as for you, so the audit trail survives exit in full. It is exported to you with the rest of your data and retained by us for the period the contract sets.
How the platform is built, and what we do not claim
Environments are built from a written definition rather than by hand, so they can be rebuilt identically and nothing depends on somebody remembering a step. Every change is tested automatically before it goes near a client, against a real database rather than a stand-in, and the isolation and audit protections above are part of what is tested each time.
An independent penetration test of the PureTrace web application, carried out by a CREST-accredited firm, was completed in August 2026. The attestation letter is available on request as part of due diligence.
We hold no certification, and it would be wrong to imply otherwise. The platform is designed to support SOC 2 and ISO 27001 audit readiness, and we answer the control questions behind both in writing. If that changes, this page will say so.
Technical documentation is shared with your reviewers as part of due diligence, once a conversation has started, and they can speak to the people who built the platform. The detailed material behind this page (test reports, control evidence and the like) is part of due diligence with an engaged client and is not published.
Who else handles your data
The platform runs on one provider, Amazon Web Services, in the region your jurisdiction requires (London for United Kingdom clients). It hosts the platform, stores and backs up the data and sends its email. Anything else that comes to handle client data is listed here, with what it does and where it runs.
| Provider | What for | Where |
|---|---|---|
| Amazon Web Services | Hosting, storage, backup and email (through Amazon SES) | London (eu-west-2) for United Kingdom clients |