Security
Built to be examined
You are buying a system whose whole purpose is to stand up to scrutiny. It would be a poor advertisement if the platform holding your evidence could not survive the same questions.
The controls below are the ones a security reviewer asks about first: where your data sits, how it is kept apart from everyone else's, what happens to the record of a change and who can do what.
What follows is the summary. The architecture overview and the API specification go to prospective clients on request.
Hosted to meet your obligations
Where your data sits, and how it is looked after, follows the regulation that applies to you. That is the requirement the platform is built around rather than a detail settled afterwards.
For United Kingdom clients the platform runs in Amazon Web Services' London region, so your data stays in the United Kingdom. Traffic between the browser and the platform is encrypted, and the databases are encrypted where they sit.
If your obligations point somewhere else, raise it early and we will work through it with you.
Your data cannot reach another organisation
Your data is separated from every other organisation's twice over, by two independent mechanisms.
The first sits in the software. The second sits in the database itself, which will not hand over another organisation's records no matter what the software asks it for.
That second layer is the one that matters. It means a mistake in the software cannot expose another organisation's register, because the database refuses regardless. Both layers are tested automatically on every change we make.
A record nobody can quietly edit
Every change writes an entry: who, what changed, from what to what, when, the role held at the time and the line of defence. Names and roles are captured at the moment of the change, so the trail still reads correctly years later.
The record only ever grows. Nothing in the system can edit an entry or remove one, and that holds for administrators and for us as well as for your users.
Entries are chained to one another, so an entry altered after the fact no longer fits and a check reports where. An auditor gets evidence rather than a log we assure them is complete.
Getting in, and staying in
Sign-in requires a second factor from an authenticator app. One administrator resets another's, and nobody resets their own.
Sessions end: thirty minutes idle or twelve hours in total, whichever comes first. A forgotten open laptop stops being a way in.
Access is role-based, and a role applies to one unit or across all of them. Asking for something you are not entitled to gets a refusal, not a hint that it exists.
New accounts can be restricted to email domains you specify, so a personal address cannot be invited into your environment by mistake.
Segregation of duties, enforced rather than asserted
These refusals are a security control as much as a governance one, and the platform enforces them where a browser cannot argue with them.
- 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.
Transactional email only: account invitations, security notifications and workflow reminders. There is no marketing send at any point, from any part of the system.
Sending is properly authenticated, on its own subdomain, with delivery monitored.
The data we hold is deliberately narrow
PureTrace is designed to run on business data rather than personal data. What it holds about your people is their working identity: name, work email address, role and the record of what they did in the system.
Your data is used to run your platform and for nothing else. It never trains anything, and no model makes a risk judgement anywhere in the system.
Where a record is removed for data protection reasons, the audit trail describing it survives. That is deliberate, and it is the point of an audit trail.
What you can ask for
There is a lot more detail behind this page. The architecture overview and the API specification go to prospective clients on request, and we will walk your technical people through either of them.
We answer assurance questionnaires directly and in writing, and we will put your technical reviewers in front of the people who built it.