ISO 27001 Control 5.9 – Inventory of Information and Other Associated Assets

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Developing and Maintaining an Inventory of Information and Other Associated Assets

ISO 27001 Control 5.9 asks organisations to develop and maintain an inventory of information and other associated assets, including their owners.

I’ve built and reviewed asset registers across a wide range of businesses over the past ten years, and the same patterns hold. When I’m working with teams, one of the very first things I try to impress upon them is that we aren’t just talking about physical assets like laptops, desktops, phones, etc., but also information assets like data stores.

We aren’t really protecting the laptop; we are protecting what’s on that laptop. The hardware is just one place where information resides. Most organisations would shrug if a laptop were stolen, but not if that laptop had their entire library of intellectual property or customer database on it unencrypted.

So, in practice, this means you need a reliable list of:

• The information you rely on (data, records, documents, configurations, code, etc.)
• The assets that create, process, store, or transmit that information (systems, services, infrastructure, people and third parties)
• Who is accountable for each one

That inventory serves as the foundation for risk assessment, access management, acceptable use, incident response, and many other controls throughout your ISMS.

Purpose of an Asset Inventory

So, why do we need one, and why does ISO 27001 want us to keep one?

A good asset inventory has several purposes;

• Identifies what needs protecting – By drawing up such a register, we start to understand what information exists, where it sits, and which supporting assets are involved.
• Supports risk-based protection – When we have that list, we can link assets to business processes and risks so that appropriate security measures are applied.
• Assigns ownership and accountability – It’s important to make it clear who is responsible for the security and lifecycle of each asset.
• Enables efficient operations and change – Support troubleshooting, capacity planning, change management and incident response by knowing what you have and how it fits together.
• Demonstrates control for audits and regulators – Provides evidence that you understand your information landscape and are managing it deliberately, not by accident.

Now, if you step back for a moment, these things are not rocket science and are necessary for any organisation to manage itself effectively. ISO 27001 requires it; IT requires asset tracking; Finance requires asset tracking; and a number of regulatory frameworks require it as well (e.g., GDPR).

If you don’t know what you have and where it is, you can’t protect it. Therefore, many of the controls (starting with 5.10 Acceptable use of information and other associated assets and 5.11 Return of Assets) aim to help us mitigate the risks associated with the second part of that previous statement.

A Guide for Asset Inventory Management

There are three steps to getting this right: identify what you have, manage how it changes over time, and apply classification so that the protection matches the value.

1. Identify and Document Assets

Start with the question: “What do we rely on to deliver our services and protect our information?” Then capture those assets in a structured way.

My ISO 27001 toolkit includes an asset register template that gives you the underlying structure. The register itself is just a table, but the discipline of populating it properly is where the value lies. It’ll be unique to every organisation, but the process should be the same.

For larger organisations with potentially hundreds of assets, the trick is to avoid trying to capture everything at once. Pick a vertical (say, employee data) and ask: “What processes this?” and “What does that sit on?” Working through one vertical at a time gives you a coherent register section rather than a long, incomplete list.

ISO 27001 doesn’t mandate what you must record in your asset register, but I’d suggest including the following at a minimum:

• Asset name and description
• Asset type or category (data, hardware, software, service, physical, intangible)
• Owner (the person accountable, not necessarily the person doing the work)
• Location (logical, physical, or both)
• Link to relevant systems, services, or processes, so you can say “what assets does HR use?” and pull back a list

What a Good Asset Register Entry Looks Like

It helps to see this in practice rather than in the abstract. Here are three asset register entries from very different parts of a typical small business, showing how the fields play out:

Three things to notice. First, the owners are senior accountable people, not the IT team, who keep the lights on. Second, the location field is meaningful: for SaaS, it’s the platform and region, for data, it’s the system that holds it, for hardware, it’s the physical site. Third, every asset belongs to a service group, which makes the register usable for risk assessments, incident response, or BCP work rather than just ticking the box.

Smaller organisations can often combine this with their risk register; larger environments benefit from dedicated asset registers and configuration management databases (CMDBs). Modern tools like Microsoft Purview can help with data asset discovery and classification, and asset tracking tools work well for physical inventories.

2. Manage the Asset Lifecycle

A register that’s out of date the moment you save it is worse than no register at all, because it gives false confidence. I’ve been on enough IT teams over the past 30 years to tell you that a manually maintained asset database starts to decay the second you save it, and it turns into shelfware.

The answer is to integrate the register into the processes that already touch assets, rather than running it as a separate exercise. There are three lifecycle hooks that matter most:

Auditors gravitate towards lifecycle processes for asset management because they know that without robust JML and change integration, registers go stale fast. They also see parallels with access control and account provisioning; if your asset register is poorly maintained, your access control records are probably too. Both controls (5.9 and 5.15) tend to pass or fail together.

3. Classify Assets to Drive Protection

Knowing what you have is necessary but not sufficient. The next step is classifying each asset so that the level of protection matches the value at risk.

There are two layers to this:

Information classification. Apply your agreed classification scheme (typically, I use something simple like Public, Internal, Confidential, and possibly a Restricted tier for highly sensitive material) to data assets and the systems that hold them. The classification then drives practical security measures: who can access the data, whether it needs to be encrypted, how it can be transferred, and what handling rules apply. This links directly to Control 5.12 (Classification of Information) and Control 5.13 (Labelling of Information).

Business criticality. Separate from the data classification, ask: what would happen to the business if this asset were lost, corrupted, or unavailable? Some assets carry routine data but underpin critical processes; others carry sensitive data, but the business could carry on if they were briefly unavailable. Capturing criticality alongside classification gives you a fuller picture of what to protect first.

For each asset, the classification and criticality together inform:

• Access control decisions (Control 5.15)
• Backup and recovery priorities (Control 8.13)
• Monitoring and logging scope (Controls 8.15 and 8.16)
• Business continuity planning (Controls 5.29 and 5.30)
• Incident response prioritisation (Control 5.24)

You don’t need to do this at the individual record level. Classifying at the asset group level (the level at which the example register above is written) is enough for most SMEs. If a group of assets has mixed classifications, classify at the highest level present in the group and note the mix in the asset’s description.

A practical observation: most SMEs over-classify when they first build this. Everything gets marked Confidential because it feels safer, and then the classification stops driving any actual decisions because everything is treated the same. The point of classification is to differentiate so you can prioritise. If 90% of your assets are Confidential, the classification isn’t doing any work. Be willing to mark internal-only documentation as Internal and public marketing material as Public; that’s how the system earns its keep.

Asset Ownership and Service Grouping

Knowing what you have is only half the job. The other half is knowing who is accountable for each asset, and how the assets relate to the services the business actually delivers.

Ownership: accountability stays, even when work is delegated

I touched on ownership earlier when defining the asset register fields, but it’s worth being explicit about what “owner” means in practice, because it’s one of the most commonly misunderstood parts of 5.9.

The asset owner is the person accountable for the security of an asset. They are not necessarily the person doing the work. For most assets in an SME, day-to-day activities are delegated: patching is done by IT, monitoring is done by a security tool, backups run automatically, and users are provisioned through a JML process. None of that changes who is accountable.

A quick example: The Head of HR would be the owner of the HR system, but the IT Manager is responsible for patching the server it runs on, the supplier is responsible for the underlying platform availability, and a third-party MSP might be running the backup. Four parties are involved in the operational work. Only one is accountable to the auditor when something goes wrong.

This matters because the most common audit finding I see on 5.9 is a lack of a comprehensive register with ownership. If I were to pounce on the asset owner, and they were unable to answer basic questions about their asset. “Who has access to it? When was it last reviewed? What’s the recovery time objective? Who’ll be told first if it goes down?” Then, the ownership is nominal rather than real. Either the owner needs to be brought into the operational picture, or accountability needs to move to someone who is.

A short quarterly review with each major asset owner could resolve this (15-20 minutes is enough), where you walk through their assets, the current state, and any decisions they need to make. This would keep ownership genuine rather than ceremonial, and the meeting itself would provide good audit evidence. You really do have to push the ownership, I’m afraid, or you end up with that ‘I’m sitting at the table, but looking at my phone’ level of engagement, which is no use to anyone.

Service grouping: managing assets together, not as islands

Most asset registers are just flat lists. Every laptop, every system, every supplier, every dataset in one long table. That’s fine as a record, but it’s a poor management tool because real-world decisions affect groups of assets at once, not individual ones.

A better mental model is to group assets around the services they deliver. For example:

The “Customer Portal” service might include:

• The web application and its source code
• The database holding customer data
• The Content Delivery Network (CDN) and the firewall in front of it
• The logging and monitoring platform
• The supporting SaaS tools (authentication provider, email service, payment processor)
• The supplier contracts for hosted components

All of these are individual assets, but for risk management, incident response, and change control, they function as a single service. If the customer portal goes down, you don’t think about the database and the CDN separately; you think about the service.

Another Example;

The “Employee Records” service might include:

• The HR system itself
• The payroll system that feeds from it
• Document storage for contracts and personnel files
• The identity provider that controls access
• Key reports that draw from HR data

Grouping like this means a service owner can sensibly look at the whole picture: where the data lives, who has access, what depends on what, and what protections are in place across the group. It also means that when a change is proposed (a new HR module, a switch to a payroll provider), the impact assessment naturally covers the service rather than just one asset at a time.

For a smaller business, you don’t need many service groups. I’d say five to ten typically covers everything that matters: Customer Portal, Employee Records, Financial Systems, Internal Collaboration, Production Infrastructure, and a few others, depending on the business.

The asset register sits beneath the service groupings, and each group has a named service owner who is accountable for the whole picture.

Common Audit Findings on Control 5.9

Wearing my internal auditor hat for a moment, the findings on 5.9 are remarkably consistent across the organisations. If you want to avoid the obvious traps, these are the ones to watch:

Issue: The register is incomplete.

Almost always missing in this order: SaaS subscriptions bought on a card by an individual department, data assets held in spreadsheets and shared drives, supplier-provided systems where the organisation has access but doesn’t own the infrastructure, and information held outside the office (in MSP environments, client systems, archives). If your register is mostly hardware and on-premise systems in 2026, it’s incomplete. However, you should have some kind of register of cloud services under control 5.23 Information security for use of cloud services.

Issue: Ownership is missing or nominal.

As I mentioned earlier, the named owner is either missing, the same name for every information asset, or cannot answer basic questions about the asset when asked. This is the easiest finding to write up, because the evidence is the owner’s own response in the room.

Issue: The register isn’t up to date.

Joiners and leavers have come and gone, suppliers have changed, systems have been retired, but the register hasn’t moved. The giveaway is comparing the register against the JML log or the procurement list to find mismatches.

Issue: Disconnect with the risk register and SoA.

The asset register exists, but the risks on the risk register don’t reference assets, and the Statement of Applicability doesn’t reflect what’s actually in the register. This is a sign the asset register has been built as a standalone document rather than as the foundation it’s supposed to be. You should be looking at risks to information assets, so establishing a relationship here would be ideal.

The good news is that none of these findings is hard to fix; they just need someone to push the discipline of keeping the register honest, integrated, and used.

How Control 5.9 Supports GDPR Article 30

Quick aside for anyone who is also working towards GDPR compliance, which I find most are these days. There’s a direct overlap between the asset register required by ISO 27001 Control 5.9 and the Records of Processing Activities (RoPA) required by Article 30 of the GDPR.

Article 30 asks controllers and processors to maintain a record of the categories of personal data they process, the purposes of processing, the recipients, transfers, retention periods, and the security measures in place. So, every entry on that record corresponds to a data asset, a system that processes it, a supplier or service that touches it, and an owner; all of which are in your asset register if you’ve done 5.9 properly.

This means if you build the asset register well, you’ve done most of the heavy lifting for Article 30. A small extension to the register (data categories, lawful basis, retention period, transfer details) turns it into a RoPA. Conversely, if you’re starting with GDPR, you’re already building the foundation of your ISO 27001 asset register without realising it.

I cover GDPR more fully on the GDPR page, but worth flagging here because the two requirements are far more aligned than they first appear, and treating them as one piece of work rather than two saves significant effort.

Minimum Viable Compliance for Control 5.9

For a small business that’s read the above and said, great, but that’s a lot of effort to go to, then if you only do four things, do these:

1. List every system that holds personal or commercially sensitive data, every SaaS subscription, and every supplier with access to your data.
2. Give each one a named owner (a person, not a team).
3. Classify each, e.g. Public, Internal, or Confidential.
4. Review the list quarterly and update it when people join, leave, or you buy new tools.

If you can answer “where is our data, who owns it, and when was this last reviewed?” you’re at the bar. Everything else is a case of maturity.

Further Reading

A few additional external sources with tools and resources worth a look for another perspective:

• NCSC Asset Management Guidance: The UK government’s view on why asset management is the foundation of cyber security.
  
• NCSC CAF Principle A3: A maturity benchmark for what good asset management looks like at “achieved” and “not achieved” levels.
  
• ICO Documentation Guidance and RoPA Templates: Free downloadable templates for the GDPR Article 30 side of this work.
  
• NIST Cybersecurity Framework 2.0: The same asset management principles expressed in the international framework that most US customers will recognise.

FAQs

Conclusion

An effective inventory of information and other associated assets is one of the quiet foundations of a strong ISMS. By:

• Identifying your information and supporting assets
• Assigning clear ownership and responsibilities
• Keeping your inventory accurate and integrated into everyday processes

You make it much easier to manage risk, demonstrate compliance, and respond quickly when things change.

ISO 27001 Control 5.9 is not about creating a beautiful list for an auditor; it is about giving your organisation a clear picture of what matters, who is responsible, and how those assets are being protected in practice.

Author Background

This article was written by Alan Parker, an ISO 27001 consultant and founder of Iseo Blue Limited. He helps UK SMEs achieve certification in 90 days or less, often without a dedicated security team or a large budget.

With over 30 years in IT governance and information security, Alan works with software companies, IT service providers, managed service providers, and professional services firms across the UK, Europe, and internationally.

Qualifications: Certified ISO 27001 Lead Auditor (ANAB-accredited certification),
ITIL v3 Expert, ITIL v4 Bridge, PRINCE2 Practitioner. Named IT Project Expert of the Year (2024, UK). Alan writes in plain English for busy teams who need to get things done.

Connect on LinkedIn or Bluesky, or explore his free ISO 27001 tools and templates at iseoblue.com. B.Sc (Hons) Information Systems, CISMP certified.

Alan Parker