Skip to main content
FromNine
Menu

ArchitectureCloud

NIS2 for Malaysian software and managed service providers

NIS2 obliges essential and important entities in the EU to secure their supply chain, and holds their management to account for it. A Malaysian software house or managed service provider usually meets the directive through its customers’ contracts, and sometimes directly. What the directive asks, how it reaches a supplier in Malaysia, and how its 24-hour early warning sits beside the six-hour notification that applies to NCII entities under Malaysia’s Cyber Security Act 2024.

By
FromNine editorial team
Published
Reading time
9 min read

Key takeaways

  1. NIS2 binds through each Member State’s own law. National rules were due to apply from 18 October 2024, yet several countries were late, so check the law wherever your EU clients operate.
  2. Article 21 counts supplier security and secure development among the minimum measures, and Article 20 has management approve them. EU clients pass both down to their Malaysian suppliers by contract.
  3. An EU client has 24 hours to give an early warning of a significant incident. Under Act 854 and its incident notification regulations, an NCII entity in Malaysia already has six hours, so incident processes built for it run on a shorter clock.
Contents

Where NIS2 stands in late 2026

The NIS2 Directive (opens external site) was published at the end of December 2022 and took effect on 16 January 2023. Member States were given until 17 October 2024 to pass national measures, which were to apply from 18 October 2024, the day the first NIS Directive was repealed.

A directive needs national legislation before it binds anyone, and here the pace has varied. Some countries finished on time, others only during 2025 or 2026, and the Commission has taken infringement steps against the latecomers. Registration, reporting channels and the supervising authority differ from one Member State to the next. A Malaysian provider with customers in four Member States may face four versions of the same duties.

Table 1Key NIS2 dates, plus one Cyber Resilience Act date for software products
DateEventConsequence
16 January 2023NIS2 takes effectTransposition work begins in each Member State.
17 October 2024Deadline for national laws; Implementing Regulation (EU) 2024/2690 adoptedTechnical rules in detail for digital providers such as cloud, data centre and managed service firms.
18 October 2024National laws due to apply; first NIS Directive repealedEntities in scope carry the duties wherever the national law is already in force.
17 April 2025Member States due to have listed the entities in scopeEach entity registers and keeps its details current.
11 September 2026Cyber Resilience Act: first reporting duties for manufacturersExploited vulnerabilities and severe incidents affecting software products must be reported.

Essential and important entities

Two annexes decide which sectors count. Annex I covers the highly critical ones, from energy, transport, banking and health to water, digital infrastructure, managed ICT services, public administration and space. Annex II adds sectors such as postal services, waste, chemicals, food, manufacturing, digital providers and research. As a rule, only medium-sized and large organisations are in scope, though a few types, central government entities and DNS and trust service providers among them, are in scope at any size.

Within that population, Article 3 separates essential entities, mostly large organisations in Annex I sectors plus the size-independent cases, from important entities, which are all the others. Essential entities face proactive supervision, including audits and inspections; important entities are supervised after the fact, when the authority sees signs of a breach.

The duties themselves are identical for both groups: risk-management measures in Article 21, reporting in Article 23 and management accountability in Article 20. Supervision and fines are what differ. National law must allow fines of up to at least EUR 10 million or 2 % of global turnover for an essential entity, and EUR 7 million or 1.4 % for an important one, taking the higher figure in each case. Whether public administration can be fined, and how much, is left to each Member State.

When a Malaysian provider is in scope itself

Building software is not a NIS2 sector as such. Running it can be. Annex I covers managed service providers, described broadly as firms that install, manage, operate or maintain ICT products, networks, infrastructure or applications for clients, on site or at a distance. Cloud and data centre providers are covered as well, subject to the size rules. For these firms, Implementing Regulation (EU) 2024/2690 (opens external site) sets the technical expectations in detail.

A Malaysian address does not take such a firm outside the directive. Article 26 requires certain digital providers that offer services in the Union without being established there, including cloud, data centre, content delivery network, managed service and managed security service providers, to designate a representative in one of the Member States they serve. A Malaysian managed service provider that operates applications for EU clients should ask its counsel whether this applies.

Most software suppliers will still meet NIS2 indirectly, as their EU clients convert their own supply-chain duty into clauses, questionnaires and audits. Software products have a regime of their own in the Cyber Resilience Act (opens external site): manufacturers have had to report exploited vulnerabilities and severe incidents since 11 September 2026, and its remaining obligations apply from 11 December 2027.

What Article 21 asks for

Article 21 calls for proportionate technical, operational and organisational measures that cover every kind of hazard, follow current good practice and recognised standards, and fit the entity’s exposure, size and potential impact. Its ten minimum headings fall into four groups:

  • Governance: risk analysis and security policies, checks on whether the measures work, and training together with basic cyber hygiene.
  • Operations: incident handling, backups, disaster recovery and crisis management.
  • Technical controls: cryptography and encryption where it fits, staff security, access control and asset management, and strong or continuous authentication with secured communication channels.
  • Suppliers: the security of each relationship with a direct supplier or service provider, and security in acquiring, developing and maintaining systems, including how vulnerabilities are handled and disclosed.

The last group is where suppliers come in. Article 21(3) asks an entity to weigh the specific weaknesses of each direct supplier, how good its products and security practice are overall, and how securely it develops software. A Malaysian supplier should expect EU clients to examine how it builds software, not merely what it ships.

Management signs off and carries the responsibility

Under Article 20, the management bodies of entities in scope approve the measures, oversee them and can be held liable when the entity falls short. They must be trained, and the entity is encouraged to train its wider workforce too. Public bodies remain subject to the national rules on the liability of officials.

For a supplier, that shifts the conversation. A board that signs off the measures wants evidence a non-specialist can follow: which supplier sits behind which service, which risks are accepted, and what testing has really taken place.

Reporting deadlines: 24 hours, 72 hours, one month

Article 23 requires a significant incident to be reported to the national CSIRT or competent authority. An incident is significant if it disrupts the service severely, causes the entity serious financial loss, or does considerable harm to other people or organisations, or could do so. The reporting runs in steps:

Table 2Reporting steps for a significant incident, Article 23(4) of NIS2
StepDeadlineWhat it contains
Early warning24 hours from awarenessSuspected unlawful or malicious cause; possible cross-border effect.
Incident notification72 hours from awarenessUpdated early warning, first assessment of severity and impact, indicators of compromise if any.
Intermediate reportOn requestStatus updates the authority asks for.
Final reportOne month after the notificationFull account, probable cause, mitigation and cross-border effect; for an incident still open, a progress report first and the final report a month after it is handled.

Where it makes sense, the entity also warns its own service users promptly about significant incidents likely to affect them, and each national law adds forms and portals.

The clock starts when the entity becomes aware. If the incident starts at a supplier, the customer can only hit 24 hours if the supplier spots it, understands it and reports it within a few hours. Monitoring, logs and an agreed reporting line therefore belong in the contract, not only in the runbook.

How Act 854 compares for teams in Malaysia

Malaysia’s Cyber Security Act 2024 (Act 854) (opens external site) has been in operation since 26 August 2024. The National Cyber Security Agency (NACSA), under the National Security Council, administers it. The Act places duties on National Critical Information Infrastructure (NCII) entities, among them risk assessment and audit, codes of practice and incident notification. Under the incident notification regulations (P.U. (A) 220/2024), an NCII entity notifies a cyber security incident within six hours of it coming to its knowledge and supplies the full details within fourteen days.

The two regimes are separate. NIS2 binds organisations in the EU, while Act 854 binds organisations designated as NCII entities in Malaysia. A Malaysian provider can meet both at once: as a supplier to an EU customer under NIS2, and as a supplier to an NCII entity at home. Where they overlap in practice is the incident process. A team that already detects, classifies and escalates within six hours for an NCII customer has the monitoring and contacts an EU customer needs for its 24-hour early warning. The reports differ in recipient, content and format, so write both paths down.

What an EU customer will ask of a supplier in Malaysia

Article 21 ends up, in practice, as questions a supplier should answer from material it already has. The common ones:

  • How do you build software securely? Threat modelling for major changes, code review, security tests and dependency checks in the build, signed artefacts, and an SBOM per release.
  • How do you handle vulnerabilities? A public reporting route, response targets by severity, and a warning to the customer when its environment is affected.
  • Who of your staff can reach our systems? Individual accounts with MFA, least privilege, temporary elevation, and a trail of every admin action.
  • Can you give us the evidence after an incident? Security events with reliable time stamps, kept for an agreed time and exportable for the customer’s own reports.
  • How fast will you tell us? A named contact, an agreed channel, a reporting time well within the customer’s 24 hours, and support in finding the root cause.
  • Does recovery actually work? Restores that have been tested, recovery targets that match the customer’s, and a procedure that has been rehearsed.
  • Who else is in the chain? A current list of subcontractors, hosting locations and key third-party components and services.
  • How do we leave? Data export in workable formats, documentation and handover help, so the customer stays in control when it changes supplier.

Good engineering teams already do much of this. What changes under NIS2 is that the customer has to be able to prove it. Our page on trust and compliance sets out our own practice as a supplier, with an information security management system certified to ISO/IEC 27001.

A checklist for contracts and procurement

  1. Link each supplier to the services it supports and note which ones can reach your systems or data.
  2. Tier suppliers. Those able to run or alter critical systems get the strictest terms.
  3. Put the measures in writing: security requirements, reporting time and channel, vulnerability handling, log retention, audit or evidence rights, subcontracting and locations.
  4. Collect evidence. Certificate scopes, test reports, an SBOM, the last successful restore.
  5. Agree how the relationship ends before it starts: data return, transition help and a run-on period.
  6. Rehearse an incident with every critical supplier, including the early warning.
  7. Keep the register live. An annual update leaves it wrong for most of the year.

National law settles the details

Portals, forms, the authority in charge and any extra national requirements all differ, and some countries link Article 21 to a national scheme or certification. Jurisdiction normally follows establishment, with Article 26 as the exception. Public electronic communications providers answer to each country they serve. Cloud, data centre and managed service providers and several other digital providers answer to the country of their main EU establishment, or of their representative if they have none. Public administration entities answer to the state that created them.

What to watch in the coming months

  • Progress of transposition in each country where your clients operate: registration dates, decrees and authority guidance.
  • The Digital Omnibus proposal (opens external site), COM(2025) 837 of 19 November 2025, which would channel incident reports under several EU laws, NIS2 and DORA included, to a single ENISA entry point. As of October 2026 it was still with the European Parliament (opens external site)), and current channels and deadlines hold until it applies.
  • EU-level risk assessments of critical ICT supply chains under Article 22, which entities must factor into their supplier measures.
  • The Cyber Resilience Act reaching full application on 11 December 2027.
  • In Malaysia, new NACSA directives and codes of practice under Act 854 where you serve NCII entities.

Financial entities follow the Digital Operational Resilience Act instead of the NIS2 rules on ICT risk, incident reporting and supervision; see our article on DORA and ICT providers in Malaysia. The Commission’s NIS2 policy page (opens external site) lists the directive and its implementing acts.

Sources

  1. EUR-Lex. Directive (EU) 2022/2555 (NIS2 Directive) (accessed )
  2. EUR-Lex. Commission Implementing Regulation (EU) 2024/2690 (accessed )
  3. EUR-Lex. Regulation (EU) 2024/2847 (Cyber Resilience Act) (accessed )
  4. EUR-Lex. Proposal for a Regulation on the simplification of the digital legislative framework (Digital Omnibus), COM(2025) 837 (accessed )
  5. National Cyber Security Agency (NACSA). Cyber Security Act 2024 (Act 854) (accessed )
  6. European Commission. NIS2 Directive: securing network and information systems (accessed )

Supplying software or managed services to EU customers?

We help providers and their EU clients with the engineering side of NIS2: hardened build pipelines, access control, incident-grade logging, restores that are tested and a planned exit. Whether NIS2 applies to you is for your counsel to judge.