If you ask a traditional IT manager to list their assets, they will point to a spreadsheet listing laptops, servers, and maybe a printer or two. If you ask an AI founder the same question, the answer is a lot messier.
Your most valuable assets aren’t physical. They are 70-billion-parameter model weights sitting in an S3 bucket. They are terabytes of cleaned training data. They are API keys for OpenAI or Anthropic hardcoded into a developer’s environment variables.
ISO 27001 Annex A 5.9: Inventory of Information and Other Associated Assets is the control that forces you to untangle this mess. For AI companies, this isn’t just about compliance; it is about protecting the intellectual property that defines your valuation.
Here is how to implement Annex A 5.9 when your “assets” are probabilistic, ephemeral, and scattered across the cloud.
What is Annex A 5.9 Actually Asking For?
The 2022 update of the standard shifted the language slightly but significantly. It now asks for an inventory of information and other associated assets.
This distinction is critical for AI.
- Information: This is the data itself. (e.g., The proprietary dataset you scraped, the fine-tuned model weights, the customer prompts).
- Associated Assets: This is the container or tool holding that information. (e.g., The AWS S3 bucket, the Pinecone vector database, the Hugging Face repository).
To pass the audit, you need to identify these assets, assign an owner to them, and classify them based on how sensitive they are.
The AI Asset Challenge: It’s Not Just Laptops
Standard asset templates don’t work for AI companies. You need to customize your inventory to capture the lifecycle of machine learning. Here are the specific categories you need to track.
1. Data Assets (The Gold)
You cannot just list “Data” as a single line item. You need granularity.
- Training Data: Raw vs. Cleaned. Who owns the cleaning script?
- Validation/Test Sets: If these leak, your benchmarks are useless.
- RAG Knowledge Bases: The vectorized documents your LLM retrieves answers from. This often contains your most sensitive IP.
2. Model Assets (The Engine)
Is a model software or data? For ISO 27001, it’s usually treated as an information asset.
- Model Weights: If you trained a Llama-3 derivative on proprietary data, those weights are a critical asset.
- System Prompts: The “secret sauce” instructions that govern your agent’s behavior.
- Checkpoints: The saved states of your model during training.
3. Compute and Service Assets (The Infrastructure)
This includes the tools that process your information.
- GPU Clusters: Whether on-prem or reserved instances in the cloud.
- Vector Databases: Pinecone, Weaviate, or Milvus instances.
- Model Registries: MLflow or Weights & Biases projects.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Step 1: Identifying “Shadow AI”
The first step in implementation is discovery. In AI startups, “Shadow IT” is rampant. Developers often spin up new tools to test a hypothesis and forget to shut them down.
Send a query to your engineering team: “Where are we storing model artifacts right now?”
You will likely find that while production models are in a secure bucket, there are dozens of experimental models sitting in personal Google Drives or public GitHub repos. Bring these into the inventory.
Step 2: Assigning Ownership (Who Owns the Model?)
Annex A 5.9 requires every asset to have an Owner. In AI, this is tricky. Who owns the model? The Data Scientist who trained it? The MLOps engineer who deployed it? Or the Product Manager?
Best Practice: Assign ownership to the role that decides who has access to the asset.
- Head of Data Science: Owns the Training Data and Model Weights.
- Head of Infrastructure: Owns the GPU Clusters and Cloud Accounts.
- CTO: Owns the Source Code and Algorithms.
Step 3: Building the Register
You need a central source of truth. A spreadsheet is fine to start, provided it has the right columns. Your AI Asset Register should track:
- Asset Name: (e.g., “Customer Support Fine-Tuned Model v2”)
- Type: (Information – Model Weights)
- Format/Location: (AWS S3 – us-east-1)
- Owner: (Lead ML Engineer)
- Classification: (Confidential – IP)
If you are struggling to structure this effectively, Hightable.io offers ISO 27001 toolkits that include Asset Inventory templates specifically designed to handle the nuances of “Information” vs “Associated Assets.” Using a pre-built template ensures you don’t miss the required fields that auditors look for.
Step 4: Managing Lifecycle (The Dynamic Inventory)
AI assets are ephemeral. You might spin up 100 GPU instances for a training run and shut them down three days later. Do you need to log every single instance in your spreadsheet?
The Auditor’s View: No. You document the Group or the Service. You list “Training Cluster Configuration” as the asset, not “GPU #492.” However, for persistent assets like datasets, you must track them from creation to deletion.
Ensure your offboarding process covers AI assets. When a Data Scientist leaves, do you revoke their access to Hugging Face? Do you check if they have local copies of the training data?
Common Pitfalls for AI Companies
Ignoring API Keys:
Your OpenAI or Anthropic API key is effectively a blank check for your company’s bank account. Treat it as a “High Criticality” information asset.
Forgetting “Derived” Data:
You listed the raw dataset, but what about the vectorized embeddings? If someone steals your vector store, they can reconstruct much of your proprietary knowledge. Inventory the embeddings too.
Conclusion
ISO 27001 Annex A 5.9 is the foundation of your AI security strategy. You cannot secure your models if you don’t know where they live or who owns them. By building a comprehensive inventory that respects the unique nature of AI assets—from weights to vectors—you protect your IP and ensure your compliance journey is a success.
Start by mapping your data pipeline today. Identify where the value is created and stored. And if you need a head start, check out the resources at Hightable.io to get your asset documentation audit-ready.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
