Data Classification: 6 Proven Steps for ISO 27001

Most data classification schemes fail for the same two reasons. They classify confidentiality and quietly forget integrity and availability, and they have no rule for what happens when data of different sensitivities lands in the same place.

Both problems were solved in a four-page US federal standard published in 2004, and the answer transfers cleanly to an ISO 27001 programme.

Data classification has three dimensions, not one

FIPS 199 categorises information against confidentiality, integrity and availability separately. Each information type gets its own value for each objective.

Compare that with the typical corporate scheme: Public, Internal, Confidential, Restricted. Four labels, all of them about who may read the data. Nothing in that scheme records that a pricing file nobody would care to steal is one whose corruption would stop invoicing for a week.

That is the most common structural defect in data classification, and it is why the classification exercise so often produces no useful control decisions. Access controls follow from confidentiality. Backup, integrity checking and recovery objectives follow from the other two — and if the scheme never records them, those decisions get made somewhere else, inconsistently.

The three data classification levels, defined by consequence

FIPS 199 sets the levels by the severity of the effect on operations, assets or individuals:

• LOW — the loss could be expected to have a limited adverse effect.
• MODERATE — the loss could be expected to have a serious adverse effect.
• HIGH — the loss could be expected to have a severe or catastrophic adverse effect.

Note what the definitions are anchored to. Not the type of document, not the department that owns it, not who is allowed to see it — the consequence of losing it. A data classification scheme whose levels are defined by document category rather than by consequence cannot be applied consistently by two different people, which is exactly what you observe in practice.

Three data classification levels is also a deliberate choice. Schemes with five or six levels do not produce finer control; they produce arguments about the boundary and a long tail of misfiled data.

The high water mark settles what happens when data mixes

This is the rule worth taking away. For an information system, FIPS 199 requires that the impact values assigned to each objective be the highest values — the high water mark — from among the security categories determined for every information type resident on that system.

One HIGH information type makes the whole system HIGH. Not an average, not a majority, not a judgement call.

The consequence runs in a direction people find uncomfortable: mixing sensitive data into a general-purpose system does not dilute it, it upgrades the system. Segregation stops being a security preference and becomes a cost-control measure, because the alternative is applying HIGH-tier controls to everything that shares the platform.

There is also a precise asymmetry in FIPS 199 that almost nobody knows. NOT APPLICABLE is a permitted value for an information type — public information genuinely has no confidentiality requirement. But it can never be assigned to a system. Every system has some value for every objective. A team that marks availability “N/A” for a production service has made a categorisation error, not a pragmatic simplification.

Where data classification sits in ISO 27001

ISO/IEC 27001:2022 splits this across two Annex A controls in a deliberate order: 5.12 Classification of information, then 5.13 Labelling of information.

The order matters because the second is where schemes die. Classification is a policy exercise that a working group can complete in a fortnight. Labelling is an operational one that never finishes — it has to work in documents, in email, in ticketing systems, in object storage and in whatever the business adopted last quarter without telling anyone.

Underneath both sits 5.9 Inventory of information and other associated assets. You cannot classify what you have not listed, and an inventory that stops at hardware will not support a data classification scheme at all.

The scheme then feeds 5.10 Acceptable use, 5.14 Information transfer, 8.10 Information deletion and 8.12 Data leakage prevention — none of which can be written coherently until the labels exist and mean something.

Why the auditor asks about data classification

Data classification is where an ISO 27001 risk assessment gets its impact scale. If the risk assessment rates impact on one set of definitions and the classification scheme uses another, the two documents disagree and an auditor will find it in minutes. Aligning them is a half-day of work that prevents a recurring finding.

It is also the honest answer to “is this control proportionate?” — which is the question GDPR Article 32 asks by requiring measures appropriate to the risk. Without classification, proportionality is an assertion.

Making a data classification scheme that actually holds

Four things separate a scheme people use from one that is quoted in a policy and ignored:

• Define levels by consequence, in the organisation’s own terms — a figure, a duration, a regulatory outcome — not by document type.
• Classify at the information-type level, then derive systems from the high water mark. Classifying systems directly is how everything drifts to the top level.
• Default deliberately. Unclassified data has to have a treatment, because most data will never be touched by a human.
• Automate labelling where the platform allows it, and accept that the residue will be handled by convention rather than control.

How data classification connects

Where to start with data classification

1. Inventory information types, not systems, and keep the list short enough to finish.
2. Rate confidentiality, integrity and availability separately for each type.
3. Write the level definitions in consequence terms your executives would recognise.
4. Derive system categories by the high water mark, and use the result to argue for segregation where it saves money.
5. Align the impact scale with the risk assessment before an auditor does it for you.
6. Solve labelling second, and treat it as a permanent programme rather than a project.

This guide reflects FIPS 199, published by NIST in February 2004, and the Annex A control structure of ISO/IEC 27001:2022, read at 16 August 2026. FIPS 199 is a US federal standard; it is used here because its definitions are public, precise and transferable, not because it binds private organisations.

The ISO 27001 Toolkit provides 162 editable templates including the information classification policy, the asset and information inventory, the labelling procedure and the risk assessment methodology that has to share its impact scale.