Classification and Clearance

Classification labels a record by how sensitive it is. Clearance is what a user must hold to open a record at that level. Together they turn "please be careful with this one" into something the system enforces rather than something staff are asked to remember.

Where to find it

Architect Panel → Security:

Classification & Clearance — the console — schemes, levels and who holds what, in one place
Classification Schemes — a named ladder of sensitivity
Classification Levels — the rungs within a scheme
User Clearance — which level each user is cleared to

Schemes and levels

A scheme is a named ladder — you might have one for information security and another for safeguarding sensitivity, because they are different judgements about different risks. A level is a rung within a scheme, and levels are ordered, so clearance to a level implies clearance to everything below it.

Most organisations need exactly one scheme. Create a second only when you genuinely have two independent axes of sensitivity, because every additional scheme multiplies the decisions a person makes when they create a record.

Keep the ladder short

Two or three levels that people understand beat six nobody can distinguish. A classification scheme that requires a judgement staff are not confident making produces records classified by guess, and a guessed classification is worse than none — it looks like a control while providing nothing.

Use the language your organisation already uses. If your information governance policy names its tiers, use those names rather than inventing parallel ones that then have to be mentally translated.

How clearance is checked

Clearance is held against the user, in User Clearance. When a user without the matching clearance encounters a classified record, the record does not appear in lists, searches or counts — not merely in the form.

That distinction matters more than it sounds. A case appearing in a search result with its content hidden still discloses that the case exists, and for safeguarding, family law or HR investigations the existence of a case is frequently the sensitive fact. Hiding the content while leaking the row is a control that fails at exactly the point it is needed.

Setting it up

Open Security → Classification & Clearance.
Create a scheme, then its levels in ascending order of sensitivity.
Grant clearance to the users who need it. Start narrow — it is far easier to add a person than to explain why fifty people were cleared to a level they never needed.
Decide which datastores participate, and whether an unclassified record is open or closed by default. Closed-by-default is safer and more annoying; pick deliberately rather than by accident.

Worked example — children's services

A single scheme with three levels: Standard, Restricted, Highly Restricted. Most casework is Standard. A case involving a child known to a member of staff is Restricted. A case subject to a court order restricting disclosure is Highly Restricted, and clearance to that level is held by four people. When an inspector asks how access to sensitive cases is controlled, the answer is a screen rather than a policy document.

Applying a classification

Classify at creation where the referral route already tells you it is warranted, and allow it to be raised later by anyone handling the case. Raising should be easy; lowering should not. Reducing sensitivity has consequences and deserves a deliberate step and a reason — ideally dual authorisation.

Recommendations

Audit a sample periodically. Unclassified records that should have been classified are the common failure, and they are invisible unless somebody looks for them.
Do not classify everything. If most records are Restricted, the level means nothing and staff will treat it as noise.
Train on the boundary cases, not the obvious ones. Nobody struggles with the extremes.
Pair with break-glass. A control with no emergency route gets circumvented outside the system, where you cannot see it.