ISO 27001:2022 Annex A 5.12 Classification of information for AI Companies

ISO 27001 Annex A 5.12 Classification of information is a security control that requires organizations to categorize information based on legal requirements, value, and sensitivity. For AI companies, implementation of this control is essential to prevent unauthorized disclosure of proprietary algorithms and training data, ensuring that security measures scale efficiently with the sensitivity of the asset.

For a high-growth AI company, information is more than just an asset. It is the engine of your value. Your proprietary algorithms, training datasets, code, and sensitive client details are your most critical resources. In this context, you should not look at ISO 27001 Annex A 5.12 Classification of information as just another rule to follow. Instead, view it as a core strategy to protect your intellectual property.

This guide provides a simple framework to help you implement this control. It ensures you can show robust governance to auditors, investors, and clients.

The “No-BS” Translation: Decoding the Requirement

Let’s strip away the consultant jargon. Classification isn’t about putting “TOP SECRET” stamps on physical folders like a 1970s spy movie. It is about tagging your AWS buckets so you don’t accidentally publish your customer database to the internet.

The Auditor’s View (ISO 27001)	The AI Company View (Reality)
“Information shall be classified in terms of legal requirements, value, criticality and sensitivity to unauthorised disclosure or modification.”	Tag your assets. If an S3 bucket contains PII, tag it confidential. If a repo contains open-source code, tag it public. If you don’t label it, your junior dev will leak it.
“Classifications and associated handling controls for information shall be developed and implemented.”	Define the rules. If a file is confidential, can I paste it into ChatGPT? (No). Can I put it on a USB stick? (No). Write this down so there is no debate.

The Business Case: Why This Actually Matters for AI Companies

You might think classification is boring admin work. It isn’t. It is the only way to scale your security without slowing down your engineering team.

The Sales Angle

Enterprise clients will ask: “How do you segregate our data from other tenants?” If your answer is “We try our best,” you lose. If your answer is “We use automated classification tags to enforce logical separation at the database level,” you win. Annex A 5.12 gives you the vocabulary to win that argument.

The Risk Angle

The “Training Data” Leak: Imagine you accidentally include a “Confidential” customer dataset in a “Public” training run for your open-source model. You have just open-sourced your client’s trade secrets. Classification prevents this by triggering alerts when sensitive tags move into public pipelines.

DORA, NIS2 and AI Regulation: Label It or Lose It

Regulators are moving from “security” to “data governance.” You cannot govern what you haven’t labelled.

• DORA (Article 8): Requires financial entities to classify ICT assets based on criticality. If you provide AI to a bank, you must mirror their classification scheme.
• NIS2 Directive: Mandates risk analysis. You cannot analyse risk if you treat your marketing brochures with the same security level as your encryption keys. Classification is the first step in risk assessment.
• EU AI Act: Distinguishes between “High Risk” and “Low Risk” AI systems. Your internal data classification must align with these regulatory categories to ensure you apply the right conformity assessments.

ISO 27001 Toolkit vs SaaS Platforms: The Classification Trap

SaaS platforms often over-complicate classification with complex “data discovery” tools that generate too much noise. Here is why the ISO 27001 Toolkit is the better approach.

Feature	ISO 27001 Toolkit (Hightable.io)	Online SaaS Platform
Simplicity	3-Tier Model. We give you a proven “Public / Internal / Confidential” policy in Word. You can adopt it in 10 minutes.	Over-engineering. Platforms often push complex DLP (Data Loss Prevention) rules that block legitimate work and frustrate developers.
Ownership	Your Policy. You own the document. You define the rules.	Black Box. The platform scans your Google Drive and applies tags you don’t understand, creating a mess of “False Positives.”
Cost	One-off fee. Pay once. Classify forever.	Volume Pricing. Many platforms charge by the gigabyte scanned. For an AI company with TBs of data, this is bankruptcy.
Freedom	Agnostic. Works for AWS, Azure, Google Drive, or paper.	Integration Limits. If the platform doesn’t integrate with your specific vector database (e.g., Pinecone), you have a compliance gap.

The Strategic Starting Line: Why Classification Is the Bedrock of Your Security

Information classification is your strategic starting line for building an Information Security Management System (ISMS). If you get this wrong, the consequences are immediate. You might waste money protecting data that does not matter. Even worse, you might fail to protect your “crown jewels” like source code and training data. Without a clear system, your security lacks focus.

The core goal of Annex A 5.12 is to create an internal priority system. It ensures you apply security based on real risks. As one auditor noted, you would not use “Fort Knox level security” for a public brochure. That would waste your budget and slow everyone down.

Decoding the Requirement: What ISO 27001 Annex A 5.12 Actually Demands

To satisfy an auditor, you must understand what the standard requires. The rule is clear. You must categorise your information based on a risk-informed rationale. This involves two main sets of criteria.

The CIA Triad

This is the classic model of information security. Your classification must look at your needs for:

• Confidentiality: Preventing unauthorised access. (e.g., Your Model Weights)
• Integrity: Keeping data accurate and trustworthy. (e.g., Your Training Data Cleanliness)
• Availability: Ensuring data is there when you need it. (e.g., Your API Uptime)

The Golden Rule of Classification: Keep It Simple

Simplicity is the key to success. You might want to build a complex system, but this often backfires. If you over-engineer the process, your team will likely ignore it.

If you create six or seven levels, you cause “decision fatigue.” Busy employees will either ignore the scheme or mark everything as “top secret” just to be safe. This defeats the purpose of prioritisation. As auditors often say, a complicated scheme is a useless scheme. Its value comes from consistent daily use.

A Practical 3-Level Classification Scheme for AI Companies

For most fast-paced AI companies, a three-level scheme is the best approach. It is practical and meets ISO 27001 standards. It answers one key question: “What is the impact if this data leaks?”

Level 1: Public

This is for information that poses no risk if disclosed. If this data appeared on the news, it would not harm you.

Examples for an AI Company:

• Marketing materials and whitepapers.
• Public API documentation.
• Open-source model weights (e.g., uploaded to Hugging Face).

Level 2: Internal

This covers information meant only for your organisation. If it leaks, it might cause minor damage or operational issues, but it would not be a disaster.

Examples for an AI Company:

• Internal process documents (Confluence/Notion pages).
• Slack messages about lunch or general updates.
• Draft product roadmaps.

Level 3: Confidential (or Restricted)

This is the highest level for your most sensitive assets. If this data is exposed, it could cause major damage, financial loss, or legal issues. This is where you focus your security efforts.

Examples for an AI Company:

• Proprietary Model Weights: The secret sauce.
• Customer Training Data: PII or sensitive IP provided by clients.
• API Keys and Secrets: Access to your infrastructure.

Your 6-Step Implementation Roadmap to Ace the Audit

To pass your audit, you need more than just a list of levels. You need a maintained system. Before you start, ensure you have a current data asset register. You cannot classify data if you do not know what you have or where it lives.

The Evidence Locker: What the Auditor Needs to See

When the audit comes, prepare these 3-5 specific artifacts to prove compliance. This turns “audit panic” into a simple file-gathering exercise.

• The Classification Policy (PDF): A signed document defining “Public,” “Internal,” and “Confidential.”
• Asset Register (Excel): A column in your asset register explicitly stating the classification level (e.g., “Customer DB | Confidential”).
• System Configs (Screenshots): Screenshots of AWS S3 Bucket tags showing classification=confidential.
• Handling Guidelines (Intranet Page): A “Cheat Sheet” for employees showing what they can and cannot do with each level (e.g., “Do not put Confidential data in ChatGPT”).

Common Pitfalls & Auditor Traps

Avoid these mistakes that will get you a Non-Conformity.

• The “Unlabelled” Slide Deck: You present a slide deck marked “Strictly Private” but your policy calls it “Confidential.” Inconsistency is a fail. Stick to your defined terms.
• The “Everything is Confidential” Trap: If you mark the lunch menu as “Confidential,” the auditor knows your system is broken. It shows users are ignoring the definitions.
• The “Shadow AI” Gap: You classified your SQL database but forgot to classify the vector database (e.g., Pinecone/Weaviate) holding the embeddings. This is a major gap in scope.

Handling Exceptions: The “Break Glass” Protocol

Sometimes, you need to downgrade classification (e.g., open-sourcing an internal tool). You need a process for this.

The Reclassification Workflow:

• Request: Product Owner requests to change “Internal” code to “Public” (Open Source).
• Review: Security/Legal reviews the code for hardcoded secrets or PII.
• Approval: CTO approves the change in classification.
• Log: Update the Asset Register to reflect the new status.

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

How to operationalise A 5.12 using your existing stack (Google Workspace, Linear).

• Step 1: Default Labelling (Automated). Configure Google Workspace to default all new documents to “Internal.” This covers 80% of your data without user effort.
• Step 2: Critical Asset Tagging (Manual). When creating a new repository in GitHub, the Engineer must select the “Topic” (Public/Private) which maps to your classification scheme.
• Step 3: DLP Enforcement (Automated). Use a simple rule in Slack: If a file marked “Confidential” is shared in a public channel (#general), block it and alert the sender.
• Step 4: Review (Manual). Once a year, export your asset list and ask owners: “Is this still Confidential?”

Information classification is more than a box to tick. It is the foundation of a smart security program. Success comes from being practical and keeping things simple. For an AI company, mastering this control is a business enabler. It shows you manage risk well and care for your IP.

ISO 27001 Annex A 5.12 for AI Companies FAQ

About the author