You cannot assess a risk against an asset you haven't identified. You cannot assign a control to a system you don't know exists. Control A.5.9 is where Clause 4 (context) and Clause 6 (risk) stop being abstract and get grounded in something real, a documented list of what you are actually protecting.
A missing or outdated register is one of the most consistently cited non-conformities at Stage 2 audit. Auditors do not treat it as a formality. They treat it as evidence that your risk management process has no foundation.

Why SaaS-heavy organisations have it harder, not easier

For organisations that run entirely in the cloud — no server room, no on-premise infrastructure — it is tempting to assume the asset inventory is a light-touch exercise. It is not. Assets multiply quietly: a new project management tool here, a freelancer's personal Notion workspace there. The inventory question for these organisations is not "what hardware do we own" — it is "what data lives where, who controls it, and what happens when someone leaves."

A.5.9 sits within the asset and data management controls in ISO 27001:2022, 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

A.5.9 is the foundation all four depend on. You cannot enforce acceptable use or ensure return of assets at offboarding if you have not first identified what the assets are. The control requires you to:

• Identify all assets within the ISMS scope.
• Document them in an Information Asset Register (IAR).
• Assign a named owner to each.
• Keep the register accurate and current.

In practice, this means every team member knows what tools the company uses, who owns them, and how to request access. The register stops being a compliance artefact and becomes the reference point your team actually uses.

The standard refers to "information and other associated assets." That distinction is intentional — and it is the best way to approach building your register for the first time.

ISO 27001 separates assets into two layers:

• Primary assets (information) — the data itself: what your organisation creates, processes, and is responsible for protecting.
• 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 corrupted, would cause real harm to your organisation or your clients. For most small businesses, this means three categories:

• Customer data — names, contact details, delivery data, anything a client has entrusted to you.
• Intellectual property — source code, templates, methodologies, anything proprietary to how you deliver your service.
• Employee records — contracts, payroll data, personal information held for HR purposes.

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

Once you have mapped your primary information assets, the next step is identifying the secondary assets — everything that processes, stores, or transmits that data. ISO 27002:2022 groups these into five categories. For each one, the examples below reflect what a remote, SaaS-first 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 are physically or logically housed.

Supplier relationships are assets too

Every SaaS tool, cloud platform, or outsourced service in your register is also a supplier relationship, and each one carries third-party risk that needs to be actively managed. The asset register is where those dependencies become visible and owned.

Supplier Management controls (A.5.19–A.5.22) help to assess, contract, monitor, and offboard suppliers, including building a dedicated supplier register.

A list of assets is not enough. ISO 27001 requires you to understand how sensitive each asset is — this is what the standard calls information classification, covered in A.5.12 — and it connects directly to A.5.9.

The most practical tool for this is a CIA analysis — rating each asset across three dimensions. Rate each dimension as High, Medium, or Low. The combination gives you a protection needs profile for every asset — and that profile tells you which controls to prioritise.

Here is an example of what a well-structured IAR looks like for a small, remote, SaaS-first organisation. Every row represents one asset. A few things to note before reading the table:

CIA Score vs. Classification — they are not the same thing

This is one of the most common points of confusion, so it is worth being explicit:

• CIA Score measures impact — how serious would the loss of Confidentiality, Integrity, or Availability be for this specific asset? Each dimension is rated High, Medium, or Low independently. This is your analytical input.
• Classification is the label that results from that analysis — the human-readable category (Public / Internal / Restricted / Confidential) that governs how the asset must be handled. This is your operational output.

Classification drives controls

Once an asset has a classification label, that label determines which controls apply. Rather than deciding case-by-case, you define rules once and apply them consistently.

This is how you protect your crown jewels efficiently — not by applying maximum controls to everything, but by letting classification do the work of deciding what level of protection each asset deserves.

Mapping secondary assets onto primary assets

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

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

Identifying your assets is only half the job. The other half is understanding how sensitive each one is, and that is where A.5.12 comes in.

A.5.9 tells you what assets exist. A.5.12 tells you how much protection each one needs. The two controls are designed to work together, and auditors will check that your register reflects both, not just a list of tools and data types, but a clear indication of sensitivity level applied consistently across every entry.

What classification means in practice

• Classification is a label that reflects the potential impact of unauthorised access, modification, or loss.
• ISO 27001 does not prescribe a specific classification scheme — you define the levels that make sense for your organisation.
• A common four-level scheme: Public / Internal / Restricted / Confidential
• Every asset in your register gets a label — and that label drives which controls apply to it.

An asset register built once and never updated is not compliance. It is a document. ISO 27001 requires the register to be maintained, and auditors will look for evidence of active upkeep like dates, owner attestations, update history, not just the existence of a file.

The register must be updated at every stage of an asset's lifecycle:

• Creation / acquisition — a new tool is adopted, a new system is provisioned, or a new data category comes into scope: log it immediately, even on a trial basis.
• Assignment — a team member joins and is granted access to assets: record what was provisioned, to whom, and when.
• Change — the asset is modified, migrated, or a supplier relationship changes (new vendor, contract renewal, scope change): update the register to reflect the new state.
• Transfer — ownership of an asset changes, or a team member moves roles and their access profile changes: reassign and re-document.
• Revocation / return — a team member leaves: confirm assets are returned and access is revoked, and record both.
• Disposal / decommissioning — a tool is retired, a service is terminated, or a data set is deleted: mark as decommissioned and retain the record for audit purposes; do not delete the row.

Stage 2 auditors approach A.5.9 as a traceability exercise. They are not just looking at whether a register exists. They are checking whether the register is complete, whether ownership is real, whether classification drives decisions, and whether the register is actively maintained or quietly abandoned after initial certification.

Mandatory checks:

• A documented, accessible IAR covering both primary information assets and the IT systems that process, store, or transmit them.
• A named individual owner for every asset, not a team, not a department, but a person.
• Classification labels applied consistently across every entry.
• Evidence that the register is actively reviewed, like dates, owner sign-offs, update history.
• Traceable evidence that offboarding triggers asset return and access revocation (A.5.11).

Control A.5.9 feeds directly into your risk assessment (Clause 6) and your Statement of Applicability. Every control you select in Annex A should trace back to an asset in your register. If it does not, you cannot justify why the control is in scope — and auditors will notice. For the broader ISMS structure A.5.9 sits within, see ISO 27001 Clauses 4–10: The First Steps in Setting Up Your ISMS. For how to define the scope that determines which assets are in scope in the first place, see ISO 27001 Clause 4: How to Perform a Context Analysis.