A confidential report leaves the organization because nothing on the document indicated it was restricted. The employee who forwarded it had no way of knowing. This is the gap that ISO 27001 control 5.13 exists to close. Without labelling, classification decisions stay trapped in policy documents and never reach the people or systems that handle data every day.
What 5.13 requires
ISO 27001 Annex A 5.13, Labelling of Information, requires organizations to develop and implement procedures for labelling information assets in accordance with the classification scheme established under control 5.12. In practical terms, this means every piece of information that the organization classifies must carry a visible or machine-readable marker that communicates its sensitivity level to anyone who handles it and to any automated system that processes it.
The control covers three labelling methods. Physical labels include stickers, stamps, or printed headers on documents and removable media. Digital labels include headers, footers, watermarks, and subject-line prefixes in emails. Metadata tags are embedded classification properties within file systems, document management platforms, and cloud storage. The 2022 revision of ISO 27001 specifically requires metadata tagging, making it a mandatory component rather than an optional enhancement.
Organizations must also define clear exceptions. Not all information needs a label. Publicly available data, for example, may be excluded from labelling requirements to avoid unnecessary overhead. The labelling procedure should specify which classification levels require labelling, which formats apply to each level, and who holds responsibility for applying and maintaining labels. The goal is to ensure that Data Loss Prevention (DLP) tools, email gateways, and access control systems can read classification labels and enforce handling rules automatically.
Why 5.13 matters
Most organizations invest significant effort in classifying their information. They define sensitivity levels, map data to categories, and document the results in a policy. Then the policy sits in a shared drive while employees continue handling data with no indication of what is sensitive and what is not.
An organization classifies its financial projections as “confidential” but never applies a label to the spreadsheet. An analyst, unaware of the classification, attaches the file to an email sent to an external consultant. No DLP rule fires because the file carries no metadata the system can read. No email gateway blocks the transmission because the subject line contains no classification prefix. The breach happens not because of malicious intent but because the classification decision never reached the point of action. According to the Verizon 2024 Data Breach Investigations Report, the human element was a component of 68% of breaches, and labelling failures are a direct contributor to the kind of mishandling that statistic reflects.
The regulatory consequences compound the operational risk. Auditors reviewing an Information Security Management System (ISMS) will look for evidence that classification is operationalized, not just documented. If labels are absent, the gap between policy and practice becomes a nonconformity. For organizations subject to the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), or sector-specific mandates, that gap can translate into enforcement action.
What attackers exploit
Labelling failures create specific vulnerabilities that adversaries actively leverage:
- Unlabelled files in shared drives: Sensitive documents stored without classification markers are accessible to anyone with folder-level permissions, making lateral movement after initial compromise far more productive. Learn more about how to prevent data leaks.
- Missing metadata on externally shared documents: When files leave the organization without embedded classification properties, receiving parties have no guidance on handling requirements, and DLP tools on either side of the exchange are blind.
- Unmarked physical media: USB drives, printed reports, and backup tapes without classification stickers are treated as non-sensitive by default, making them targets for theft or careless disposal.
- Email systems without classification headers: The absence of automated classification in email transport headers enables social engineering. Attackers who compromise an internal account can exfiltrate data without triggering label-based alerting rules.
- Inconsistent labelling across departments: When one business unit labels aggressively and another does not, employees lose trust in the system. Sensitivity labels become noise rather than signals, and genuinely sensitive data blends into the background.
How to implement 5.13
For your organization (first-party)
Effective labelling starts with the classification scheme defined under control 5.12. Every classification level in that scheme needs a corresponding labelling procedure that specifies how the label is applied, by whom, and in what format.
- Map labels to classification levels. Each sensitivity tier (public, internal, confidential, restricted, or whatever taxonomy the organization uses) should have a defined label format for electronic documents, emails, physical assets, and cloud storage. This mapping becomes the reference document for all subsequent steps.
- Define labelling procedures by format. Electronic documents should carry headers, footers, and embedded metadata. Emails should include subject-line prefixes and transport headers that DLP systems can parse. Physical assets need classification stickers or stamps. Cloud storage objects require sensitivity tags applied through the platform’s native tooling.
- Implement metadata tagging at the platform level. Tools like Microsoft Purview Information Protection and Google Workspace Labels allow organizations to embed classification metadata directly into file properties. This is not optional under the 2022 revision. Configure these tools to apply default labels based on content location or type, with the option for users to upgrade or downgrade based on actual sensitivity.
- Automate enforcement through DLP policies. Configure DLP rules to read metadata labels and take action. A file labelled “restricted” attached to an external email should trigger a block, encryption requirement, or manager approval workflow. Automation reduces reliance on employees remembering to check labels before sharing.
- Train all personnel. Everyone who creates, modifies, or shares information needs to understand the labelling scheme, know how to apply labels in the tools they use daily, and recognize what each classification level means in terms of handling obligations.
- Define exceptions explicitly. Specify which data types are exempt from labelling. Without clear exceptions, teams default to labelling everything as “confidential,” which dilutes the value of the entire scheme.
- Review annually. Labelling procedures should be revisited whenever the classification scheme changes or at minimum once per year. New data types, new storage platforms, and organizational changes all create labelling gaps if procedures are static.
Common implementation mistakes include labelling only digital assets while ignoring physical media, creating too many classification levels that make consistent labelling impractical, relying entirely on manual labelling without platform-level automation, and failing to update labels when information sensitivity changes over its lifecycle.
For your vendors (third-party assessment)
Vendor labelling practices are a blind spot in most Third-Party Risk Management (TPRM) programs. When sensitive data is shared with a vendor, the classification label should persist through the transfer and remain enforceable within the vendor’s environment.
Include these questions in vendor security assessments:
- “Describe your information labelling procedures. How do you ensure classification labels persist when data is shared externally?”
- “Do you use metadata tagging for classification, and can you demonstrate label-based DLP enforcement?”
Request specific evidence: the vendor’s labelling policy or procedure document, screenshots showing metadata tagging in practice, and DLP configurations demonstrating label-based enforcement rules.
Watch for red flags. A vendor that relies exclusively on folder-based access control instead of document-level labelling has a structural gap. A vendor that cannot demonstrate metadata use beyond visual markers (headers and footers) is likely unable to support automated enforcement. A vendor whose labelling applies only to a subset of data types may be leaving shared sensitive data unprotected.
Verification goes beyond documentation. Request a sample labelled document and inspect the file properties to confirm that classification metadata is embedded, not just visually displayed. The global average breach cost reached $4.88 million in 2024, a 10% increase from 2023 according to the IBM Cost of Data Breach Report 2024, and third-party incidents are a growing share of that figure. Verifying vendor labelling practices is a concrete step toward reducing that exposure.
Audit evidence for 5.13
Preparing for an ISO 27001 5.13 audit requires assembling artifacts that demonstrate labelling is operational, not just documented. The following table outlines the evidence types auditors typically request.
| Evidence type | Example artifact |
|---|---|
| Policy | Information labelling procedure defining labelling methods per format, exceptions, and responsibilities |
| Configuration | Screenshots of sensitivity label configuration in Microsoft Purview or equivalent platform |
| Metadata sample | File properties screenshot showing classification metadata embedded in a confidential document |
| Training records | Attendance logs and completion certificates for labelling awareness training |
| DLP policy | Data Loss Prevention rule set showing label-based enforcement actions (block, encrypt, notify) |
| Physical labelling | Photo evidence of classification stickers on removable media or printed documents |
| Audit log | System log showing automated label application or user-applied label events |
The strongest audit submissions pair each evidence type with a date stamp and responsible owner. Auditors are looking for consistency between the labelling procedure and actual practice, so the metadata sample should reflect the classification levels defined in the policy, and the DLP rules should reference the same label taxonomy.
Cross-framework mapping
Control 5.13 does not exist in isolation. Organizations managing compliance across multiple frameworks can map labelling requirements to equivalent controls, reducing duplicated effort and strengthening audit readiness across programs.
| Framework | Equivalent control(s) | Coverage |
|---|---|---|
| NIST 800-53 | MP-03 (Media Marking) | Full |
| NIST 800-53 | PE-22 (Component Marking) | Partial |
| SOC 2 | CC6.1 (Logical and Physical Access Controls) | Partial |
| CIS Controls v8.1 | 3.7 (Establish and Maintain a Data Classification Scheme) | Partial |
| NIST CSF 2.0 | PR.DS (Data Security) | Partial |
| DORA (EU) | Article 9 (ICT risk management framework) | Partial |
NIST 800-53 MP-03 provides the closest equivalent, covering marking procedures for both digital and physical media. The other mappings are partial because those frameworks address classification or access control more broadly without isolating labelling as a discrete control. Organizations pursuing multi-framework compliance can use labelling evidence gathered for 5.13 to satisfy portions of these parallel requirements.
Related ISO 27001 controls
Control 5.13 connects functionally to several other Annex A controls. Understanding these relationships helps organizations implement labelling as part of a cohesive information security program rather than a standalone exercise.
| Control ID | Control name | Relationship |
|---|---|---|
| 5.10 | Acceptable use of information and other associated assets | Defines handling rules that labels communicate |
| 5.12 | Classification of information | Provides the classification scheme that labelling implements |
| 5.14 | Information transfer | Labels determine transfer handling requirements |
| 5.15 | Access control | Labels inform access decisions and authorization levels |
| 5.33 | Protection of records | Records retention depends on classification labels |
| 7.7 | Clear desk and clear screen | Physical labels trigger secure handling of visible documents |
| 7.10 | Storage media | Labelling of removable media and storage devices |
| 8.12 | Data leakage prevention | DLP rules consume labels to enforce policy automatically |
The relationship with 5.12 is foundational. Without a defined classification scheme, there is nothing to label. The relationship with 8.12 is operational. Without labels, DLP systems have no metadata to act on and cannot enforce handling rules. Control 5.14 depends on labelling to determine how information should be protected during transfer, whether that means encryption, secure channels, or restricted recipient lists. Together, 5.12, 5.13, and 8.12 form the classify-label-enforce chain that turns information security policy into automated protection.
Frequently asked questions
What is ISO 27001 5.13?
ISO 27001 5.13 is the Annex A control requiring organizations to develop and implement procedures for labelling information in line with their classification scheme. It covers visual markers such as headers, footers, and stickers, as well as digital metadata tags that communicate sensitivity levels to both people and automated systems like DLP tools and email gateways.
What happens if 5.13 is not implemented?
Without labelling, classification decisions remain theoretical. Employees and automated systems have no way to identify sensitive data during handling, transfer, or storage. This leads to accidental disclosure, DLP tools that cannot enforce policy, and audit nonconformities that can block or delay ISO 27001 certification.
How do you audit 5.13?
Auditors check for a documented labelling procedure, verify that labels match the organization’s classification scheme, and perform spot checks on random documents and media. They also review metadata in file properties to confirm labels are machine-readable and examine DLP configurations that rely on labels for enforcement actions.
How UpGuard helps
Maintaining visibility across classified information assets and the systems that process them requires continuous monitoring, not periodic reviews. The UpGuard platform supports organizations working toward ISO 27001 compliance through:
- Compliance mapping across frameworks including ISO 27001, NIST, and SOC 2
- Vendor Risk assessments that evaluate third-party labelling and classification practices, streamlining the questionnaire and evidence collection process that 5.13 compliance depends on
- Attack surface monitoring that identifies where sensitive data may be exposed without adequate controls
Start a free trial to experience the UpGuard cybersecurity platform.