NIS2 in Malta: what the Order means for you and your software suppliers

01NIS2 in Malta as of November 2026

The NIS2 Directive (opens external site), formally Directive (EU) 2022/2555, was printed in the EU’s Official Journal of 27 December 2022 and took effect on 16 January 2023. Each Member State had until 17 October 2024 to adopt and publish its national rules and was to apply them from the following day, when the original NIS Directive ceased to have effect.

A directive binds organisations only through national law. Malta transposed NIS2 with the Measures for a High Common Level of Cybersecurity across the European Union (Malta) Order, 2025 (opens external site), issued as Legal Notice 71 of 2025 and numbered S.L. 460.41. Legal Notice 22 of 2026 brought the Order into force on 23 January 2026, and Legal Notice 89 of 2026 amended it on 7 April 2026. It repeals the NIS1 rules in S.L. 460.35 and makes the Critical Infrastructure Protection Department (CIP Department) the competent authority. Other Member States moved at their own pace, some on time and some only in 2025 or 2026, so a group active in several countries still meets different registration rules, portals and supervisors.

02Which organisations the Order covers

The directive, and with it the Order, reaches public and private organisations in two groups of sectors. Annex I lists the sectors of high criticality, among them energy, transport, health, banking and financial market infrastructures, drinking and waste water, digital infrastructure, the management of ICT services, public administration and space. Annex II adds other critical sectors such as manufacturing, chemicals, food, waste management, postal and courier services, digital providers and research. Size usually decides: medium-sized and large organisations are covered, smaller ones generally are not. A few types are covered at any size, central government entities, DNS service providers and trust service providers among them.

Article 3 divides them into two classes:

• Essential entities: for the most part large organisations in Annex I sectors, together with those that count as essential whatever their size, for example central government entities, DNS service providers, registries of top-level domains and qualified trust service providers. Their supervision is proactive and can include audits and inspections on site.
• Important entities: all other organisations that Annex I or II brings in. The authority supervises them after the fact, stepping in when it sees signs that the rules are not being met.

The duties are the same for both classes: the risk-management measures of Article 21, the reporting of Article 23 and the accountability of management under Article 20. Supervision and fines are where they part. For breaches of Article 21 or 23 the directive requires national law to allow fines up to a ceiling of no less than EUR 10 million, or 2% of total worldwide turnover if higher, for an essential entity; for an important entity the ceiling is no less than EUR 7 million or 1.4%. Member States decide whether, and how far, fines reach public administration entities. For the penalty provisions that apply in Malta, read the Order itself.

Could the Order apply to your software supplier directly?

Developing software is not a NIS2 sector in its own right, yet some suppliers are caught anyway. Annex I includes managed service providers, and the definition is wide: organisations that look after a customer’s ICT for it, installing, running or maintaining its applications, networks, infrastructure or products, on site or at a distance. A supplier of at least medium size that operates or maintains applications for clients can therefore carry duties of its own, and so can providers of cloud computing and data centre services. Implementing Regulation (EU) 2024/2690 (opens external site) sets out at length the technical requirements that apply to them.

For most software firms, though, the Order arrives indirectly: their clients pass on their own supply-chain obligations as security questionnaires, audit rights and clauses in the contract. Products are covered separately by the Cyber Resilience Act (opens external site), Regulation (EU) 2024/2847, under which manufacturers must report severe incidents and actively exploited vulnerabilities from 11 September 2026, with the remaining obligations following on 11 December 2027.

03Article 21: the minimum set of measures

Article 21 asks for technical, operational and organisational measures that are appropriate, proportionate and designed for all hazards. They must be state of the art, take account of European or international standards that are relevant, and fit the entity’s risk exposure, its size and how badly an incident could hurt. As a minimum they deal with:

1. 01policies for analysing risk and securing information systems;
2. 02the handling of incidents;
3. 03crisis management and continuity of operations, with backups and disaster recovery;
4. 04security of the supply chain, covering the security side of relations with each direct supplier or service provider;
5. 05security when acquiring, developing and maintaining networks and information systems, vulnerability handling and disclosure included;
6. 06ways to assess how effective these measures are;
7. 07cybersecurity training and basic cyber hygiene;
8. 08rules for cryptography and, where it fits, encryption;
9. 09security of personnel, access control and the management of assets;
10. 10where appropriate, multi-factor or continuous authentication and protected channels for voice, video, text and emergencies.

Suppliers enter at points 4 and 5. Under Article 21(3) an entity weighs the weaknesses particular to each direct supplier, the general quality of its products and security practice, and how securely it develops. In plain terms, your clients will want to see how your software is made, not just the release they receive.

04The board signs off and is answerable

Article 20 makes the management body of an essential or important entity approve the risk-management measures, supervise how they are put into effect and answer for breaches. Its members have to be trained, and the entity is encouraged to give its staff regular training too. In a Maltese ministry or public entity, the national rules on the liability of public officers and institutions continue to apply alongside.

That changes what a supplier is asked. A board that must sign off the measures needs evidence it can follow: which supplier carries which service, what risk is left over, and what was really tested.

05Reporting an incident: the directive’s 24 hours, 72 hours and one month

Article 23 obliges entities to notify significant incidents to their CSIRT or competent authority. An incident counts as significant when it has caused, or could cause, serious disruption to operations or financial loss for the entity, or when it has harmed, or could harm, other people or organisations, materially or otherwise. The directive sets the stages below; the forms and the channel to use in Malta follow from the Order and the CIP Department’s guidance.

Where it makes sense, the entity must also tell the users of its services, without undue delay, about significant incidents likely to affect them.

The time limit runs from the moment the entity knows. If the incident begins in a supplier’s environment, you can give your early warning within 24 hours only if the supplier notices the problem, understands it and reports it to you within a few hours. Monitoring, logs and an agreed reporting route therefore belong in the contract, not only in the engineering plan.

06What a client under the Order will expect from its software supplier

In practice Article 21 becomes a set of measures and proof that a supplier should be able to produce on request, without opening a separate project. Those we are asked for most:

• A secure way of building software. Threat models for significant changes, code review by a colleague, automated security tests and dependency checks in the pipeline, signed builds, and a software bill of materials (SBOM) with every release.
• Handling and disclosing vulnerabilities. A public route for reporting them, response times agreed per severity level, and a warning to the client whenever one touches its environment.
• Controlled access for supplier staff. Personal accounts, multi-factor authentication, only the privileges needed, elevated rights for a limited time, and a record of each administrative action taken in the client’s systems.
• Logs that serve as evidence. Security events recorded with dependable timestamps, retained for an agreed period and exportable, so the client can complete its early warning and its final report.
• Working together in an incident. A named person and channel, a reporting time well within the client’s 24 hours, and help in finding the root cause.
• Recovery that has been proven. Backups tested by actually restoring them, recovery objectives that fit the client’s own, and a procedure that has been rehearsed.
• A documented supply chain. An up-to-date list of subcontractors and hosting locations, and of the principal external components and services the solution needs.
• A way out. Data exported in formats the client can use, documentation and help with handover, so it can move to another supplier and keep the service under control.

Mature engineering teams already do most of this. What the Order adds is that the client has to be able to show it, to its own board and to the CIP Department if asked. Our page on trust and compliance sets out how we work as a supplier, including our ISO/IEC 27001 certification for information security management.

07Checklist for contracts and calls for tenders

1. 01Link suppliers to services. Note which supplier supports which service covered by the Order, and which suppliers can reach your systems or data.
2. 02Rank them by how critical they are. Suppliers that operate, or can change, critical systems get the strictest requirements.
3. 03Put the measures in writing. Security requirements, reporting time and channel for incidents, vulnerability handling, logging and retention, rights to audit or to evidence, rules on subcontracting and locations. A contracting authority tendering under the Public Procurement Regulations (S.L. 601.03) can set these out in the call for tenders itself.
4. 04Ask to see proof. Certificates with their scope, test results, an SBOM, the date the last restore was tested.
5. 05Settle the exit at the start. Return of data, help with the transition, and how long the supplier keeps the service running in the meantime.
6. 06Practise together. Hold an incident exercise with critical suppliers that includes the 24-hour early warning.
7. 07Look again regularly. Suppliers, services and threats move on; a register reviewed once a year is stale for most of that year.

08In Malta, the Order and the CIP Department settle the details

Registration, the reporting channel, forms, the authority and any extra requirements come from national law, which in Malta means S.L. 460.41 and the guidance of the CIP Department (opens external site). The Department runs the national self-registration mechanism, so the first practical step for an organisation that may be covered is to check whether it has to register. Normally the jurisdiction is that of the country where the entity is established. Article 26 sets exceptions: providers of public electronic communications answer to each country where they offer services; digital providers such as data centres, cloud services and managed service providers to the country of their main establishment; and public administration entities to the state that set them up. A group with a Maltese company and operations elsewhere may therefore deal with more than one authority.

09What to follow next

• Guidance from the CIP Department on the Order, on self-registration and on reporting, and any further Legal Notice amending S.L. 460.41.
• The Digital Omnibus proposal (opens external site) of 19 November 2025, COM(2025) 837, under which incident reports under NIS2, the GDPR, DORA and other acts would pass through one entry point operated by ENISA. In October 2026 the file was still with the European Parliament (opens external site)); until it is adopted and starts to apply, today’s channels and deadlines stay in place.
• The EU’s coordinated risk assessments of critical ICT supply chains under Article 22, which entities have to weigh when they choose measures for their suppliers.
• The Cyber Resilience Act timetable for software products, which applies in full from 11 December 2027.

Financial entities supervised by the Malta Financial Services Authority (MFSA) follow DORA instead of the NIS2 rules on ICT risk management, incident reporting and supervision; our article on DORA and ICT third-party providers covers that side. The European Commission lists the directive and its implementing acts on its NIS2 policy page (opens external site).