How commvita is secured: the controls, and the evidence for them

Role and organisation scope, step-up re-authentication for special-category records, break-glass with a recorded justification, a hash-chained audit re-verified when it’s read, and the toolkit and assessment-criteria evidence an assessor can take away.

1 The three questions an assessor actually asks

An information governance lead doesn’t want a policy document. They want three things answered on screen, with the platform in front of them: who can reach this record, what has happened to it, and can you prove the record of what happened hasn’t been edited since. This is how commvita answers all three, and what an assessor can see for themselves.

2 Role, organisation scope, and the reach that follows

Access is modelled as two independent things. The role is the capability. The organisation scope is the reach. A receptionist and a consultant in the same practice are separated by role; two consultants in different organisations are separated by scope. Getting one right doesn’t get you the other.

Every cell in that matrix is a decision somebody has to be able to defend. Sensitive diagnoses are policy-driven instead of a flat yes or no, which is the honest answer for a data class where the rule depends on the care relationship. A receptionist gets demographics and nothing else. A health care assistant reads, and doesn’t write. The matrix is served by the platform not typed into a slide, and it exports so that an assessor can take it away as evidence.

Underneath it, the scope rules matter as much as the roles. A user is attached to the organisations they work for. Cross-organisation reads need explicit permission instead of an accident of role. A team lead can inherit a colleague’s scope through a delegation, and that delegation expires. A user group grants scope and can never grant a role, so nobody gains capability by being added to a list.

3 Special-category records: step up, or break glass

Genomics, mental health, sexual health and safeguarding records are special category data under Article 9. Holding them behind the same login as an appointment list isn’t good enough, and two controls sit in front of them.

The design point behind all three: an emergency override that’s easy to use and impossible to hide is safer than one that’s hard to use. Clinicians will always need to reach a record they don’t normally hold. What matters is that reaching it costs a sentence of explanation and leaves a mark somebody reviews.

4 An audit that can’t be edited quietly

The audit log records every access and every mutation, with the actor, the action, the module, the resource and its identifier, the time, and the jurisdiction it happened in. It’s filterable by date, user, action and module, and it exports.

Two things in that screenshot are worth naming. The third row is a genomics access event, recorded because a special-category resource was reached, with the role and access level captured alongside it. And the strip at the bottom states the retention position: a minimum seven-year retention, every access and mutation recorded, tamper-evident. Those are the claims an assessor will test, so they’re on the screen the assessor is looking at.

The account log is separate and stricter. It records one row for every authentication event: sign-in, failure, second-factor challenge and sign-out, with the username, the source address including the forwarded chain, the country the login came from, the device and the result. It’s append-only. There’s no endpoint that updates or deletes a row, because the way to make a log trustworthy is to build no path that could edit it. Reading it’s restricted to administrators.

The green line is the control. Each row is bound by a hash to the row before it, and the chain is recomputed across the whole log every single time the log is read. The page reports the result of that recomputation, not a stored flag saying it was fine once. That’s the difference between a log that claims to be tamper-evident and one that demonstrates it to the person reading it, in the second they read it.

5 Sessions end, and secrets stay on the server

Three controls that get less attention than they deserve, because none of them is visible until something goes wrong.

6 Watching it in use

Controls stop things. They don’t tell you what is being attempted. The Security Console is the operational view: current threat level, active sessions and how many carry special-category scope, failed logins and lockouts, Article 9 access events, revoked credentials, and the platform’s position against the toolkit criteria.

The console carries its own amber banner saying it’s seeded demonstration data, and that’s accurate: this surface is illustrative today. What it demonstrates is the shape of the monitoring, and the shape is the part that’s specific to healthcare. A generic security tool flags a bulk download. It can’t tell you whether the person doing it’s on the care team.

Read the clinical context line on each card. Bulk access to mental health records by someone not on that care team is a finding. The same access by the clinician who is on the team is a Tuesday. Off-hours access matters more when the on-call rota says nobody should be working. An overseas login matters more when the staff record says the person is on leave. Every one of those cross-references is a fact the platform already holds because it also runs the rota, the care team and the leave. That’s the argument for putting the monitoring inside the clinical system instead of shipping logs to something that has never heard of a care team.

7 The evidence pack, and the ceiling

Assurance in this market runs on two artefacts: the Data Security and Protection Toolkit, and the Digital Technology Assessment Criteria. Both are held in the platform as evidence with a status, not as a claim in a brochure.

The toolkit position is derived from the mandatory items for the organisation’s own category, and it distinguishes between an item that hasn’t been met and an item on which nothing has been recorded. Those are different facts and the platform reports them differently, because scoring an empty toolkit as a failure is a finding derived from no data. The assessment criteria are held per domain, each with its standard, whether it’s mandatory, its weight, the evidence text, who assessed it and when, and a weighted position over the mandatory set. The access matrix exports as evidence for the access-control criteria, and the account log answers the access-monitoring ones.

Now the ceiling, plainly. The audit, the account log with its chain verification, the role and scope model with its exports, the step-up re-authentication, the break-glass record, sign-out revocation, the server-side handling of credentials, the encrypted export and the toolkit and criteria evidence are all API-backed and working today. The Security Console and its anomaly stream are a demonstrated surface on seeded data, and the page says so on itself. The platform also holds an internal security architecture view with its threat model and a control-by-control posture including the gaps it’s closing. I haven’t screenshotted that view here and I won’t publish its detail on a public page. It goes to a prospective customer in a due diligence pack, with the gaps in it, because a supplier who shows you only the closed controls is telling you less than nothing.

Where it lives in commvita