Ask most organisations how they classify information and you'll get one of three answers.
Classification is one of those controls that sounds administrative and turns out to be structural. It's the control that decides whether the rest of your information security program is protecting anything specific, or just protecting everything equally, which usually means protecting nothing particularly well.
Let's get into it.
Annex A 5.12 asks organisations to classify information according to the information security needs of the organisation, based on confidentiality, integrity and availability requirements, and the expectations of interested parties.
Unpacked, that means three things:
It's a short control. It's also load-bearing. Almost every protective control downstream (access rights, encryption, retention, transfer, disposal, monitoring) depends on knowing what you're dealing with.
You cannot apply proportionate protection to information you haven't sorted.
Ask a room of employees about classification and watch the enthusiasm drain out of them.
That's usually because they've encountered a version of it that didn't work. The five-tier scheme with definitions that overlap. The mandatory header on every document. The training module that explained the labels but never explained what to actually do differently.
Classification earns its bad reputation when it stops at labelling.
A label is not a control. "Confidential" written at the top of a document changes nothing on its own. It only becomes a control when the label triggers different handling — different access, different storage, different sharing rules, different retention, different approval before it goes anywhere new.
If the label doesn't change behaviour, you've built a filing convention and called it security.
Too many classifications. Four levels is usually plenty. Once you have six, with the distinction between two of them resting on a subtlety only the person who wrote the policy understands, staff stop engaging and default to whatever feels safest. Usually that's the lowest level, because the higher ones create friction.
Classification that lives only in the policy. The scheme is defined, approved and filed. It has never been applied to an actual system, repository or dataset. When an auditor asks to see classification in practice, there's a document describing an intention.
No link to the asset or data register. Your register lists what you hold. Your classification scheme describes how sensitive things can be. If those two never meet, you can't answer the question that actually matters: where is our most sensitive information, and what is protecting it?
Inherited classification nobody revisits. Data classified as confidential at creation stays confidential forever, including the 2019 marketing deck that's been on the public website for five years. Over-classification erodes the scheme just as effectively as under-classification, because it teaches people that the labels don't mean much.
Classification that stops at documents. Most schemes were designed for files. Information now lives in databases, SaaS platforms, tickets, chat threads, CRM records, logs and backups. If your scheme only makes sense for a Word document, it's covering a shrinking share of your information.
Classification has become considerably more urgent in the last two years, and not because the standard changed.
When staff use AI tools, they make a classification decision every time they paste something in. They're deciding, in the moment, whether this particular piece of information is fine to put into this particular system. Most of them are making that call with no framework, no label and no clear rule.
"Don't put anything sensitive into AI tools" is only useful if people can identify what's sensitive without stopping to think about it. If your classification scheme is vague, or lives in a policy nobody has read since onboarding, then every AI interaction becomes an individual judgement call made under time pressure by someone trying to finish a task.
That's not a training problem. It's a classification problem wearing a new hat.
A simple scheme, in plain language. Three or four levels, each with a one-line description a person can apply without interpretation. If someone has to consult the policy to classify a document, the scheme is too complex.
Handling rules attached to each level. For every classification, say what it means in practice: who can access it, where it can be stored, whether it can leave the organisation, whether it can go into third-party or AI tools, how long it's kept, how it's disposed of. This is the part that makes it a control.
Classification applied to registers, not just documents. Your information asset register and data register should carry classification as a field. That's what lets you answer supplier, customer and audit questions quickly, because sensitivity becomes something you can filter on rather than something you have to reconstruct.
Alignment with contracts and obligations. If a customer contract defines specific handling requirements for their data, your scheme should accommodate that rather than sit alongside it in a parallel universe.
Review built in. Classification isn't permanent. Things become less sensitive with time and occasionally more so. Build reclassification into your review cycles rather than treating the first decision as final.
Ownership. Someone decides classification for each information asset. Usually the asset owner. If nobody owns the decision, the decision doesn't get made.
The recurring theme in this series applies here too: the auditor is less interested in the document than in whether it's operating.
Classification fails when it's treated as a documentation exercise rather than an operating decision. The scheme gets written because the standard asks for one, filed because the audit needs it, and then plays no part in how the business actually handles information.
The test is simple. Pick a piece of sensitive information in your organisation. Ask what its classification is, who decided that, and what that classification changes about how it's stored, shared and retained.
If the answer comes back quickly and consistently, 5.12 is working.
If the answer is "it would be confidential, I think," you have a policy rather than a control.
de.iterate connects classification to the things that make it useful: your information asset register, data register, risks, controls and evidence. So sensitivity isn't a label sitting in a document somewhere. It's a field you can filter, report on and prove.
Book a demo to see how it works.