You can't assess a risk against an asset you haven't identified. You can't map a control to a system you don't know exists. The asset inventory is where Clause 4 (context) and Clause 6 (risk) stop being abstract and anchor to something real: a documented list of what you actually protect.

A missing or out-of-date inventory is one of the most consistently cited nonconformities at Stage 2 audit. Auditors don't treat it as a formality. They treat it as the test of whether your risk management has any foundation at all.

If you run entirely in the cloud — no server room, no on-premise infrastructure — it's tempting to assume the asset inventory is a minor concern. It isn't. That's exactly where assets multiply unnoticed: a new project management tool here, a freelancer's personal Notion workspace there. The inventory question for these organisations isn't "what hardware do we own?" but "what data lives where, who controls it, and what happens when someone leaves?"

Asset management in ISO 27001

In ISO 27001:2022, the requirement to keep an asset inventory sits in Control A.5.9, part of the asset and data management controls. It works alongside four closely related controls:

• A.5.10 — Acceptable use of information and other associated assets
• A.5.12 — Classification of information
• A.5.13 — Labelling of information
• A.5.14 — Information transfer

The asset inventory is the foundation those four rely on. You can't enforce acceptable use or guarantee the return of assets at offboarding if you haven't first identified what the assets are. In practice, the standard requires you to:

• identify all assets within the ISMS scope,
• document them in an information asset register (IAR),
• assign a named owner to each, and
• keep the register complete and current.

Done well, every team member knows which tools the company uses, who's responsible for them, and how to request access. The register stops being a compliance artefact and becomes a reference point your team actually uses.

The standard deliberately refers to "information and other associated assets." That distinction is intentional — and it's also the best way to build your register for the first time.

Assets generally fall into two layers — a distinction ISO 27001 builds on as well:

• Primary assets (information) — the data itself: what your organisation creates, processes, and has to protect.
• Secondary assets (associated assets) — the systems, tools, and infrastructure that process, store, or transmit that data.

Start with the primary layer. These are the things that, if lost, leaked, or damaged, would do real harm to your organisation or your customers. For most small companies that comes down to three categories:

• Customer data — names, contact details, delivery information, anything a customer has entrusted to you.
• Intellectual property — source code, templates, methodologies, anything that makes the way you deliver unique.
• HR data — contracts, salary data, personal information held for HR purposes.

These are your crown jewels. Everything else in the inventory exists only to process, store, or transmit them.

Once your primary information assets are mapped, the next step is to identify the secondary assets — everything that processes, stores, or transmits that data. ISO 27002:2022 groups them into five categories. The examples below reflect what a remote-working, SaaS-oriented organisation is most likely to encounter:

• Software & cloud services — the tools and platforms your team uses day to day.
• Hardware — the physical devices the team works on.
• Services — third-party dependencies your operations rely on.
• People — roles and individuals essential to managing or processing information.
• Locations — where assets sit, physically or logically.

Every SaaS tool, cloud platform, and outsourced service in your register is also a supplier relationship — and each carries third-party risk that has to be actively managed. The asset inventory is where those dependencies become visible and gain an owner.

The supplier management controls (A.5.19–A.5.22) help you assess, contract, monitor, and offboard suppliers — right down to building a dedicated supplier register.

A list of assets isn't enough. ISO 27001 requires you to understand how sensitive each asset is — what the standard calls information classification, covered in A.5.12, and it ties directly back to the asset inventory.

The most practical tool for this is a CIA analysis: rating each asset across three dimensions — confidentiality, integrity, and availability — each as high, medium, or low. The combination produces a protection-needs profile for every asset, and that profile tells you which controls to prioritise.

Rating each asset across C, I and A gives its overall protection need — taken as the highest of the three. This lets you prioritise the highest-need assets first for risk identification, and set policy rules by criticality, where the rating triggers required controls: for example, any asset with a high availability need must have backups enabled.

The example below shows a well-structured IAR for a small, remote-working, SaaS-oriented organisation. Each row is one asset. Two things to note before you read it:

CIA score and classification are not the same thing

This is one of the most common points of confusion, so to be explicit:

The CIA score measures impact: how severe would the loss of confidentiality, integrity, or availability be for this specific asset? Each dimension is rated independently as high, medium, or low — that's your analytical input.

The classification is the label that results from that analysis — the human-readable category (Public / Internal / Restricted / Confidential) that governs how the asset is handled — that's your operational output.

Classification drives the controls

Once an asset carries a classification label, that label determines which controls apply. Instead of deciding case by case, you define the rules once and apply them consistently.

That's how you protect your crown jewels efficiently — not by throwing maximum controls at everything, but by letting classification do the work of deciding how much protection each asset actually needs.

Map secondary assets to primary assets

Best practice — and auditor expectation — is to link each secondary asset to the primary information asset it holds. That's what makes the register operationally useful: when you need to know which controls apply to Supabase, you look up which primary assets it holds, read their classification, and the required controls follow automatically. The table below maps that relationship.

C = Confidentiality, I = Integrity, A = Availability. H = High, M = Medium, L = Low.

Identifying your assets is only half the work. The other half is understanding how sensitive each one is — and that's where A.5.12 comes in.

The asset inventory tells you which assets exist; A.5.12 tells you how much protection each one needs. The two work together, and auditors check that your register reflects both — not just a list of tools and data types, but a clear, consistently applied statement of sensitivity for every entry.

What classification means in practice

• A classification label reflects the potential impact of unauthorised access, alteration, or loss.
• ISO 27001 doesn't mandate a particular scheme — you define the levels that make sense for your organisation.
• A common four-tier scheme: Public / Internal / Restricted / Confidential.
• Every asset gets a label — and that label drives which controls apply to it.

A register created once and never touched again isn't compliance — it's just a document. ISO 27001 requires active maintenance, and auditors look for evidence of it: dates, owner confirmations, a traceable change history — not merely the existence of a file.

The register has to be updated at every stage of the asset lifecycle:

• Creation / procurement — a new tool, system, or data category enters scope: record it immediately, even for a trial.
• Assignment — a team member gains access to assets: capture what was provisioned, to whom, and when.
• Change — an asset is modified or migrated, or a supplier relationship changes (new vendor, renewal, scope change): bring the register up to date.
• Transfer — ownership changes hands, or a team member moves into a new role with a different access profile: reassign and re-document.
• Revocation / return — a team member leaves: confirm that assets were returned and access removed, and record both.
• Disposal / decommissioning — a tool is retired, a service ended, or a dataset deleted: mark it out of service and retain the entry for audit purposes rather than deleting the row.

Stage 2 auditors approach the asset inventory as a traceability exercise. Its mere existence isn't enough. They check whether it's complete, whether ownership is real, whether classification actually drives decisions — and whether the register is actively maintained or quietly abandoned after initial certification.

In particular, they check for:

• a documented, accessible IAR covering both primary information assets and the IT systems that process, store, or transmit them;
• a named, individual owner per asset — not a team, not a department, but a person;
• classification labels applied consistently to every entry;
• evidence of active maintenance — dates, owner sign-offs, change history;
• a traceable record that offboarding triggers the return of assets and removal of access (A.5.11).

Your asset inventory feeds directly into your risk assessment (Clause 6) and your Statement of Applicability (SoA). Every control you select from Annex A should be traceable to an asset in your register. If it isn't, you can't justify why the control is in scope — and auditors will notice. For how the asset inventory fits into the wider ISMS structure, see "ISO 27001 Clauses 4–10: The first steps in setting up your ISMS." For setting the scope that determines which assets are in scope at all, see "ISO 27001 Clause 4: How to perform a context analysis."