Every security framework starts with the same requirement: know what you have. ISO 27001 asks for an inventory of information and associated assets with owners. NIS2 expects organisations to know which network and information systems support their essential services. Risk analysis, incident response, supplier management and security testing all assume that the organisation knows what it is protecting.
Most organisations do have some kind of asset list. The problem is that it often does not answer the questions that security decisions depend on.
A familiar situation
An organisation's IT department maintains a configuration database with servers, laptops, network devices and software licences. It is fairly complete and updated automatically. When the organisation prepares for ISO 27001, the auditor asks a simple question: which assets support the client portal, and who owns the risk if it becomes unavailable?
Nobody can answer quickly. The portal runs on a SaaS platform that does not appear in the configuration database because IT does not manage it. It uses an authentication service from another supplier. The client data it shows comes from an internal database, which is in the list, but is labelled only with a server name. The business owner of the portal is in the marketing department and has never been asked about security.
The organisation knew its technology. It did not know how its services were put together.
What an information asset really is
The word "asset" is often understood as a device or a piece of software. For security purposes, that is too narrow. The things that need protection are, in order of importance:
- Information: client records, research data, financial data, personnel files, intellectual property, credentials.
- Business processes and services: what the organisation does with that information, such as invoicing, admissions, payroll or a client portal.
- Supporting assets: applications, databases, servers, cloud services, networks, devices and locations that the processes rely on.
- Suppliers and people: the parties and roles that operate, maintain or have access to the above.
The value lies in the first two. Supporting assets matter because of what depends on them. A server is important when it holds client data or runs a critical process, not in itself.
Asset owner versus technical administrator
One of the most common sources of confusion is the difference between the person who owns an asset and the person who manages it.
The asset owner is the person in the business who is accountable for the information or service. They decide who may access it, how important it is and which risks are acceptable. For the client portal, that might be the head of client services.
The technical administrator is the person or team that operates the system: IT, a developer, or a supplier. They implement controls and keep things running, but they should not have to decide alone how much risk the business accepts.
When the asset owner is not named, or when IT is named as owner of everything, risk decisions end up with people who do not have the business context or the mandate to make them. This is one of the main reasons why security improvements stall.
Relationships and dependencies
A list of assets becomes useful when it shows how they relate. For each important service, the organisation should be able to say:
- which information the service uses or produces;
- which applications and infrastructure it runs on;
- which suppliers are involved, including cloud services that IT does not manage directly;
- which other services depend on it, or on which it depends.
This does not require a complex modelling tool. A simple table per critical service, or a diagram on one page, already reveals single points of failure, hidden supplier dependencies and systems that are more important than anyone realised. It also helps to scope security tests around the services that matter, rather than around a list of IP addresses.
Classification and business impact
Not every asset deserves the same protection. Classification makes the difference explicit. A common approach is to rate each information asset or service for confidentiality, integrity and availability on a small scale, for example low, medium and high.
The scale only works if the levels are described in business terms. "High availability" could mean "the service may not be unavailable for more than four hours during working days, because client appointments cannot be scheduled". "High confidentiality" could mean "disclosure would expose personal data of clients and require notification to the regulator". These descriptions let the asset owner make the rating, rather than the security team guessing.
Classification then feeds back to supporting assets. A database that holds information classified as high for confidentiality inherits that requirement, and so does the supplier hosting it.
The link with risk analysis
Asset insight and risk analysis are two halves of the same activity. A risk is always a risk to something: the confidentiality of client data, the availability of the payroll process, the integrity of research results. Without a clear view of assets and their value, a risk register becomes a list of generic threats with no clear owner and no clear impact.
With asset insight, risk analysis becomes more focused. Start from the most important services and information, ask what could go wrong for each, and use the dependency picture to see where the weak points are. This is also where threat intelligence becomes practical: knowing which actors target your type of information or service tells you which scenarios to analyse first.
A minimal dataset for a usable register
An asset register does not need dozens of fields. For most organisations, the following is enough to support risk management and audits:
- name and short description;
- type (information, service, application, infrastructure, supplier);
- asset owner (a named role in the business);
- technical administrator or supplier;
- classification for confidentiality, integrity and availability;
- the services or processes it supports;
- the most important dependencies;
- location or hosting, including country for personal data;
- date of the last review.
Start with information and services, then link the supporting assets. Technical inventories from IT tools can be connected later; they are useful for completeness but should not be the starting point.
Common mistakes
- Starting from technology. Building the register from network scans produces a long list of devices without business meaning.
- Naming IT as owner of everything. This moves risk decisions away from the business.
- Leaving out cloud services and suppliers. SaaS applications are often where the most sensitive information lives, and they rarely appear in technical inventories.
- Trying to be complete before being useful. A register that covers the ten most critical services well is more valuable than a register that lists everything superficially.
- No review moment. Without an agreed review, the register is out of date within a year.
Keeping the register alive
The hardest part of asset management is not creating the register but keeping it current. Three arrangements help. First, connect updates to existing processes: when a new application is purchased, a supplier is contracted or a service changes, updating the register is a step in that process, not a separate task. Second, give asset owners a short review once a year, where they confirm the classification, the dependencies and the supplier information for their own services. Third, use the register. When it is consulted for incident response, test scoping and supplier reviews, errors are noticed and corrected.
Beyond security
Good asset insight has benefits outside security. It shows duplicated applications and licences that nobody uses, makes it easier to plan replacements and migrations, and helps to estimate the impact of changes. Organisations that keep their register current often find that IT and the business start using it for their own decisions, which is the best guarantee that it stays up to date.
A 30-day approach
Week 1. Identify the five to ten business services that matter most. Name an owner in the business for each.
Week 2. With each owner, list the information the service uses and classify it for confidentiality, integrity and availability, using descriptions in business terms.
Week 3. With IT and procurement, map the applications, infrastructure and suppliers each service depends on. Note any dependency that nobody can explain.
Week 4. Record the results in a simple register with the minimal dataset above. Identify the three most significant gaps, such as an unassessed critical supplier or a service without an owner, and agree an action for each. Set a review date.
After thirty days, the organisation will not have a complete inventory. It will have a clear picture of what matters most, who owns it and where the main risks are. That is a better basis for security decisions than a long list of devices.
Conclusion
Asset insight is not about counting hardware. It is about knowing which information and services the organisation depends on, how they are built, who is responsible for them and what would happen if they failed. With that picture, risk analysis, supplier management, testing and compliance all become more focused and less of a paperwork exercise.
Building an asset register that supports decisions is part of how FLODISQ sets up a working ISMS within Security Governance. When the dependency picture shows which suppliers carry your most important services, Supply Chain Security is the logical next step.