NIS2: what affects mid-size companies — duties and deadlines

Scope follows from two criteria that must both apply: sector and company size. The directive lists the sectors in two annexes. The first covers eleven sectors of high criticality (European Commission): energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure, management of information and communication technology services for third parties, public administration and space. The second annex names seven further critical sectors (European Commission): postal and courier services, waste management, chemicals, food, manufacturing, digital providers and research.

For mid-size companies the manufacturing sector matters most in practice, because it is drawn broadly: medical devices, computer, electronic and optical products, electrical equipment, machinery and equipment, motor vehicles and parts, and other transport equipment. A supplier with 80 employees (project experience, as a typical order of magnitude) producing assemblies for machine builders may therefore be directly in scope, even though nobody in the business has ever spoken of critical infrastructure.

The size thresholds follow the European definition of medium-sized enterprises. From 50 employees, or an annual turnover and balance sheet total each above 10 million euros (European Commission), a company in a covered sector normally counts as an important entity. From 250 employees, or an annual turnover above 50 million euros or a balance sheet total above 43 million euros (European Commission), and within a sector of the first annex, it becomes an essential entity. For certain business types — providers of particular digital infrastructure services, for example — special rules apply regardless of size.

The most important point in this table is often overlooked: the substantive catalogue of duties does not differ between the two categories. What differs is supervision and the penalty range. Anyone reassuring themselves that they are merely an important and not an essential entity faces exactly the same work — only with a lower probability of being asked about it unannounced.

The catalogue of risk management measures is drafted as a minimum list (European Commission). It is deliberately technology-neutral: it does not say which tool to use, only which subject has to be governed. The measures must be appropriate to the risk — a company with 60 employees will not build the same thing as a grid operator, but it has to cover all the topics.

In practice the list condenses into six fields of work. None of them is new; most companies already have parts of them without calling them that. The difference lies in evidence: what sits today in the head of the person looking after the systems has to exist in writing and be current.

One item on the minimum list stands out: policies to assess the effectiveness of the measures (European Commission). Issuing a rule is therefore not enough. It has to be checked and recorded whether the rule works in daily operation. This is where many existing security folders fail: they describe a target state that stopped matching the business years ago.

The directive addresses management bodies directly. They must approve the risk management measures, oversee their implementation and take part in training regularly so that they can assess risks and management practices (European Commission). The rules also provide for management responsibility in the event of breaches. Execution can be delegated; accountability cannot.

For a mid-size company that has a very practical consequence: security work which used to run on the side now needs a dated approval. A management decision that endorses the plan of measures, names budget and responsibility and sets a review date is not a formality. It is the evidence that the management duty was exercised — and it stops the work being dropped at the first burst of order pressure.

The training duty is often underrated because it does not feel like a technical task. Yet it is the point where evidence can be produced most cheaply: attendance lists, contents and dates are documented quickly and cover an audit point completely. It makes sense to combine it with the training and rollout that new workflows require anyway, rather than scheduling a separate session that nobody attends.

The most common mistake in this situation is waiting. As long as the last implementing rule is unpublished, every investment looks premature. In reality the remaining uncertainty concerns formalities above all: the registration procedure, notification forms, deadlines for first registration, the assignment of particular business types. The substance has been settled since the directive was adopted, and it largely coincides with what a company needs anyway in order to be able to work again after an outage.

Framing the preparation as an IT security project makes it larger than it needs to be. It carries much better as an inventory exercise: which systems exist, which data moves between them, who has access to what, what happens on failure? These are the same questions that open every process analysis — the results pay for themselves twice.

Six weeks is not a promise but an order of magnitude from projects of this kind (project experience). What matters is not the pace but that every week ends with a result on paper. An asset register that is 80 per cent complete (project experience) helps more in an inspection than a perfect one that was never started.

Most mid-size companies run at least one system that has received no updates for years: a production control system, an older merchandise management system, a machine controller with a fixed operating system, a time recording server under a desk. Such systems are the hardest point in risk management, because they cannot be secured by patching and because replacing them often collides with production.

The directive does not demand replacement. It demands that the risk is identified, assessed and treated with appropriate measures. Containment is usually the workable answer: separate the system on the network from the rest of the business, limit access to named people and routes, run data exchange through controlled handover points, secure the logs and prepare a recovery of the whole system. Documented and justified, a contained legacy system withstands an inspection; ignored, it is the open point every inspection finds first.

Where containment reaches its limits — because the system sits centrally in the data flow, or because the vendor provides no support at all — replacing the legacy system becomes a medium-term task. It then belongs in the plan with a date and a budget, not in the category of known problems. A known, scheduled shortcoming is judged differently in supervision than an unknown one.