Does your company know which software it depends on? A new European guide explains why it matters

A company will usually know how many computers it has, who its main suppliers are and which bills it needs to pay each month. Identifying every application that enables people to work, understanding where those applications store information or knowing who is responsible for each one can be harder, especially when tools have been adopted gradually over the years as new needs arose.

Invoicing software, email, a customer management platform, a booking system or an application used to share documents may work so quietly in everyday business that we rarely think about what lies behind them. That ease of use is precisely what makes technology useful, but it can also make it harder to understand the dependencies that develop between services.

It was against this background that, on 22 October 2026, the European Union Agency for Cybersecurity (ENISA) published technical guidance on a concept known as a Software Bill of Materials, usually shortened to SBOM. The document is aimed primarily at organisations seeking to understand and manage the components included in their software products more effectively, with particular attention to micro, small and medium-sized enterprises.

The term is technical, but the underlying idea is fairly simple: to manage a product’s security better, it helps to know what it is made of.

What exactly is an SBOM?

When we use an application, we see the features it offers, not the many components that may have been combined to build it. Just as a piece of equipment contains parts made by different manufacturers, a computer program can include libraries, modules and other pieces of software developed by different organisations.

An SBOM is a structured inventory of those components and the relationships between them. It is often compared to an ingredients list, although the comparison is not perfect: in a computer program, different parts may depend on one another, receive updates at different times and carry risks that are not immediately visible to the person using the product.

Imagine a security flaw is discovered in a component used by several applications. For those developing or maintaining these products, knowing the software’s composition can help them identify more quickly which products may be affected and which fixes need to be assessed. Without that information, the investigation can take longer, even when a solution to the problem already exists.

ENISA’s guidance is intended to support this work, explaining how to organise information, manage its lifecycle and reduce risks associated with the component inventories themselves. It is not, however, a new requirement for every small business to start producing technical documents about each program it uses.

And what does this mean for a company that does not develop software?

For an accountancy firm, a restaurant or a small service business, the starting point will generally be different. Rather than identifying the internal components of each application, it makes more sense to begin by understanding which tools support the business, which companies supply them and who is responsible for their maintenance.

Consider a business that relies on one application to issue invoices and another to track orders. As long as both are working, there may be no apparent reason to review that arrangement. But if one platform becomes unavailable, undergoes an important change or needs an urgent update, it becomes relevant to know who administers the service, where the data is held and what alternatives are available to keep working.

This information is also useful when an employee leaves, when a supplier changes or when the company discovers it has several subscriptions to tools that perform similar functions. The inventory is therefore more than a security matter: it can help organise resources and control costs.

There is no need to start with a complex solution. For many small businesses, an up-to-date list of the applications they use, together with some essential details, is already enough to make more informed decisions.

Where to start without making things complicated?

An initial review can be based on very practical questions: which applications are essential to the business, who uses them, who has administrative access, where the information is stored and who should be contacted when a problem arises.

It is equally useful to understand whether updates are handled by the supplier or require internal action, how backups are made and what happens if an application can no longer be used. With externally contracted services, these points are worth confirming rather than assuming every responsibility is included in the same monthly fee.

For example, a company may subscribe to an online tool and benefit from platform updates carried out by its provider while remaining responsible for managing employee accounts, access permissions and certain security settings. The precise model varies between services, so understanding this division of responsibilities avoids confusion when action is needed.

Where a company develops software, sells digital solutions or depends on particularly critical applications, a more in-depth review may be justified, including using SBOMs or requesting them from suppliers when appropriate. For most small businesses, however, the important first step is to gain a clear view of the technology they actually depend on.

Knowing your systems is a way of preparing for the future

Small businesses now have access to tools that, only a few years ago, were reserved for organisations with specialist technology departments. That development has brought clear productivity gains and made many tasks simpler, but it has also meant that an important part of everyday operations now depends on external applications and services.

ENISA’s new guidance is a reminder that a digital product’s security is linked to what it contains and to the ability to track changes to its components. For those who simply use these tools, the lesson is complementary: understanding which systems exist, what they are for and who looks after them makes it easier to respond both to a security alert and to an ordinary operational change.

The aim is not to turn a business owner into an IT specialist or to create documentation that nobody will read. It is to have enough information so that, when a difficulty arises, the affected service can be identified, the right person contacted and an informed decision made.

And in a company where time and resources are limited, that preparation can make an important difference.

Can your company identify the applications it depends on most?

At TISEC, we help businesses understand their technology infrastructure, organise information about the systems they use and identify risks and opportunities for improvement, in keeping with the size and needs of each organisation.

If you would like to know where to begin or clarify which applications and responsibilities should be reviewed, get in touch with us so we can discuss your company’s circumstances.

Official source: ENISA — ENISA Technical Advisory for Software Bill of Materials, 22 October 2026

Precision note: an inventory of the applications used by a company is not the same as an SBOM, which describes the components of a software product. ENISA’s document is technical guidance and does not, in itself, create a general obligation for all SMEs to produce SBOMs.