ISO 27001 A.5.13: Make Information Labels Useful

What A.5.13 requires in practice

Annex A control A.5.13 asks the organisation to develop and implement suitable procedures for labelling information, in line with the classification scheme it has adopted. Labelling is the visible side of classification: it lets a person see, at the point of use, how a document, message or medium should be treated.

Two points need care. First, the procedures must follow the chosen classification scheme, so labels mean the same as the levels they represent. Second, they must be implemented, which means people really apply them and systems support them where practical. The organisation decides what suits each format, whether a marking on a page, a header in an email, a property in a file or a tag on a storage medium.

The control does not require every item to carry a physical mark, nor a specific tool. Where labelling would be impractical or counterproductive, other means of making handling expectations clear may be justified. The test is whether people can tell how to treat information when they meet it.

Design for the next person or system

Identify where information loses context. A report may leave a protected application as a spreadsheet, appear as a screenshot in a presentation or be printed for a meeting. The recipient may not know its source or owner. Decide which classification information must travel with it and what the recipient needs to do differently.

A visible heading may suit a document read by people, while metadata may support processing within an application. Some material needs both. Establish who can assign or change a label, when a default is appropriate and how uncertainty is resolved. Avoid making every employee infer a classification anew when the source owner has already made that decision.

Labels need a shared meaning at interfaces. A customer’s “internal” category might permit a wider audience than your own category with the same name. Agree handling expectations before exchanging material. The useful agreement concerns access, permitted redistribution and protection, rather than simply matching colours or vocabulary.

Manage exceptions without losing the outcome

Some formats cannot carry an embedded label reliably. The organisation can identify alternatives such as a controlled container, accompanying notice or restricted transfer route. This is an implementation decision that should reflect the risk. A technical limitation is a reason to design another protection, not an automatic reason to ignore classification.

Consider what labels reveal. Marking an outer package with a highly descriptive sensitive project name could draw unwanted attention. An external marking can identify necessary handling without unnecessarily advertising its contents. Where a system protects all information at an agreed level, the critical labelling point may be export from that system.

Why labelling information matters to the business

A classification scheme only helps if people can see it at the moment they decide what to do with a file. Clear labels reduce hesitation, stop sensitive material being forwarded by accident and let colleagues, suppliers and customers recognise how information should be treated.

Labels also help technical controls. Systems that read labels can restrict sharing, warn users or route messages appropriately. For customers who trade sensitive information with you, consistent labelling signals discipline and reduces ambiguity in shared documents. Poorly maintained labelling, on the other hand, trains people to ignore the marks and weakens the whole scheme.

How to implement A.5.13

Start where mislabelling would cause the most harm, and make labelling as automatic as you reasonably can. Pilot the approach with one team first, so practical problems appear before the whole business is asked to follow it.

1. Confirm the classification levels first, since labels can only be as clear as the scheme behind them.
2. List the formats in which information appears, such as documents, emails, databases, printed material and media.
3. Decide how each format will carry its label and where a visible marking would cause more problems than it solves.
4. Use tool features that apply or suggest labels where your systems allow, to avoid relying solely on memory.
5. Explain to staff what each label means for sharing and storage, using examples from their own work.
6. Agree how information received from outside, or shared with customers, is treated when labels differ from yours.
7. Sample documents occasionally to see whether labels are present, correct and respected.

Illustrative BPO example: the missing export label

Illustrative construction example: drawings at a site meeting

A hypothetical contractor prints a drawing containing commercially sensitive design details. The electronic document carries a label, but the print layout clips the header. Meeting attendees cannot distinguish it from a version approved for wider distribution.

The document controller adjusts the print layout, checks multiple page sizes and explains the return or disposal route for meeting copies. A sample print becomes part of the release check for this document class. The organisation retains a practical test result, rather than assuming that a label visible on screen will always reach paper.

Evidence should follow representative journeys

Common nonconformities with A.5.13

Findings generally show labels that are missing, inconsistent or detached from handling. Assessors usually test labelling by picking a few real documents and comparing them with the scheme.

• Documents at sensitive levels carry no marking, or markings that differ from the scheme.
• Staff use their own terms for labels, so the same word means different things in different teams.
• Labelling is required in policy, but systems offer no easy way to apply it.
• Information from customers carries their labels, and no one has decided how to treat them alongside the internal scheme.
• Labels are applied inconsistently to electronic and printed copies of the same information.