NIS2 documentation in Malta: where to start under S.L. 460.41

First look at the whole set, not the first page

Most Maltese businesses in scope of NIS2 open with the question "which document do we write first?" The more useful question is the opposite one: what does the complete set look like? The Measures for a High Common Level of Cybersecurity across the European Union (Malta) Order (S.L. 460.41) does not prescribe a single file. It describes a system of technical, operational and organisational measures, and your documentation is the record that this system exists.

Article 19(2) of the Order requires measures based on an all-hazards approach and lists them from point (a) to point (k). For a company building its first documentation, five areas form the backbone.

1. Cybersecurity risk-management policy — article 19(2)(a) Article 19(2)(a) requires policies on risk analysis and information system security. Under article 19(1)(b), the level of security must be appropriate to the risks posed, taking into account the state of the art, relevant European and international standards and the cost of implementation; proportionality is judged by the entity's exposure to risks, its size, and the likelihood and severity of incidents. This is where your organisation writes down what it protects, what could go wrong and which controls it has chosen.

2. Incident handling — article 19(2)(b) Article 19(2)(b) requires incident handling as a measure in its own right. It connects directly to article 20, under which essential and important entities immediately notify the national CSIRT of any incident that has a significant impact on the provision of their services, then submit an early warning without undue delay and in any event within 24 hours of becoming aware of the significant incident, an incident notification within 72 hours of becoming aware of it, and a final report not later than one month after the incident notification. A written procedure is what makes those steps executable at three in the morning.

3. Business continuity — article 19(2)(c) Article 19(2)(c) covers business continuity, such as backup management and disaster recovery, and crisis management. Article 19(1)(c)(i) adds that the appointed security liaison officer facilitates the development, implementation, maintenance and review of business continuity plans and, where necessary, termination plans, and under article 19(1)(c)(iii) maintains and exercises an operator security plan. These are plans that are meant to be exercised, not filed.

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

5. Management responsibility and training — article 18 Article 18(1) requires management bodies of essential and important entities to approve the cybersecurity risk-management measures under article 19 and to oversee their implementation. Under article 18(3), members of 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 employees on a regular basis so they can identify risks and assess cybersecurity risk-management practices.

The remaining points of article 19(2) — acquisition, development and maintenance including vulnerability handling and disclosure (e), assessing the effectiveness of measures (f), basic cyber hygiene and training (g), cryptography (h), human resources security, insider risk, access control and asset management (i), multi-factor authentication and secured communications (j) and logging and traceability (k) — sit inside or alongside these five.

Why the risk-management policy is the natural first step

Only after you can see the whole does the sequence become obvious. The cybersecurity risk-management policy is the first of the five, and it is the document the other four build on.

• It sets the scale. Article 19(1)(b) makes proportionality depend on exposure, size and the likelihood and severity of incidents. Until that judgement is written down, there is no defensible basis for deciding how detailed the incident procedure or the continuity plan needs to be.
• It feeds the other documents. Article 19(1)(c)(ii) requires the security liaison officer to ensure the entity conducts and maintains appropriate risk assessments. Continuity planning under article 19(2)(c) and supplier requirements under article 19(3) both start from the same risk picture.
• It is what management approves. Article 18(1) speaks of approving the cybersecurity risk-management measures and overseeing their implementation — a board cannot approve a set of measures that has never been described in one place.

Writing it first does not make anything else optional. Article 19(4) states that where an entity finds it does not comply with the measures in article 19(2), it must take all necessary, appropriate and proportionate corrective measures without undue delay.

Supervision asks for the set, not a single document

This is a fact worth planning around. Under article 7(1), the Critical Infrastructure Protection Department is the national supervisory authority responsible for monitoring implementation of the Order and ensuring compliance with it. Under article 7(3), it is responsible among other things for ensuring that risk assessments are carried out, that operator security plans and business continuity plans are drawn up and maintained, and for instigating simulated runs of those plans.

The supervisory powers over essential entities in article 29(2) are explicit about documents:

For important entities, article 30(1) provides for action through ex post supervisory measures where there is evidence, indication or information of non-compliance, and article 30(2) lists comparable powers, including requests for information covering documented cybersecurity policies (article 30(2)(d)) and requests for evidence of operator security plans and business continuity plans (article 30(2)(i)). When these powers are exercised, the authority states the purpose of the request and specifies the information requested (articles 29(5) and 30(5)).

Read the list again: policies, evidence of implementation, plans, audit results. That is a set. Procuring customers ask the same way, for the same reason.

The supply-chain ring: why suppliers get evidence requests

There is a second, quieter reason the documentation set matters even to companies still working out their own status.

In-scope entities are required by article 19(2)(d) to manage supply chain security, including security-related aspects of their relationships with direct suppliers and service providers. Article 19(3) requires them to take into account the vulnerabilities specific to each direct supplier and service provider, the overall quality of their products and cybersecurity practices including secure development procedures, and the results of the coordinated security risk assessments of critical supply chains carried out under Article 22(1) of the Directive.

The practical consequence is a ring: an entity that must assess its suppliers has to ask those suppliers for something in writing. So questionnaires and evidence requests travel down the chain to companies that may never appear in the First Schedule or the Second Schedule themselves. Having the five areas documented turns a tender-stage security annex from a scramble into an attachment.

A practical order of work

1. Establish your classification. Article 4 sets out which entities are essential entities and which are important entities, by reference to the types listed in the First Schedule and Second Schedule and the size ceilings for medium-sized enterprises. A structured self-assessment against article 4 is the sensible starting point before any drafting begins. 2. Write the risk-management policy — article 19(2)(a), scaled by the proportionality factors in article 19(1)(b). 3. Write the incident handling procedure — article 19(2)(b), with the reporting steps of article 20 built into it as concrete actions and owners. 4. Write business continuity and the related plans — article 19(2)(c) and article 19(1)(c), remembering that article 7(3)(e) provides for simulated runs. 5. Set supplier requirements — article 19(2)(d) and article 19(3), so the same questions you are asked can be asked of your own suppliers. 6. Record management approval and training — article 18(1), 18(3) and 18(4).

Also note the registration duties: under article 7(4), essential and important entities providing services in Malta register on the national self-registration mechanism and provide at least the entity name, the CSIRT providing monitoring services, contact details including email addresses, IP ranges and telephone numbers, the relevant sector or sub-sector, and where applicable the Member States where they provide services in scope. Under article 7(5), changes to those details are notified without delay and in any event within two weeks of the date of the change.

Documentation does not by itself demonstrate that an organisation meets the Order. It is the record of decisions the Order requires you to make. For the exact electronic notification and registration channels and any procedural detail not set out above, please confirm with the published guidance of the Critical Infrastructure Protection Department (official source).