Which risk class applies — and how do you prove it?
Classification is a self-assessment. That is convenient right up to the moment someone asks you to show the reasoning behind it.
Last reviewed:
Sound familiar?
- Everyone agrees the system is 'probably limited risk' and nobody can point to why.
- The use case sits close to an area that carries heavier duties — HR, credit, education, safety components.
- A feature shipped last quarter changed what the system decides, and the classification was never revisited.
- There is no evidence file, only a slide from a workshop nine months ago.
What we do
Per-system classification
We work through the intended purpose, the decision the system influences and the people affected, and land on a class with reasons attached.
Borderline analysis
Where a use case sits near a heavier class, we document both readings and the facts that decide between them.
Evidence pack
The written record behind the self-assessment: inputs, outputs, human oversight, affected persons, and the version of the system it applies to.
Re-classification trigger
A short rule set that says when a change to the product forces a fresh look — so the classification does not silently expire.
Questions we get
Who checks our classification?
In most cases nobody, until something goes wrong or a customer, auditor or authority asks. That is why the value of this work is the written reasoning, not the label.
Does an internal-only tool need classification?
Yes. Internal use does not exempt you, and internal HR or monitoring use cases are among the ones that attract the heaviest duties.
How long does the assessment take?
For a handful of systems, typically one to two weeks including interviews. The long pole is usually finding out what the systems actually do, not the classification itself.
Tell us what's running in production.
We'll tell you what we'd check first — and what we wouldn't bother with.
Book a call