ISO 27001 Annex A 5.12 classification of information: a lean scheme

The enterprise security questionnaire asks for your classification policy. You have one, in a PDF, and nobody has applied it to a single file. This guide explains ISO 27001 Annex A 5.12 classification of information for a regulated firm of around 50 people: how to build a lean tier scheme, turn it into a one-page handling matrix, survive auditor sampling and let Microsoft Purview or Google Workspace enforce it.

It is written for information security managers, heads of compliance and IT leads preparing for ISO/IEC 27001:2022 certification or a surveillance audit.

What does ISO 27001 Annex A 5.12 classification of information require?

ISO 27001 A.5.12 requires a small set of named sensitivity tiers, criteria anchored in what compromise would cost the business, and a named owner who grades each piece of information. It is a preventive control that weighs confidentiality, integrity and availability, and it demands reviewable grades applied consistently by everyone.

In practice the control breaks into five working parts:

• Named tiers. A short list of sensitivity grades that staff can remember without a lookup.
• Impact-based criteria. Each tier is defined by what compromise would cost, plus what regulators, clients and contracts demand.
• A named owner. One accountable person grades each dataset or system.
• All three properties. Grading weighs secrecy, accuracy and availability, not secrecy alone.
• Built-in review. Sensitivity decays or spikes over a document's life, so the scheme carries its own review criteria.

Because the control is preventive, grading happens before an incident. The safeguards are already attached when something goes wrong, rather than being bolted on afterwards.

Grading against all three properties matters because some data is sensitive for reasons other than secrecy. A pricing table is rarely secret, but a wrong one costs money. NIST's draft SP 800-60 Rev. 2 categorization guidance takes the same approach, rating impact separately for confidentiality, integrity and availability.

Ownership is where schemes quietly fail. The person who understands the value of a customer contract or a source-code repository is a department head, not the sysadmin. Hand the grading to IT and you get informed guesses.

Left ungraded by the business, crown-jewel data ends up sitting at Internal. The register looks compliant, and the data is protected like a canteen menu.

How many classification tiers does a 50-person firm need?

Three tiers, or four at most: Public, Internal, Confidential, and Restricted only if genuinely needed. Each tier is defined by the damage compromise would cause, from no harm through short-term operational pain to a threat to the company's survival. Legal and contractual duties set the floor, and more tiers than four kill adoption.

The logic is not new. The UK Government Security Classifications Policy uses three tiers, each carrying baseline protective behaviours proportionate to the potential impact of a compromise. Tiers earn their place by tying protection to impact, which is exactly what your auditor will look for in an ISO 27001 data classification scheme.

A workable set of definitions for a firm of your size:

• Public: disclosure does no harm, such as published marketing material.
• Internal: disclosure causes limited, short-term operational pain.
• Confidential: disclosure causes serious commercial, contractual or regulatory damage.
• Restricted (only if needed): disclosure could threaten the company's survival.

Legal and contractual duties override internal opinion. Personal data, client-confidential material and anything a regulator cares about lands at whatever tier those obligations demand. GDPR and client contracts set floors rather than the whole scheme, so you still need tiers for everything else.

Mark everything Confidential and you have classified nothing.

Staff who find every file locked down learn to route around the controls with personal email, unofficial file shares and screenshots. Auditors notice that quickly, because the workarounds show up in the files they sample.

Too many tiers is the failure we see most often. A six-tier model borrowed from older government practice is more than a 40-person company can operate, and the usual sequence is confusion, then abandonment.

What belongs in a one-page handling matrix?

A handling matrix is a single page that states, for each tier, who may see the information, where it may live, whether it is encrypted, how it is shared and how it is destroyed. The matrix turns tier names into behaviour, and the cheat-sheet staff are trained on points straight at it.

Each tier gets one row, and each row answers five questions:

• Who may see it: everyone, all staff, named teams or named individuals.
• Where it may live: the approved repositories, and the places it must never go.
• Encryption: whether it must be encrypted at rest, in transit or both.
• Sharing: who can receive it, by what route, and whether approval is needed.
• Destruction: how it is deleted or disposed of when its retention ends.

Keep every cell short and checkable. "Encrypted at rest and in transit" can be verified in a sample; "handled with care" cannot.

Training then shrinks to a cheat-sheet in place of a course. It carries the tier names, the impact test for choosing between them and the place to look up the handling rules. New joiners can apply it on day one, and your awareness records show staff met the scheme.

The matrix also removes a quiet source of disagreement. When the criteria are never written down, sales reads Confidential as "don't post it publicly" while engineering reads it as "encrypted, named recipients only". Both are reasonable, and both are wrong against a page that says which.

Which of the following is an example of a correct way to protect classified data?

The correct way to protect classified data is to apply the safeguards the information's tier demands, set by its named owner at creation and recorded in the asset register: access limited to those the tier permits, storage in approved locations, encryption and sharing rules as the handling matrix states, and regrading as sensitivity changes.

The workflow behind that answer has four steps:

1. Grade at creation. The owner assigns the tier when the dataset, system or document is first created, using the written impact test.
2. Record the grade. The tier goes into the classification column of the asset register, against a named owner.
3. Apply the matrix. The file is stored in an approved location and shared only by the route its tier allows.
4. Regrade on events. A launch, a contract end or a publication prompts the owner to review the tier.

Grading at creation matters because retrospective grading never finishes. A client contract signed on Monday is Confidential on Monday, stored in the contracts folder and shared with named recipients only. Waiting for an annual clean-up means weeks of exposure at the wrong tier.

Regrading runs in both directions. Yesterday's launch secret is today's press release, and the document should drop a tier the moment it is published. A newly signed enterprise customer can lift an ordinary spreadsheet to Confidential through the contract alone.

The pitfall to design out is the missing review cycle. Without one, nothing is ever downgraded, so the Confidential population only ever grows. Friction rises with it, and the scheme drifts back toward the over-classification problem described earlier.

How does A.5.12 sequence with A.5.9, A.5.13 and A.5.15?

ISO 27001 A.5.12 sits immediately after the asset inventory in A.5.9 and before labelling in A.5.13 and access control in A.5.15, which both consume its output. Designing the scheme is a one-to-two-week job, and grades are recorded as one column in the existing asset register rather than a parallel inventory.

The dependency chain is one of the genuine early ordering constraints in an ISMS build:

• A.5.9 supplies the inventory of what there is to grade.
• A.5.12 supplies the grades and the criteria behind them.
• A.5.13 makes each grade visible through labels and markings.
• A.5.15 writes access rules keyed to the grade.

The one-to-two weeks cover agreeing the impact criteria with the business, drafting tier definitions, writing the handling matrix and getting owners to grade their first datasets. Most of the elapsed time goes on owners' calendars, not on writing.

A single column keeps the register honest. A separate classification spreadsheet drifts from the inventory, and then auditors find two lists that disagree.

Watch for ownerless entries. A register row with a grade but no named owner means nobody is accountable for reviewing it, so everyone's data becomes no one's responsibility.

How do UK GDPR, DORA and client questionnaires shape your tiers?

UK GDPR requires a level of security appropriate to the risks of processing, and DORA requires financial entities to classify information assets. Neither works without tiers: you cannot show proportionate protection to a regulator if you cannot say what you hold and how sensitive it is. Enterprise questionnaires ask for the classification policy almost as early as the security policy.

The ICO guidance on data security outcomes ties Article 5(1)(f) and Article 32 to security that is appropriate to the risk across confidentiality, integrity and availability. Tiers are how you evidence that proportion. Without them a firm protects everything identically, which over-protects the trivial and under-protects the crown jewels.

DORA is more direct. Article 8 requires financial entities in its scope to identify, classify and adequately document the information assets behind their business functions, and to review that classification at least yearly. An A.5.12 scheme recorded in the A.5.9 register gives a DORA firm a head start on that duty.

Every downstream control inherits its logic from the tiers too. Access rules, encryption, retention and transfer all key off the grade, so a weak scheme weakens each of them.

Partners add a complication. When you exchange sensitive material with clients, agree in writing:

• Mapping: which of their labels corresponds to which of yours.
• Handling: the minimum safeguards each side applies to the other's material.
• Contract route: where the mapping lives, usually the NDA or data processing terms.

Identical label names routinely mean different things in different companies, so an auditor will ask how you interpret a client's markings.

What will a certification auditor sample for A.5.12?

Auditors trace asset register entries to the repositories they describe, check random files, emails and decks against the scheme, and ask staff to name the tiers and handling rules. No scheme, or one ignored across the business, grades major; stale grades, ownerless datasets or patchy marking grade minor, aggregating to major as a pattern.

Expect questions like these in the room:

• "Talk me through your tiers. What makes something Confidential rather than Internal?"
• "Who decided this system's grade, and on what basis?"
• "Show me where classifications are recorded."
• "Here is a document from your shared drive. What tier is it, and how would a new joiner know how to handle it?"
• "You share data with this client. How do they know what protection it needs, and how do you interpret their markings?"

The evidence that answers them is short:

• The classification policy with tier definitions and the impact criteria behind them.
• The asset register showing a grade and a named owner against each entry.
• The handling matrix mapping tiers to storage, access, encryption and disposal.
• A handful of real files showing markings or tags consistent with the scheme.
• Tagging or data-loss-prevention configuration, where it exists, showing enforcement keyed to grades.
• Contracts and NDAs that pass handling requirements to partners.
• Training or awareness records.

Auditors test whether real files match the paper scheme. A modest register that reconciles with reality beats an elaborate policy nobody applies, and the grading line is drawn there: minor findings are drift, major findings are absence.

How do you automate classification in Microsoft Purview and Google Workspace?

Configure sensitivity labels in Microsoft Purview or Google Workspace so the grade attaches to the file at creation and inherits downstream. Then key sharing, encryption and retention rules to the tag, sync the asset register's classification column from the tagging estate, and run scheduled queries for untagged content in sensitive repositories.

The point of the exercise is that grades become machine-readable metadata instead of words in a policy. A label travels with the file, so the scheme enforces itself without relying on anyone's memory. The handling matrix stops being a document and becomes behaviour the platform applies.

A grade that lives only in a policy PDF is an opinion, not a control.

Grades that exist only on paper fail audits. With no tags and no markings, tooling has nothing to enforce and staff have nothing to follow. Where a label exists, an ISO 27001 classification of information sample takes minutes to pass.

Exceptions are the final layer. Scheduled queries for untagged content in sensitive repositories, or mismatches between a system's grade and its actual controls, replace the annual "is the register still right?" archaeology. Drift surfaces at the next scheduled run, and the owner fixes it before an auditor samples it.

At this scale the outcome is an audit sample that finds tags rather than gaps. The four patterns below build on each other:

Frequently asked questions