ISO 27001:2022 Annex A 5.13 Labelling of information for AI Companies

ISO 27001 Annex A 5.13 Labelling of information is a security control that mandates organizations to develop and implement appropriate procedures for information labelling in accordance with their classification scheme. For AI companies, this control is critical to prevent data spillage and ensure compliance with regulations like the EU AI Act by ensuring high-value assets like training datasets and model weights are clearly identifiable and handled securely.

For an AI company, information is not a byproduct of business; it is the core asset and the engine of value. While ISO 27001 Annex A 5.13 Labelling of information might appear to be a simple administrative task, it is the critical foundation for protecting sensitive training data, proprietary models, and client trust in an auditable and defensible way. Mastering this control is a prerequisite for any AI organisation serious about security and governance.

Regulators, auditors, and clients view clear, consistent labelling as a “visible sign of operational maturity.” It demonstrates that your security programme is methodical and that every asset is traceable and accountable. The alternative is a chaotic environment of unlabelled data, which sends a blaring signal that your security is “built on hope, not discipline.” A single missing label can silently undermine your entire security posture, turning a routine audit into a crisis or a minor incident into a headline-making breach.

This guide moves beyond generic advice to break down what Annex A 5.13 means specifically for the unique workflows of an AI company. It provides a clear, practical path to implement robust labelling practices that not only satisfy auditors but also strengthen your operational resilience.

The “No-BS” Translation: Decoding the Requirement

Let’s strip away the consultant-speak. ISO 27001 Annex A 5.13 is not about sticking physical red labels on server racks. It is about ensuring your systems know the difference between “Public Marketing Data” and “Proprietary Model Weights.”

The Auditor’s View (ISO 27001)	The AI Company View (Reality)
“An appropriate set of procedures for information labelling shall be developed and implemented in accordance with the information classification scheme.”	Metadata is king. Don’t just call a file final_v2.csv. Use AWS Resource Tags (classification=confidential) or GitHub Repository Topics (visibility=private). If the computer can’t read the label, it doesn’t exist.
“Procedures for information labelling… need to cover information and its related assets in physical and electronic formats.”	Physical: Put a sticker on the USB drive holding the air-gapped signing keys. Electronic: Configure your DLP (Data Loss Prevention) to block any file tagged Confidential from being pasted into Slack public channels.

The Business Case: Why This Actually Matters for AI Companies

You might think labelling is a waste of engineering cycles. It isn’t. It is the only scalable way to automate security. If you want to move fast, your infrastructure needs to know what it is holding.

The Sales Angle

Enterprise clients are paranoid about “Data Mixing.” They will ask: “How do you guarantee our data is not used to train your public base model?” If your answer is “We have a policy,” they will walk away. If your answer is “All customer data is ingested into S3 buckets automatically tagged ‘No-Train’, and our training pipeline hard-blocks any source with that tag,” you close the deal. Labelling is the technical proof of your promises.

The Risk Angle

The “Open Source” Leak: Your junior dev wants to contribute to open source. They push a repo to public GitHub. Without labelling, they didn’t realise that the utils folder contained a hardcoded API key or a sample of PII. If that repo had been labelled/tagged properly, your pre-commit hooks could have caught it.

DORA, NIS2 and AI Regulation: Labelling is the Law

Regulators are moving from “process” to “governance.” You cannot govern what you cannot identify.

• DORA (Article 8): Requires identification and classification of all information assets. You must label them to map their criticality. If you can’t show which server holds “Critical” data versus “Non-Critical” data, you are non-compliant.
• NIS2 Directive: Mandates security measures appropriate to the risk. You cannot determine the appropriate measure if you haven’t labelled the asset’s risk level first.
• EU AI Act: The transparency requirements for High-Risk AI systems require strict data governance. You must be able to trace training data provenance. Labelling datasets with their source, consent status, and allowable use is now a regulatory requirement, not just best practice.

ISO 27001 Toolkit vs SaaS Platforms: The Tagging Trap

SaaS platforms promise “automated data discovery and labelling.” In reality, they often generate thousands of false positives and create a dependency you can’t break. Here is why the ISO 27001 Toolkit is the smarter play.

Feature	ISO 27001 Toolkit (Hightable.io)	Online SaaS Platform
Simplicity	Clear Protocols. We give you the procedure: “Tag S3 buckets with key Classification.” Your engineers implement it in Terraform. Done.	Black Box Magic. The tool scans your drive and labels a lunch menu as “Confidential.” You spend weeks tuning the “AI” to stop it flagging nonsense.
Ownership	Your Logic. You define the rules in your own policy document. You own the tagging scripts.	Rented Intelligence. If you stop paying, the scanning stops, and you lose the record of what was labelled.
Cost	One-off fee. Pay once. Use the template forever.	Data Tax. Many platforms charge by the Gigabyte scanned. For an AI company with Petabytes of training data, this is financially ruinous.
Freedom	Tech Agnostic. Our procedures work for AWS, Azure, GCP, or a server in your basement.	Integration Hell. If the SaaS tool doesn’t support your specific Vector Database, you have a blind spot.

The AI Challenge: Analysing the Unique Risks of Information Labelling

Standard information labelling practices, designed for traditional corporate documents, often fall short when applied to the unique and complex assets of an AI company. The speed, scale, and nature of AI development create distinct risks that can turn minor labelling oversights into significant security exposures.

Risk 1: Exposure of Sensitive Training Datasets

Failing to correctly label training datasets is a primary risk. An oversight can lead to sensitive personal or proprietary client data being used improperly in model training. Unlabelled legacy datasets stored on cloud archives represent a significant blind spot. If unlabelled data of unknown origin is inadvertently used for retraining, it creates a vector for data poisoning.

Risk 2: Disruption of Algorithmic Processes

AI models, configuration files, and the underlying source code are all critical assets. Mislabelling these assets can have immediate operational consequences, such as an incorrect or outdated model being deployed into production. When different teams—like MLOps and DevOps—develop their own siloed labelling schemes, the resulting inconsistencies create pathways for error.

Risk 3: Vulnerabilities in the AI Supply Chain

The modern AI supply chain is complex. Sending improperly labelled data to an external partner for annotation is a direct path to contractual breaches. Without clear labels, you lose control over how your data is handled once it leaves your perimeter.

Your Blueprint for Compliance: Actionable Steps for AI Companies

Achieving compliance with Annex A 5.13 is not a theoretical exercise but a practical discipline that must be embedded directly into your AI development lifecycle.

Step 1: Establish Your Information Classification Scheme

Before you can label anything, you must know how to classify it. Refer to Annex A 5.12 for the scheme (Public, Internal, Confidential). This must be defined first.

Step 2: Develop a Comprehensive Labelling Procedure

Document a procedure that provides clear instructions. This procedure must cover both digital and physical assets.

• Cloud Assets: Use resource tags (e.g., AWS Tags).
• Documents: Use headers/footers or watermarks.
• Code: Use repository visibility settings and topics.

Step 3: Implement Labelling Across Your AI Lifecycle

With a clear procedure in place, implement it. Apply labels consistently across all assets.

Technique	AI Application Example
Cloud Tagging	Applying Classification: Confidential to an S3 bucket containing PII.
File Naming	Naming a model weights file model_v1_confidential.pt to clearly indicate sensitivity.
Metadata	Tagging a training dataset with source and consent information to ensure GDPR compliance.
Watermarking	Applying a visual watermark to confidential generated images or PDF reports.

Step 4: Train Your Team and Assign Clear Ownership

A procedure is useless if your team doesn’t understand it. Train your engineers on how to apply tags in Terraform or the console. Assign ownership for each asset class to ensure accountability.

The Evidence Locker: What the Auditor Needs to See

When audit week arrives, do not give me a verbal promise. Give me evidence. Prepare these artifacts:

• Labelling Policy (PDF): A signed document explaining how you label (e.g., “We use AWS tags”).
• Screenshots of Infrastructure (Images): Evidence of your S3 buckets, EC2 instances, or Google Drive folders showing the labels/tags in place.
• Data Loss Prevention (DLP) Logs: If you claim to block confidential data transfers, show a log of a blocked attempt.
• Asset Register (Excel): Ensure the “Classification” column matches the labels seen in your screenshots.

Common Pitfalls & Auditor Traps

Here are the top 3 ways AI companies fail Annex A 5.13:

• The “Invisible” Label: You have a policy that says “All confidential documents must be watermarked,” but your engineering diagrams are not. Inconsistency is an instant fail.
• The “SaaS” Hallucination: You trusted an automated tool to label your data, but it missed your proprietary .safetensors files because it didn’t recognise the extension. You are now storing confidential IP as “Unclassified.”
• The “Email” Gap: You label files, but you don’t label emails. If you send a “Confidential” attachment in an email with the subject line “Check this out,” you have broken the chain of custody.

Handling Exceptions: The “Break Glass” Protocol

Sometimes, systems cannot support your labelling scheme (e.g., a legacy database that doesn’t support tags). You need a protocol for this.

The Compensating Control Workflow:

• Identify: System X cannot be labelled.
• Document: Record this in the Risk Register.
• Compensate: Apply a stricter control instead, such as isolating the system on its own VLAN or restricting access to “Admins Only” to mitigate the risk of it being unlabelled.

The Process Layer: “The Standard Operating Procedure (SOP)”

How to operationalise A 5.13 using your existing stack (AWS, Google Workspace).

• Step 1: Define Tags (Manual). Agree on the exact key-value pairs (e.g., DataClassification: Confidential). Case sensitivity matters.
• Step 2: Enforce via IaC (Automated). Update your Terraform modules. Require the DataClassification tag on all resource creations. If a dev tries to deploy an S3 bucket without it, the build fails.
• Step 3: Document Marking (Automated). Configure Google Workspace to force users to select a label (Public/Internal/Confidential) when creating a new document.
• Step 4: Audit (Manual). Once a quarter, run a script to list all resources with DataClassification: Unknown or missing tags. Create tickets to fix them.

For any serious AI company, effective information labelling under Annex A 5.13 is not a compliance burden but a strategic imperative. A disciplined approach to classifying and labelling your core assets—data and models—is a clear indicator of a mature security posture that clients, partners, and regulators demand.

ISO 27001 Annex A 5.13 for AI Companies FAQ

About the author