C5 domain AM: building an asset register with classification

This page covers the AM (asset management) domain of C5:2026, section 5.4 of the catalogue. How criteria and subcriteria are structured in general is explained on the page C5 criteria catalogue.

What is the AM domain about?

AM governs how the cloud service provider records and protects its assets. The catalogue states as its objective to identify the organisation’s own assets and to ensure an appropriate level of protection throughout their lifecycle (section 5.4). According to the supplementary information on AM-01, assets are the objects in the provider’s area of responsibility that are required for the information security of the service, for example firewalls, load balancers, web servers, application and database servers. They consist of hardware objects, which expressly include virtual infrastructure resources, and software objects such as containers, operating systems, databases, microservices and application programming interfaces.

The domain comprises twelve criteria, AM-01 to AM-12, with 26 basic subcriteria, 2 sharpening and 9 complementing additional subcriteria. According to the change history, six criteria are new: AM-01, AM-03, AM-04, AM-10, AM-11 and AM-12. The asset inventory is also the basis for other domains, for example for the risk assessment (AM-02.03B refers to OIS-07), the network topology (COS-07.03B) and container management (OPS-34.02B refers to AM-02, AM-03 and AM-09).

A note for bilingual teams: in the English version 1.0.1, the complementing subcriterion on keeping the inventory up to date is AM-01.02AC, in the German version 1.1.0 it is AM-02.01AC. The content is the same.

Starting point: inventory in a console and a spreadsheet

Fictitious example, not a client. A provider runs a platform through which building authorities and architecture firms exchange building applications, plans and approvals. Around 45 employees; the service runs as SaaS on the infrastructure of a large cloud provider: a managed Kubernetes cluster with microservices, a managed database, an object storage for plans and documents. Administrators sign in with FIDO2 security keys.

Before the project, the situation looks like this:

• The cloud resources can be seen in the platform’s console, laptops and security keys are listed in an IT spreadsheet. There is no common inventory.
• Which resource contains which data and who is responsible for it is recorded nowhere; some test resources have no recognisable purpose.
• The software list is limited to the provider’s own microservices. Which libraries, images and database version run underneath is known only to the operations team.
• Changes to the spreadsheet are overwritten, without history.
• A security key of an administrator who has left has not been returned for weeks.

Who is responsible for what: provider, platform, customer?

For a SaaS service on third-party infrastructure, AM is split along the boundary between virtual and physical resources. Our classification for the example:

How the data centres themselves are secured belongs to the PS domain. Whether individual hardware criteria are applicable to your service and how you include subservice organisations is defined with the scope and justified in the system description. You may not exclude a criterion there because your controls are missing.

What does a classification scheme under AM-09 look like?

AM-09 requires assets to be classified by the protection needs of the data they process, store or transmit. The protection need is determined by the people responsible for the assets according to a uniform, documented scheme (AM-09.03B). The scheme provides levels of protection for confidentiality, integrity, availability and authenticity, aligned with the recovery objectives in the business continuity and disaster recovery plans (AM-09.04B). Our scheme for the example:

The target values in the availability column are example values that must come from the provider’s own business continuity and disaster recovery plans; how to set them is shown in the BCM domain. You review the levels at least annually and in case of significant changes to the service (AM-09.02B). If a provider does not classify its assets individually, according to the supplementary information on AM-09 all assets may be treated as requiring the highest level of protection. For small services this is a possible route, but in our assessment a demanding one, because the strictest measures then apply everywhere.

What does an audit-ready asset register look like?

AM-03.01B and AM-04.01B define what an entry must achieve: identify the asset, provide visibility into its lifecycle or dependencies and enable the provider to control it and perform a risk assessment. The supplementary information lists possible fields for this, such as name, function, model, location, owner and information security requirements, for software the version and the parent resource. An asset owner is the individual or role responsible for managing and protecting the asset, not the legal owner. The catalogue speaks of the asset inventory; the asset register is the work product with which you maintain it. An excerpt from our register for the example (protection needs as C/I/A/A in the order confidentiality, integrity, availability, authenticity; the first A stands for availability, the second for authenticity):

Three points make the register audit-ready. First, recording: performed automatically and/or by the people responsible, so that the inventory is complete, accurate, valid and consistent (AM-02.02B). Second, the change log: changes to the recorded information are logged (AM-02.04B); a spreadsheet that can be overwritten is not enough for this. Third, the link to access rights: AM-02.05B requires lists of the users with access to a resource and their rights; these may come from the identity service, as described on the page IAM. Containers that you operate yourself are inventoried with their lifecycle; the details are in the OPS domain. The software list for third-party components (SBOM) belongs to DEV.

Example control description for AM-02

A register is only as good as its reconciliation with reality. Our example control for the provider above (own wording, not catalogue text):

Automated monitoring of the inventory process corresponds to the complementing subcriterion AM-01.02AC (AM-02.01AC in the German version). Whether you include it is your decision; as a way of working we recommend the reconciliation even without including it, because it is what makes the basic subcriteria verifiable in the first place.

What evidence the auditor wants to see

For AM, the register and its history are the central evidence, together with procedures and records for the lifecycle steps. Examples from our scenario:

An evidence register maps each subcriterion to its evidence; how to maintain it is shown on the page Evidence and documentation.

Possible gaps: cause, effect, remedy

The following gaps follow from the wording of the criteria and the scenario above. If a single subcriterion is not met, the criterion counts as not met, and the auditor reports the deviation (sections 3.4.12 and 3.4.13).

All criteria of the AM domain

Titles as in the English version 1.0.1, number of subcriteria counted per section 5 of the English version (B = basic, AS = sharpening, AC = complementing). In the German version 1.1.0, AM-01 has one and AM-02 one complementing subcriterion (AM-02.01AC there corresponds to AM-01.02AC here). The column “What it covers” is our own short description, not catalogue text; the wording of the criteria in the catalogue is binding.

Among the additional criteria, AM-07.01AS (decommissioning also for development, test and staging environments), AM-04.01AC (information on how long a software asset will receive security updates) and AM-09.03AC and AM-09.04AC (logging and monitoring take the protection needs of the assets into account) are particularly tangible for SaaS providers.

Relationship to ISO/IEC 27001:2022 Annex A

The following mapping is our own, unofficial classification by topic. The BSI has not yet published a cross-reference for C5:2026. The catalogue refers to the BSI website for it (section 3.3). So far the table there covers C5:2020 only, and the BSI says the table for C5:2026 is “scheduled for publication in the near future” (as of 6 November 2026). According to the catalogue, even an official table only shows thematic proximity, not fulfilment of the criteria (section 3.3). The short labels are ours, not titles from the standard. What you can reuse overall from a certified ISMS is shown on the page C5 and ISO 27001.