NIS2 in Malta: what S.L. 460.41 actually requires your company to produce

The law, and who falls under it

Malta implements the NIS2 Directive through the Measures for a High Common Level of Cybersecurity across the European Union (Malta) Order (S.L. 460.41). The Order does not talk about "cybersecurity in general" — it names concrete duties, and it names the two categories of organisation that carry them.

Article 4 draws the line. Entities of a type listed in the First Schedule that exceed the ceilings for medium-sized enterprises are essential entities; qualified trust service providers, top-level domain name registries and DNS service providers are essential entities regardless of size. Entities of a type referred to in the First or Second Schedule that do not qualify as essential are important entities (article 4(2)). The Schedules cover energy, transport, banking, health, drinking water, waste water, digital infrastructure, ICT service management, public administration and space; the Second Schedule adds postal and courier services, waste management, chemicals, food, several manufacturing branches, digital providers and research organisations.

Under article 23(1), entities within the scope of the Order fall under Maltese jurisdiction if they are established in Malta, with specific rules for electronic communications providers, cloud, data centre, managed service and managed security service providers and online platforms.

The national supervisory authority is the Critical Infrastructure Protection Department (CIP Department), responsible for monitoring implementation of the Order and ensuring compliance with it (article 7(1)). Where the Schedules designate another competent authority for a sector, that authority acts under the CIP Department's supervision.

The documented risk-management measures: five core areas, one set

Article 19 is the operative obligation. Measures must be appropriate and proportionate technical, operational and organisational measures (article 19(1)(a)), based on an all-hazards approach, and article 19(2) lists eleven areas that must be included at least. Five of them form the backbone that everything else hangs on.

1. Risk-management policy. Article 19(2)(a) requires "policies on risk analysis and information system security" — article 19(2)(a). This is the document that states what your systems are, what can go wrong, how likely and how severe that is, and which controls you have chosen in response. Article 19(1)(c)(ii) also requires the entity to conduct and maintain appropriate risk assessments, with a designated security liaison officer responsible for making sure that happens.

2. Incident handling. Article 19(2)(b) requires incident handling as a standing capability, not an improvisation. In Malta this is tied to article 19(1)(d): the entity must receive CSIRT monitoring services from either an internal CSIRT or an autonomous CSIRT. Written procedures — who detects, who classifies, who escalates, who notifies — are what turn that into evidence.

3. Business continuity. Article 19(2)(c) covers "business continuity, such as backup management and disaster recovery, and crisis management" — article 19(2)(c). The security liaison officer must facilitate the development, implementation, maintenance and review of business continuity plans and, where necessary, termination plans (article 19(1)(c)(i)), and must ensure the entity maintains and exercises an operator security plan (article 19(1)(c)(iii)).

4. Supply-chain security. Article 19(2)(d) requires "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers" — article 19(2)(d). Article 19(3) sharpens it: entities must take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers, including their secure development procedures.

5. Management responsibility. Article 18(1) requires that management bodies approve the cybersecurity risk-management measures under article 19 and oversee their implementation. The same provision states that the natural persons composing the management bodies may be held liable for infringements of that article, in accordance with articles 31(10)(b) and 33. Approval is therefore a documented act of the management body, not an informal nod.

The remaining areas of article 19(2) — secure acquisition and development including vulnerability handling, effectiveness assessment, cyber hygiene and training, cryptography, human resources and access control, multi-factor authentication, and logging and traceability — sit inside the same set. Where an entity finds that it does not comply with article 19(2), it must take all necessary, appropriate and proportionate corrective measures without undue delay (article 19(4)).

Incident notification: what has to leave the building, and when

Under article 20(1), essential and important entities shall immediately notify the national CSIRT of any incident that has a significant impact on the provision of their services. The mere act of notification does not subject the notifying entity to increased liability.

Article 20(5) sets out what must be submitted:

• an early warning, without undue delay and in any event within twenty-four (24) hours of becoming aware of the significant incident, indicating where applicable whether the incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact (article 20(5)(a));
• an incident notification, without undue delay and in any event within seventy-two (72) hours of becoming aware of the significant incident, updating the earlier information with an initial assessment of severity and impact and, where available, indicators of compromise (article 20(5)(b));
• an intermediate report on relevant status updates, upon request of the national CSIRT (article 20(5)(c));
• a final report not later than one (1) month after the submission of the incident notification, describing the incident, the likely root cause, applied and ongoing mitigation measures and any cross-border impact (article 20(5)(d)).

A trust service provider notifies the national CSIRT, with regard to significant incidents affecting its trust services, without undue delay and in any event within twenty-four (24) hours of becoming aware of the significant incident (article 20(6)). Where appropriate, recipients of the services must also be notified of significant incidents likely to adversely affect them (article 20(2)).

The exact electronic notification and registration channels are to be verified against the published guidance of the Critical Infrastructure Protection Department as the official source.

Approval, training and registration

Three duties are frequently underestimated because they are short provisions.

Management approval (article 18(1)) — the measures under article 19 must be approved by the management body and their implementation overseen by it.

Training. The Order is explicit: "Members of the management bodies of essential and important entities are required to follow training in order to carry out their tasks." — article 18(3). And for staff: "Essential and important entities shall offer similar training to their employees on a regular basis, in order that they gain sufficient knowledge and skills to enable them to identify risks and assess cybersecurity risk-management practices and their impact on the services provided by the entity." — article 18(4).

Registration. Essential and important entities providing services in Malta, as well as entities providing domain name registration services in Malta, must register on the national self-registration mechanism established by the CIP Department (article 7(4)). The submission must include at least the name of the entity; the name of the CSIRT providing monitoring services and whether it is internal or autonomous; the address and up-to-date contact details, including email addresses, IP ranges and telephone numbers; where applicable the relevant sector and sub-sector from the First or Second Schedule; and where applicable a list of the Member States where services within the scope of the Order are provided. Changes to those details must be notified to the CIP Department without delay and in any event within two (2) weeks of the date of the change (article 7(5)).

The supply-chain ring: why suppliers outside the scope get asked too

This is the part that reaches far beyond the Schedules, and it is a matter of law, not of market fashion.

Because article 19(2)(d) makes supply chain security a mandatory element of every in-scope entity's measures, and because article 19(3) requires those entities to take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of their products and cybersecurity practices, a covered customer cannot manage its own obligation without looking at its suppliers.

The practical consequence: companies that are not themselves essential or important entities receive supplier security questionnaires, contractual security clauses and requests for evidence from customers who are. The supplier's own status under article 4 does not remove the customer's duty under article 19(2)(d) — so the request lands anyway. A supplier that can hand over a written risk-management policy, an incident handling procedure and a continuity plan answers in days; a supplier that has nothing written down answers in weeks, or loses the contract.

Supervision looks at the whole documentation set — start with the policy

Supervision under S.L. 460.41 is documentary. For essential entities, article 29(2) gives the CIP Department, or where designated the competent authority, powers including on-site inspections and off-site supervision (article 29(2)(a)); regular and targeted security audits by an independent body or the authority itself (article 29(2)(b)); ad hoc audits, including where justified on the ground of a significant incident (article 29(2)(c)); requests for information necessary to assess the cybersecurity risk-management measures adopted, including documented cybersecurity policies (article 29(2)(e)); requests to access data, documents and information (article 29(2)(f)); requests for evidence of implementation of cybersecurity policies, such as the results of security audits and the underlying evidence (article 29(2)(g)); requests for evidence of CSIRT monitoring services (article 29(2)(h)); and requests for evidence of operator security plans, business continuity plans and where necessary termination plans (article 29(2)(j)).

For important entities, article 30 provides the equivalent ex post supervisory measures, including requests for information to assess the risk-management measures adopted, including documented cybersecurity policies (article 30(2)(d)), evidence of implementation of cybersecurity policies (article 30(2)(f)) and evidence of operator security plans and business continuity plans (article 30(2)(i)). The costs of a targeted security audit carried out by an independent body are borne by the audited entity, except in duly substantiated cases where the authority decides otherwise (articles 29(4) and 30(4)).

In other words, the authority does not ask for one file. It asks for the set — policy, incident procedure, continuity plan, supplier controls, and the management body's approval — and it reads them against each other.

Which is why the sequence matters. Of the five core areas, the risk-management policy under article 19(2)(a) is the first one to write, because everything else references it: the incident handling procedure classifies against the risks it names, the continuity plan protects the services it identifies as critical, the supplier controls apply to the dependencies it lists, and the management body approves it under article 18(1). Begin with a structured self-assessment of where your organisation sits under article 4, then write the policy — the other four documents build on it.