Why the assets in your ISMS are not a copy of your CMDB

Almost every organisation that starts building an ISMS reaches the same point. There is already a CMDB with thousands of configuration items, neatly maintained by the operations team, and the obvious question follows. Should we copy that list into the ISMS? The answer is no. Those who do end up, within a week, with a register nobody maintains and a classification column that stays empty. Understanding the difference between the two registers saves you months of work. For financial entities under DORA the picture is more nuanced, and we return to that separately further on.

One word, two meanings

In IT, the word “asset” carries two meanings that happen to share the same term.

In the service management world, that of ITIL and ISO/IEC 20000, a configuration item is everything you need to know to deliver and change a service: servers, virtual machines, network components, licences and interfaces. The register exists to control changes, incidents and capacity. Completeness and currency are its main quality requirements.

In the security world, that of ISO/IEC 27001, an asset is something that comes with an owner who can take decisions about it. Control 5.9 asks for an inventory of information and other associated assets, with an owner for each entry. That ownership requirement is not an administrative formality, because without an owner there is nobody who can accept the residual risk.

The two registers therefore answer different questions. Your CMDB answers the question of what you run and how it fits together. Your ISMS register answers the question of what you must protect, how strictly, and who decides about it. These are not two versions of the same list, but two lists at different levels of abstraction.

Researchers pointed this out early on. Oppenheim, Stenson and Wilson showed in their work on information as an asset that information behaves differently from a classic asset: it does not wear out, it can exist in several places at once, and it derives its value from the context in which it is used. An accounting or technical inventory logic is a poor fit for that.

The four layers

It helps to organise assets into four layers. Each layer has its own kind of owner and its own kind of question.

1. The business process, for example payroll, student enrolment or order handling. The owner is the process owner, who can say how long the process may stand still before real damage occurs.
2. The information or data set handled in that process, such as personnel files, exam results or client contracts. This is where the confidentiality, integrity and availability (CIA) rating applies, and the owner is the person responsible for that data.
3. The application or service that supports the process. It inherits its classification from the most sensitive information processed in it.
4. The underlying technology: servers, storage, network components and interfaces. This is the territory of your CMDB.

An ISMS works on layers 1 to 3. Your CMDB works on layer 4 and sometimes on layer 3, because that is where the two registers meet. Exactly at that interface you create the link, and nowhere else.

You rate CIA on information, not on hardware

A database server is not confidential. The data stored on it is. That sounds like wordplay, but it is the whole difference between a classification that works and a classification that stays on paper.

The rating of confidentiality, integrity and availability is not a label in its own right, but a switch. A classification only has meaning if something follows from it. Think of consequences such as these:

• Which baseline controls are mandatory and which additional controls come on top of them.
• Which recovery time and which maximum data loss apply, meaning the RTO and RPO from your continuity analysis.
• How strict access control, logging and retention periods must be.
• Whether a separate risk analysis or a DPIA is needed before processing may start.

If you rate at layer 4, you are rating hardware, and no meaningful business interest can be attached to hardware. A server only needs a protection level once you know which information sits on it.

The American government standard works exactly this way. FIPS 199 categorises along the same three properties, with the levels low, moderate and high, and applies the high water mark principle. The category of a system equals the highest rating of all information types the system processes. NIST SP 800-60 works this out in tables that map information types to categories. That is the same inheritance you see running from information to application in Kantyra.

That principle also has a downside you should know. Applying the high water mark mechanically pushes entire environments into the heaviest regime because one sensitive data set happens to run in them. That is precisely why NIST SP 800-53 leaves room for tailoring the control set, and why separating environments often turns out cheaper than lifting everything to the highest level. If one application drags your whole estate to the critical level, the question is not how to pay for that, but whether that application belongs there at all.

Watch out for the aggregation effect as well. Individual data items may each score low, while the collection as a whole becomes sensitive. A list of postcodes on its own is harmless, but the same list linked to absence records no longer is.

What research shows about classification that stalls

Information classification is one of the few subjects in information security that has been studied empirically in a serious way, notably in Swedish research on public sector organisations. The findings recur with striking consistency, and they explain why so many classification programmes strand.

In practice, organisations classify systems instead of information, because systems are tangible and sit in a list. With that, the link to the business interest disappears and a technical inventory is all that remains. The classification schemes are, moreover, often too fine-grained, with too many levels and too many dimensions, so the people who must apply them give up. The work then ends up being done by the security officer or the IT department instead of the owner, and precisely that undermines the purpose, because a classification is a statement about business interest and not about technology. Finally, classification is treated as a one-off exercise for the auditor, while processes and data flows change every year.

The common thread in those findings is that classification fails as soon as it is decoupled from the people who know the interest and from the controls that follow from it. That is also the most important design requirement for any ISMS register: every entry should have an owner with a name, and every rating should demonstrably change something about what needs to happen.

This also matches how governance is commonly arranged. The CISO is not the risk owner. The process or system owner holds the risk and accepts the residual risk, and the board is ultimately accountable. A classification filled in by the security department therefore records a judgement that department is not entitled to make.

Whether to link to the CMDB

The practical advice is to build no synchronisation, but do create a reference. There are three variants, increasing in cost and in maintenance burden.

In the simplest variant, you record the CI number from the CMDB as a plain field per application in your ISMS. An auditor can follow that reference, you need no technology for it, and you are done in an afternoon. For most organisations this is enough.

In the second variant, you do a one-off import of a subset. You export from the CMDB only the configuration items of the type application or business service, and use those as a starting list. After that you maintain both registers separately, because they change for different reasons.

The third variant is a periodic link, and it is only worthwhile if your CMDB is demonstrably current and each configuration item has a clear owner. In most organisations that is not the case, and then you mostly import pollution.

More important than the technology is the direction of the traffic, because it runs both ways. Downwards goes the classification. If an application scores high on availability, the servers beneath it must receive the corresponding backup, patch and monitoring regime, and that is the reason you create the link in the first place. Upwards go the technical facts: which components support this application, where they run and what their patch status is. The first direction is the valuable one, because your classification then drives operations instead of remaining a paper exercise.

These three variants suffice for organisations working from ISO/IEC 27001 or NIS2. If you fall under DORA, the first variant is too light, and we explain that in the next section.

Four frameworks, one subject

The layered logic holds up across the different frameworks, but the axis along which you classify differs per framework. That is exactly where things often go wrong, because organisations then build three registers side by side while the subject is the same.

The first three rows are about the same subject, only through a different legal lens. The fourth row is about something else.

NIS2 attaches to the service

NIS2 works at the level of the service. Whether you fall under the directive depends on your sector and on the service you deliver, not on your systems. The duty of care asks for appropriate and proportionate measures based on a risk assessment, and asset management and access policy are named explicitly among the measure categories of Article 21. The national laws transposing the directive add their own detail, so check the rules that apply in your country.

The word “proportionate” does the work here. Proportionality can only be substantiated if you know which business interest sits behind a system, and that is exactly what a CIA rating records. Without classification you have no defensible answer to the question of why you set up a second failover location for one system and not for another. The reporting duty works the same way, because the threshold depends on the consequences for your service delivery, and you assess those at process level.

The governance side reinforces the point about ownership. The management body must approve the measures and oversee their implementation, and can be held accountable for it. A classification the security department filled in by itself then records a judgement the board ought to carry.

DORA asks for both registers at once

DORA is the exception to the claim this article opens with, and it is worth getting precise.

Whoever reads Article 8 sees, in paragraphs 4 and 6, something that is functionally plain configuration management. You must identify all information assets and ICT assets, including those on remote sites, network resources and hardware, and you must map the configuration and the links and interdependencies between them, and keep those inventories up to date. That is considerably more concrete than ISO/IEC 27001, because control 5.9 says nothing about configurations or dependencies. Whoever concludes from this that DORA mainly prescribes a CMDB has a point.

Yet that is not what it is, and the regulation makes this clear itself in its definitions. DORA distinguishes the ICT asset, a software or hardware asset in the network and information systems, from the information asset, a collection of information worth protecting. That is exactly the separation between the layers described above, and the legislator anchored it in the definitions instead of lumping both together.

Paragraph 1, moreover, is not an inventory question. It says you must identify, classify and document the ICT-supported business functions, together with the roles and responsibilities, and with the information assets and ICT assets supporting those functions, each time in relation to the ICT risk. An average CMDB does not deliver that, because the following is missing from it:

• It contains at most a technical administrator, not an owner who can accept the residual risk.
• The link from a component to the business function it supports is missing, and with it the reason why that component matters.
• The judgement on criticality does not follow from it, because that judgement follows from the business function and not from the technology.
• There is no periodic review in which someone confirms the classification still holds, while DORA asks for updates and for a risk assessment at every major change.
• Legacy systems and the dependence on third-party ICT service providers get no separate attention, while Article 8 devotes separate paragraphs to them.

The sharp formulation is therefore that DORA asks neither for a CMDB nor for a classic asset register, but for the combination of both with a demonstrable link between them. A CMDB alone is too technical and misses the function, the owner and the criticality. A classic register alone is too abstract and misses the configuration and the dependencies. The regulatory technical standards accompanying the regulation work this out further with requirements for what the inventory must contain per asset.

Practically, this means for financial entities that a single reference field with the CI number does not suffice. You need a maintained link in which criticality inherits downwards to the technical components and in which the dependencies remain visible. Count on a third register as well, one that has nothing to do with the first two: the register of information on the contractual arrangements with ICT service providers. It comes with a prescribed data model and fixed templates and goes to the supervisor, so whoever tries to squeeze it into the same table as their assets will get stuck.

One register, several attributes

The practical outcome is that you keep one register at process and information level, with one attribute per framework on the same line. A process thus receives a CIA rating, next to it an attribute stating whether it counts as an essential or important service under NIS2, and for financial entities an attribute stating whether it is a critical or important function.

Do not derive these attributes from one another automatically. A high confidentiality score does not make something a critical function under DORA, and a critical function need not score high on confidentiality. They are legal qualifications with their own criteria, and software that copies them from one another automatically produces a wrong picture that merely looks tidy.

How large should the register be

A workable ISMS register counts between fifty and a hundred assets in most organisations. If you are at thousands of lines, you have copied your CMDB.

The test per line is simple. Is there a person with a name who can accept the residual risk for this asset? And does the classification you attach to it change anything about the controls? If you answer either question with no, the line belongs in your CMDB and not in your ISMS.

Under DORA that rule of thumb keeps applying to the upper layers, but the full inventory of ICT assets comes on top, and that one is by definition larger. The difference is that you keep the two separate and connect them, instead of blending them into one list.

In seven steps

1. Start with the business processes and not with the systems, and limit the number to the processes that genuinely matter.
2. Name the owner for each process, and record that name before you continue.
3. Map, for each process, the information handled in it, and rate it on confidentiality, integrity and availability.
4. Link the applications to that information and let the classification inherit from the most sensitive data set.
5. Record, for each application, the reference to the configuration item in your CMDB, without copying the technical data. If you fall under DORA, create a maintained link to the underlying components and their dependencies.
6. Translate the classification into concrete requirements: controls, recovery times and retention periods, and pass those on to operations.
7. Review the rating yearly and at every significant change, and have the owner confirm that review.

For part of the organisations this order is, moreover, not a free choice. Both NIS2 and DORA require your measures to be proportionate to the risk, and you can only substantiate that proportion if you know which business interest sits behind a system. A technical inventory alone does not deliver that substantiation, and a classification without a link to the technology delivers no demonstrable implementation. You need both, but as two registers that you connect.

Sources

Normative sources, to consult directly:

• ISO/IEC 27001:2022, controls 5.9 (inventory of information and other associated assets), 5.10, 5.12 (classification of information) and 5.13 (labelling of information), with the guidance in ISO/IEC 27002:2022.
• Directive (EU) 2022/2555 (NIS2), in particular the cybersecurity risk-management measures in Article 21, the governance requirements in Article 20 and the reporting obligations in Article 23. Check the national law transposing the directive in your country before relying on it.
• Regulation (EU) 2022/2554 (DORA), Article 3 for the definitions of the ICT asset and the information asset, and Article 8 for identification, classification and documentation of business functions and assets. Take the definitions from Article 3 over literally when writing internal policy on this, and involve the regulatory technical standards accompanying the regulation for the inventory requirements.
• ISO/IEC 20000-1 and the ITIL 4 practice for service configuration management, for the meaning of the configuration item and the CMDB.
• FIPS 199 (2004) for categorisation along confidentiality, integrity and availability and for the high water mark principle, with the elaboration in NIST SP 800-60.
• NIST SP 800-53 rev. 5, control CM-8 on the inventory of system components, which shows clearly that the technical inventory is something other than the categorisation.
• NIST Cybersecurity Framework 2.0, category ID.AM, in which prioritising assets based on classification and criticality is included explicitly.
• CIS Controls v8, controls 1 and 2 for the inventory of devices and software, and control 3.7 for the data classification scheme.

Research literature:

• Oppenheim, Stenson and Wilson, “The attributes of information as an asset” (New Library World, 2001) and the three-part series “Studies on Information as an Asset” (Journal of Information Science, 2003–2004), on why information behaves differently from a classic asset.
• Erik Bergström and colleagues (University of Skövde and Jönköping University) on information classification in the Swedish public sector, among others “Developing an information classification method” (Information & Computer Security, 2021) and “An information classification model for public sector organizations in Sweden” (Information & Computer Security, 2022), with findings on overly complex schemes, classification by the wrong official and the missing link to controls.