If everything in your organisation is labelled confidential, start by comparing the harm that different kinds of information loss or misuse could cause. A worked information classification example helps make those distinctions explicit.
Classification only earns its keep when it's tied to a defensible value judgement: what does this information or system actually cost the organisation if it's disclosed, altered or unavailable, and to whom. That judgement is harder than picking a label off a list, which is why most schemes fail at the point of application rather than at the point of design.
Classify value, not just secrecy
The most common design mistake is treating classification as a confidentiality-only exercise. A payroll file and a SCADA control interface are both sensitive, but for different reasons: one is a confidentiality problem if it leaks, the other is primarily an integrity and availability problem if someone can change what it does. A classification scheme built only around "who's allowed to see this" will systematically under-rate systems where the real risk is manipulation or downtime.
A more complete approach rates each information asset or system against confidentiality, integrity and availability separately, then assigns an overall sensitivity label from the highest of the three. This takes longer to set up than a single confidentiality scale, and it produces ratings people can actually defend when someone asks why a particular system sits where it does.
A four-label scheme, applied
Most organisations don't need more than four sensitivity labels. More than that and staff stop being able to remember which one applies; fewer, and you can't distinguish the genuinely sensitive from the routinely internal. A workable four-tier scheme looks something like:
| Label | Typical meaning |
|---|---|
| Public | No harm from disclosure. Loss of integrity or availability causes reputational, not operational, damage. |
| Internal | Routine business information. Disclosure is embarrassing or gives a minor competitive edge to an outsider, but isn't materially damaging. |
| Confidential | Disclosure, corruption or unavailability causes real harm — financial loss, safety risk, regulatory exposure, or serious reputational damage. |
| Highly Confidential | Harm is severe, potentially affecting safety of life, critical service continuity, or the organisation's ongoing viability. |
Information classification example: rating five systems at a fictional water utility
Here's how that scheme applies in practice, using a fictional mid-size water utility, Fenmark Water, rating a handful of its systems against the four labels.
| System | Confidentiality | Integrity | Availability | Overall label | Why |
|---|---|---|---|---|---|
| Customer billing database | Confidential | Internal | Internal | Confidential | Contains personal and financial data; disclosure has regulatory and reputational consequences even though short outages are tolerable. |
| SCADA treatment plant control | Internal | Highly Confidential | Highly Confidential | Highly Confidential | Disclosure alone is low-value to an attacker without control access, but unauthorised change or loss of availability can affect water safety. |
| HR recruitment records | Confidential | Internal | Public | Confidential | Personal information with disclosure risk; short-term unavailability has little operational effect. |
| Public website content | Public | Internal | Internal | Internal | No confidentiality value; defacement (integrity) is reputational rather than operational. |
| Asset maintenance scheduling system | Internal | Confidential | Confidential | Confidential | Incorrect or unavailable maintenance data can delay critical asset servicing, which has downstream safety implications. |
Two things are worth noticing here. First, the SCADA system rates lowest on confidentiality and highest overall — a scheme that only measured confidentiality would badly under-protect it. Second, the reasoning column is doing the real work. A rating without a written reason is an opinion; a rating with one is a decision someone else can review, challenge or update as circumstances change.
That reasoning also needs to cover the information lifecycle — how a given asset moves from creation through use, storage, transmission and eventual disposal or archiving — and who currently has access to it at each stage. A system rated Highly Confidential with an access list nobody has reviewed in two years is a rating that exists on paper only.
A repeatable procedure, not a one-off workshop
Classification produces defensible ratings only if it's done the same way each time, rather than reinvented per system by whoever happens to be in the room. A straightforward procedure looks like this:
- Identify the asset or system boundary. Decide whether you're classifying a database, an application, a physical file series, or a whole system including its interfaces. Get this wrong and you either double-count or miss dependencies.
- Rate confidentiality, integrity and availability separately. Resist the urge to jump straight to an overall label — the separate ratings are what let you catch cases like the SCADA example above.
- Take the highest of the three as the overall label, unless your organisation has a documented reason to weight one dimension more heavily for a particular asset class.
- Write the reasoning down, in plain language, at the time of rating — not reconstructed later when someone asks.
- Record who currently has access, and at what lifecycle stage the asset sits (created, in active use, archived, due for disposal).
- Set a review trigger, not just a review date — a system integration, a data volume change, or a new regulatory obligation should prompt re-classification regardless of when the last scheduled review happened.
Two people doing this independently for the same system should land on similar ratings if the reasoning in step four is doing its job. If they don't, that's a sign the rating criteria need tightening, not that classification is inherently subjective.
Common mistakes
Rating on confidentiality alone. As above — this systematically misses control and operational systems where integrity or availability is the real exposure.
Labelling everything Confidential. If 90 percent of your information holdings carry the same label, the label isn't informing any decision. Staff learn to ignore it, and the genuinely sensitive 10 percent gets the same handling as routine correspondence.
No written reasoning behind the rating. A spreadsheet of labels with no justification column can't be defended to an auditor, a regulator, or your own successor eighteen months from now when someone asks why a system was rated the way it was.
Classifying the system once and never again. A system's value changes as it's integrated with others, as data volumes grow, or as its role in operations changes. A classification exercise done once at go-live and never revisited drifts out of date quietly.
Confusing classification with access control. A label tells you how sensitive something is. It doesn't by itself tell you who should have access — that's a separate decision, informed by the label but not identical to it.
See the full worked example
The Worked Example: Information and System Value Assessment gives you the complete version of what's summarised above: forty ratings with written reasoning, across five systems and four sensitivity labels for a fictional water utility, including the lifecycle and access records and commentary on where the judgement calls were genuinely difficult. It's a template for the reasoning as much as the ratings. If you're building the risk register that sits alongside this classification work, Before and After: Recording Pre- and Post-Mitigation Risk covers how to track the effect of controls once they're in place, and if your systems sit under the Essential Eight, Essential Eight Maturity Level 1 vs 2 vs 3: What Each Really Requires is worth reading before you set your target maturity. For staff who travel with sensitive information on laptops or phones, the Business Travel Safety Plan Template covers the handling side classification alone doesn't.