IT Asset Management for the ISMS: Inventory, Criticality, and Classification

Why the ISMS needs an asset inventory

Every information security management system revolves around a simple question at its core: what do we need to protect? The asset inventory provides the answer. Without a complete overview of your organization's information-processing assets, every risk analysis is patchwork and every protective measure a shot in the dark.

ISO 27001 formulates this requirement clearly in Annex A.5.9: information and other associated assets must be identified, and an inventory of these assets must be created and maintained. That sounds like administrative overhead, but it is the foundation on which everything else is built. Your risk assessment, your protection needs assessment, your access control concept, and ultimately your ability to demonstrate compliance to auditors and authorities.

NIS2 further strengthens this requirement. Article 21 requires affected organizations to implement risk management covering all relevant systems and processes. Without knowing which assets exist, you can neither assess risks nor demonstrate that you have implemented the legally required minimum measures.

And yet practice shows: the asset inventory is one of the areas where SMEs most frequently have gaps. Often there is an IT inventory list for hardware, perhaps license management for software. But a comprehensive register mapping all information-processing assets with their dependencies, owners, and protection needs? That is missing in most organizations.

What is an asset, exactly?

Before you start building an inventory, you need to clarify what you mean by an asset. In the context of an ISMS, the definition is deliberately broad. An asset is anything that has value for the organization and whose compromise (regarding confidentiality, integrity, or availability) could cause damage.

This goes far beyond the traditional IT inventory list. A physical server is an asset, obviously. But the database running on that server is a separate asset. The application that uses this database is another one. And the information processed in this application is yet another separate asset with its own protection needs.

Asset categories at a glance

A division into six main categories has proven effective for a structured inventory:

Hardware assets include all physical devices: servers, workstations, laptops, smartphones, tablets, network components (switches, routers, firewalls, access points), printers, storage systems (NAS, SAN), UPS units, and physical security components such as access control systems.

Software assets cover the entire spectrum of deployed applications: operating systems, business applications (ERP, CRM, accounting), database management systems, development tools, security software (antivirus, EDR, SIEM), backup software, and middleware.

Cloud services and SaaS are often the most poorly inventoried assets in modern organizations. This includes IaaS resources (virtual machines, storage buckets, networks in AWS, Azure, or GCP), PaaS services (managed databases, container platforms), SaaS applications (Microsoft 365, Google Workspace, Salesforce, Slack, Zoom), and cloud-based development platforms.

Information assets are the actual values to be protected: customer data, personnel data, financial data, trade secrets, technical documentation, contracts, email communications, and backup data.

Network assets form the communication infrastructure: network segments, VPN connections, DNS services, proxy servers, load balancers, and external connections (internet lines, site-to-site links).

Service assets are the business processes and services built on top of the technical assets: email service, website, online shop, remote access, telephony/VoIP, print services, and monitoring systems.

Where does the inventory end?

A legitimate question is how granular the inventory should be. Must you inventory every single laptop, or is a category "employee notebooks" sufficient? The answer depends on the risk profile and the organization's size.

For a mid-market company with 50 to 250 employees, the following rule of thumb has proven effective: individual recording for everything that warrants its own risk assessment. Typically, these are servers, central network components, business applications, and cloud services. Similar end-user devices (laptops, smartphones) can be grouped together as long as they have the same protection needs and are subject to the same policies.

Asset attributes: what to document for each asset

An asset in the inventory is more than a name on a list. To make it useful for risk assessment and day-to-day ISMS management, you need a defined set of attributes.

Mandatory attributes

Recommended additional attributes

Depending on the maturity of your ISMS, further attributes significantly increase the inventory's value:

Technical attributes: IP address or hostname, operating system and version, main installed applications, license information, lifecycle status (end-of-life date).

Organizational attributes: Department or business unit, contract information (maintenance contract, SLA), procurement date and cost, depreciation period.

Security attributes: CIA classification (more on this shortly), protection needs category, NIS2 relevance (yes/no), dependencies (which assets does it depend on, which depend on it), applicable policies.

Criticality assessment: how important is the asset?

Not every asset is equally important. The printer in the break room has a different relevance than the database server holding your ERP data. The criticality assessment places each asset on a scale and helps you concentrate resources and protective measures where they deliver the greatest value.

Assessment criteria

Four dimensions have been established for criticality assessment:

Business impact of failure: How severely would the organization be affected if this asset were unavailable? An ERP system failure may paralyze the entire order processing. The failure of a single desktop printer is barely noticeable.

Number of affected users or processes: An asset used by all employees (email system, Active Directory) is more critical than a specialized tool used by only one department.

Recoverability: How quickly and at what cost can the asset be restored? A cloud service can often be re-provisioned within minutes. A physical machine with special components may take weeks.

Regulatory relevance: Is the asset subject to specific legal requirements (GDPR, NIS2, industry-specific regulations)? A system processing personal data has elevated criticality simply due to GDPR.

Criticality levels

A three-tier scale is sufficient for most mid-market companies:

Criticality high: A failure or compromise has immediate, severe impacts on business operations. Financial damages in the six-figure range or higher are possible. Regulatory consequences are likely. Examples: ERP system, production database, Active Directory, firewall.

Criticality medium: A failure is noticeable and impairs operations, but the core business can continue in the short term. Workarounds are available. Examples: email system, CRM, departmental servers, VPN gateway.

Criticality low: A failure is annoying but has no significant impact on business operations. Examples: print server, presentation technology, individual workstations, test systems.

This classification is not static. A test system becomes critical when it suddenly serves as a fallback for the production system. The assessment must therefore be reviewed regularly — at least annually or when significant changes occur.

CIA classification: confidentiality, integrity, and availability

The criticality assessment tells you how important an asset is overall. The CIA classification goes a step further and differentiates by the three fundamental protection goals of information security.

Confidentiality

Confidentiality means that information is only accessible to authorized persons or systems. The question is: what damage would it cause if unauthorized parties gained access to this asset or the information stored on it?

Normal: The information is internally available and not particularly sensitive. Unauthorized access would be undesirable but would not have severe consequences. Example: general internal documentation, publicly available marketing materials.

High: The information is confidential. Unauthorized access could cause financial damage, competitive disadvantage, or reputational harm. Example: customer data, quote calculations, contracts, personnel data.

Very high: The information is strictly confidential. Unauthorized access could cause existentially threatening damage or violate legal requirements. Example: trade secrets, health data, credentials for critical systems, cryptographic keys.

Integrity

Integrity ensures that information is correct and unaltered. The question is: what damage would it cause if data on this asset were undetectably modified or falsified?

Normal: Falsified data would be annoying but easily detectable and correctable. Example: intranet content, calendars.

High: Falsified data could lead to wrong decisions, financial losses, or flawed business processes. Correction is costly. Example: accounting data, order data, production data.

Very high: Falsified data could cause personal harm, massive financial losses, or existentially threatening consequences. Example: medical data, production control data, financial transactions, audit logs.

Availability

Availability means that systems and data are accessible when needed. The question is: what damage would it cause if this asset were unavailable for a certain period?

Normal: An outage of up to 24 hours is tolerable. The impact on business operations is minor. Example: archive systems, wikis, test systems.

High: An outage of more than four hours causes noticeable impairments. Customers or internal processes are affected. Example: email system, CRM, web shop, accounting software.

Very high: Even an outage of less than one hour causes significant damage. Production standstill, revenue loss, or endangerment of persons is possible. Example: ERP system, production control, emergency call systems, online banking platform.

CIA classification in practice

The three protection goals are assessed independently because an asset can have different protection needs for each goal and because different protection goals require different measures.

Take the example of a company's public website: confidentiality is low (the content is public anyway), integrity is high (defacement of the website damages reputation), and availability depends on whether the website only provides information or actually generates revenue. For a pure image website, availability may be normal; for an online shop, it is very high.

The CIA classification feeds directly into the risk analysis. An asset with a "very high" protection need for availability requires different measures (redundancy, failover, low RTO) than an asset with a "normal" protection need. And an asset with high confidentiality requires different controls (encryption, access restrictions, logging) than one whose data is public anyway.

Asset owner: who is responsible?

ISO 27001 explicitly requires in Annex A.5.9 that an owner be designated for each asset. The asset owner is not necessarily the person who administers the asset daily. It is the person or role that bears responsibility for the entire lifecycle of the asset.

Asset owner responsibilities

The asset owner is responsible for the following areas:

They ensure that the asset is correctly inventoried and classified. They regularly verify that the classification is still current. They define (or approve) access permissions for the asset. They ensure that appropriate protective measures are implemented. And they are informed and involved when security incidents affect the asset.

Who becomes the asset owner?

The assignment follows business responsibility, not technical administration:

A common mistake is making the IT department the owner of all technical assets. This does not work because while IT is responsible for operations, business responsibility for the processed data lies with the business departments. IT management can and should be the asset owner for pure infrastructure (network, servers, base systems). For business applications and the information processed in them, the owner should come from the business side.

Flagging NIS2-critical assets

If your organization falls under NIS2, you must map an additional dimension in your asset inventory: NIS2 relevance. Not every asset is relevant for NIS2 compliance, but you must be able to demonstrate which ones are and how you protect them.

Which assets are NIS2-relevant?

All assets that are directly or indirectly involved in delivering the regulated services are NIS2-relevant. If your company is an IT service provider under NIS2, then all systems needed for delivering the IT services are NIS2-relevant. This includes production systems but also management systems (ticketing, monitoring), security infrastructure (firewall, SIEM), and communication systems (email, VPN).

For flagging in the asset inventory, a simple attribute "NIS2-relevant: yes/no" along with a brief justification is recommended. During an audit or BSI review, you need to explain why an asset was classified as relevant or not relevant.

NIS2 minimum measures and assets

The ten minimum measures from NIS2 Article 21 can be directly mapped to asset categories:

This mapping helps you target the right assets during measure planning and identify gaps.

Dependencies between assets

No asset exists in isolation. The ERP server needs the database, the database needs the storage system, the storage system needs the network, the network needs the firewall, and the firewall needs power and internet connectivity. If you do not know these chains, you systematically underestimate the impact of failures and security incidents.

Dependency types

Vertical dependencies describe the layers on which an asset is built. A business application depends on middleware, which depends on the operating system, which depends on hardware, which depends on power supply and network infrastructure. A problem at a lower layer propagates upward.

Horizontal dependencies exist between assets at the same level. The ERP system communicates with the CRM system, the CRM sends data to the email system, the email system uses the DNS server. If one link in this chain fails, the others are impaired.

External dependencies concern services and systems outside your control: internet connectivity, DNS provider, cloud services (AWS, Azure), SaaS applications, external APIs. These dependencies are often underestimated because they are invisible during normal operations.

Documenting dependencies

For each asset, you should maintain two lists:

Depends on: Which other assets must be functioning for this asset to do its job?

Required by: Which other assets depend on this asset?

This information is invaluable when you need to assess the impact of a failure or security incident. It shows you which asset is the central node whose failure triggers a cascade. And it helps you correctly account for the inheritance effect in the protection needs assessment: a system on which many others depend inherits the highest protection need of its dependent systems. This inheritance principle is also central to the Business Impact Analysis.

Practical example: asset inventory for a 100-employee company

To make this tangible, here is a typical asset inventory for a mid-market company with approximately 100 employees. The company is an IT service provider, falls under NIS2, has two locations, and uses a hybrid infrastructure of on-premise systems and cloud services.

Hardware assets (typically 15–25 entries)

Software and service assets (typically 20–40 entries)

Information assets (typically 10–15 entries)

This example shows: even for a company with 100 employees, you quickly reach 50 to 80 relevant assets. That sounds like a lot but is manageable if you use an appropriate tool and do not maintain the inventory in a monolithic Excel spreadsheet.

Building the asset inventory: step by step

If you are starting from scratch, a phased approach is recommended that leads to a reliable result within four to six weeks.

Phase 1: Stocktaking (Week 1–2)

Start with what you already have. Most companies have an IT inventory list, license management, or at least network documentation somewhere. Collect these sources and consolidate them into a uniform format.

In parallel, conduct interviews with department heads. Ask specifically about the systems and applications that are business-critical for the respective department. You will be surprised at the shadow IT that surfaces: SaaS services that individual teams procured without IT's knowledge, local databases on departmental servers, Excel-based workflows with business-critical data.

Phase 2: Structuring and classification (Week 2–3)

Bring the collected assets into the defined schema. Assign asset IDs, allocate categories and types, and designate asset owners. In this step, you also perform the initial CIA classification. You need the asset owners for this, as they best understand the business value of the information.

Important: the CIA classification should not be performed by the IT department alone. IT can contribute the technical perspective (availability requirements, recovery times), but assessing confidentiality and integrity requires the expertise of the respective department.

Phase 3: Dependencies and validation (Week 3–4)

Document the dependencies between assets. Start with the highly critical assets and work your way down. Check the inheritance of protection needs: if a low-classified asset forms the foundation for a highly critical asset, the protection need must be adjusted.

Perform a quality check: are there assets without an owner? Are there gaps in the classification? Are there obvious dependencies that are not documented?

Phase 4: Review and approval (Week 4–5)

Present the asset inventory to management, ideally as part of the management review. This is not a formality but an essential step: executive management must know the inventory and confirm the classifications, because priorities for protective measures and investments are derived from it.

After approval, the inventory becomes a living document. Define a review cycle (at least annually, preferably semi-annually) and a process for changes (new assets, decommissioned assets, changes in classification).

Common mistakes and how to avoid them

From consulting practice, we know some pitfalls that occur repeatedly:

Mistake 1: Only inventorying hardware. The inventory lists servers, switches, and laptops but no cloud services, no SaaS applications, and no information assets. This means exactly the assets that make up the largest attack surface in modern organizations are missing.

Mistake 2: IT does everything alone. If only the IT department maintains the inventory, the business perspective is missing. Asset owners from business departments must be involved; otherwise, the classifications are inaccurate.

Mistake 3: Create once, never update. An asset inventory that was correct at the time of creation but has not been updated for two years is dangerous. It conveys a false sense of security and leads to wrong decisions in the risk analysis.

Mistake 4: Too granular or too coarse. 500 entries for 100 employees are just as problematic as 15 entries. Overly granular inventories are unmaintainable; overly coarse inventories lack insight. Find the right level for your organization.

Mistake 5: Ignoring dependencies. Without dependency documentation, you do not realize that the failure of a single DNS server paralyzes your entire network. The cascade effect is decisive in risk analysis.

From inventory to risk assessment

The asset inventory is not an end in itself. Its true value unfolds only in combination with the risk assessment. Each asset with its CIA classification becomes the basis for the question: what threats can affect this asset, how likely is that, and how great would the damage be?

The formula is simple in principle: you take an asset, identify the relevant threats (ransomware, hardware failure, misconfiguration, unauthorized access), assess the probability of occurrence and the magnitude of damage, and derive the risk value. The CIA classification determines the damage magnitude: an asset with a "very high" protection need for availability leads to higher damage in an availability incident than an asset with a "normal" protection need.

Without a clean asset inventory with reliable classification, this risk assessment is not possible. You would either overestimate or underestimate risks, implement measures in the wrong places, and be unable to explain in an audit why you prioritized certain areas and neglected others.

Tools and formats

Various tools are available for the asset inventory, and the choice depends on the maturity of your ISMS and the organization's size.

Excel or Google Sheets are the lowest-barrier entry point. For the beginning, this works, but as soon as the inventory exceeds 100 assets, multiple people work on it simultaneously, or you need links to the risk assessment, you hit limitations.

Dedicated ISMS tools like ISMS Lite offer asset management as an integrated function. The advantage: the inventory is directly linked to the risk assessment, measure tracking, and the audit trail. Changes to an asset automatically propagate into the risk analysis.

CMDB systems (Configuration Management Database) like i-doit or GLPI are powerful but often oversized for SMEs and not tailored to ISMS requirements. They work well as a data source feeding into an ISMS tool.

Regardless of the tool: the asset inventory must be accessible to auditors and traceable. It must show who made which changes when (change history) and when the last review took place.

Your next step

The asset inventory is the foundation of your ISMS. If you do not have one yet, start now. If you have one, check it for completeness: are cloud services included? Does every asset have an owner? Are the CIA classifications current? Are dependencies documented?

Further reading

• Protection Needs Assessment: Evaluating Confidentiality, Integrity, and Availability
• Risikobewertung im ISMS: Methodik, Matrix und Praxisbeispiel
• Business Impact Analyse (BIA) durchführen: Geschäftsprozesse bewerten
• Geltungsbereich (Scope) definieren: Was gehört ins ISMS und was nicht?
• ISMS aufbauen: Der komplette Leitfaden für Unternehmen mit 50 bis 500 Mitarbeitern

In the next article, we take it a step further and show you how to derive a complete protection needs assessment from the CIA classification using the BSI methodology. Because the classification in the asset inventory is the starting point, but the systematic protection needs assessment requires a few additional steps: the examination of damage scenarios, the inheritance of protection needs, and the documentation your auditor wants to see.