What a NIS2 cybersecurity risk-management policy must contain in Malta

The document behind the duty: where the content requirements come from

In Malta, NIS2 is transposed by the Measures for a High Common Level of Cybersecurity across the European Union (Malta) Order (S.L. 460.41). The content of a cybersecurity risk-management policy is not a matter of style preference: it follows the structure of article 19 of the Order.

Article 19(1)(a) sets the baseline: essential and important entities must "take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimise the impact of incidents on recipients of their services and on other services" (article 19(1)(a)).

That sentence explains why the policy is written at the level of your systems and your services — not as an abstract security manual. Everything that follows in this article is about turning article 19 into a readable document.

The statutory content list: article 19(2), points (a) to (k)

Article 19(2) states that the measures "shall be based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents" (article 19(2)), and that they shall include at least the following. A policy that is missing one of these headings is visibly incomplete on its face:

Note that the Maltese list runs to eleven points, and that points (i) and (k) are worded more broadly than many readers expect: the Order expressly names an insider risk management policy and logging and traceability.

Article 19(3) adds a drafting instruction for the supply chain chapter: entities "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 and service providers, including their secure development procedures" (article 19(3)). A generic supplier clause does not reflect that wording; a named-supplier assessment does.

Article 19(4) closes the loop: where an entity finds that it does not meet the measures in article 19(2), it must take "without undue delay, all necessary, appropriate and proportionate corrective measures" (article 19(4)). In practice this means the policy needs a place to record known shortfalls and their correction, rather than presenting an idealised picture.

All-hazards and proportionality: why two policies legitimately differ

Two Maltese companies in the same sector can hold visibly different policies without either being wrong. The reason is written into article 19(1)(b), which requires a level of security appropriate to the risks posed, taking into account the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation — and then adds: "Provided that when assessing the proportionality of the measures, they shall take due consideration of the degree of the entity's exposure to risks, the entity's size and the likelihood of occurrence of incidents and their severity, including their societal and economic impact" (article 19(1)(b)).

Three variables, therefore, drive depth: exposure, size, and likelihood and severity of incidents, including societal and economic impact. A strong policy makes that reasoning explicit — a short paragraph per chapter explaining why the chosen measure is proportionate for this organisation. That paragraph is what a supervisor can actually read and follow.

The all-hazards approach in article 19(2) also stretches the scope beyond hacking scenarios: it covers "the physical environment of those systems", so server rooms, power, access to premises and physical media belong in the document too.

Which parts depend on your own profile

Several parts of the policy cannot be copied from anyone. They are determined by facts specific to your organisation:

• Sector and sub-sector. The First Schedule (sectors of high criticality) and the Second Schedule (other critical sectors) list the types of entities in scope and name the competent authority per sector — for most sectors the CIP Department as the national supervisory authority, and for digital infrastructure, digital providers and postal and courier services the Malta Communications Authority (MCA). Your policy should state which Schedule entry describes you.
• Statutory classification. Under article 4(1), an essential entity includes, among others, entities of a type in the First Schedule which exceed the ceilings for medium-sized enterprises under Article 2(1) of the Annex to Commission Recommendation 2003/361/EC, and qualified trust service providers, top-level domain name registries and DNS service providers regardless of their size. Under article 4(2), entities of a type in the First or Second Schedule that do not qualify as essential are important entities. The classification changes the supervisory regime: article 29 applies to essential entities (including regular and targeted security audits), while article 30 applies ex post to important entities.
• Services and dependencies. Article 19(1)(a) ties the measures to the systems used for your operations and for the provision of your services, so the policy needs a service inventory and the dependencies behind each service.
• Roles. Article 19(1)(c) requires the appointment of a security liaison officer with the necessary expertise, who facilitates business continuity plans and, where necessary, termination plans, maintains appropriate risk assessments, maintains and exercises an operator security plan, and acts as the point of contact with the CIP Department or, where designated, the competent authority.
• Monitoring arrangement. Article 19(1)(d) requires the entity to receive CSIRT monitoring services from an internal CSIRT or an autonomous CSIRT.

If you are unsure which classification and Schedule entry apply to you, a short applicability check is the fastest way to settle those inputs before drafting.

Management approval, oversight and training

The policy is not an IT deliverable. Article 18(1) provides that management bodies of essential and important entities approve the cybersecurity risk-management measures in accordance with article 19 and oversee their implementation, and that the natural persons composing the management bodies may be held liable for infringements in accordance with articles 31(10)(b) and 33.

Two practical consequences for the document:

• It should carry a dated approval by the management body, and a record of the oversight cycle (when implementation was reviewed, by whom, what was decided).
• Appointing a security liaison officer under article 19(1)(c) does not move the approval and oversight duty away from the management body.

On training, article 18(3) states that members of the management bodies are required to follow training in order to carry out their tasks, and article 18(4) requires entities to offer similar training to their employees on a regular basis, so that they gain sufficient knowledge and skills to identify risks and assess cybersecurity risk-management practices and their impact on the services provided. Training therefore appears twice in a well-built policy: as a measure under article 19(2)(g), and as a governance duty under article 18(3) and 18(4).

What makes the policy verifiable

Supervision is document-driven. Article 29(2)(e) allows requests for information necessary to assess the cybersecurity risk-management measures adopted, including documented cybersecurity policies, and article 29(2)(g) allows requests for evidence of implementation of cybersecurity policies. The equivalent powers for important entities sit in article 30(2)(d) and 30(2)(f). Article 29(2)(j) and 30(2)(i) add requests for evidence of operator security plans, business continuity plans and, where necessary, termination plans.

A verifiable policy therefore does three things:

1. Names the provision next to each requirement — "incident handling (article 19(2)(b))" rather than "incident handling (NIS2)". Anyone reading it can check the source text.
2. Separates the rule from the evidence — each chapter points to the artefact that shows the measure is running (logs, test records, supplier assessments, training records).
3. Records the proportionality reasoning required by article 19(1)(b), so the depth chosen is explained rather than assumed.

No document produces a legal outcome by itself, and no policy removes the possibility of supervisory or enforcement measures. What a well-referenced policy does is make your position readable — for the management body approving it under article 18(1), and for the authority reviewing it under article 29 or article 30.

For practical details that the Order does not spell out — such as the electronic registration and notification channels — consult the published guidance of the Critical Infrastructure Protection Department (official source).