NIS2 compliance for non-EU AI and managed service suppliers

The proposed supplier configures deployed model services, maintains integrations, manages changes and provides remote technical support. These activities strongly support classification as a managed service provider, or MSP. The definition covers installing, managing, operating or maintaining information and communication technology (ICT) products, infrastructure, applications and other network and information systems through assistance or active administration, onsite or remotely. It does not require a recurring contract or privileged access in every case. (NIS2, Article 6(39), Annex I, sector 9; Belgian NIS2 Law, Article 8(38).)

A software licence or development project requires a closer examination. Bare delivery of code may fall outside this category. Adding installation, maintenance or operational assistance can bring the service within it. Removing the word “managed” from the contract changes nothing if the activity remains covered.

Check cloud classification separately. A cloud service enables on-demand administration and broad remote access to scalable, elastic, shareable computing resources. Software as a service can qualify. Buying cloud infrastructure for the supplier's own operations does not, by itself, make its customer offering a cloud service. A provider performing cybersecurity risk-management activities may also be a managed security service provider. (NIS2, Article 6(30), (40); Belgian NIS2 Law, Article 8(29), (39); CCB NIS2 FAQ, sections 1.22.7–1.22.8.)

Prepare a classification note identifying the contracting and performing entities, service boundaries, architecture, access rights and operational responsibilities. Record every applicable category. Upstream outsourcing does not transfer the supplier's own legal responsibilities.

For these categories, the ordinary medium-or-larger test is met with at least 50 annual work units, or when both annual turnover and the balance-sheet total exceed €10 million. The large-enterprise boundary is at least 250 annual work units, or both turnover above €50 million and a balance-sheet total above €43 million. The alternatives matter: exceeding only one financial ceiling does not suffice where headcount remains below the relevant threshold. (Recommendation 2003/361/EC, Annex, Articles 2–6; NIS2, Articles 2–3.)

Use approved accounts and annual work-unit calculations. Identify partner and linked enterprises, including overseas relationships, and apply the required proportional or full aggregation. Ordinary threshold movements generally require two consecutive accounting periods; ownership changes need immediate reassessment. A new enterprise without approved accounts uses a good-faith estimate. Retain ownership, voting and control records alongside the calculation. (Recommendation, Annex, Articles 3–6; Commission SME User Guide, pages 11, 14–15.)

A medium MSP ordinarily becomes an important entity; a large MSP ordinarily becomes essential. A small supplier is generally outside this ordinary route. Special statutory identification, including critical-entity or systemic-risk provisions, can change that result. Selling to a bank alone does not. Belgium also allows the CCB to consider genuine independence within a group. Separate incorporation does not establish the required independence. (Belgian NIS2 Law, Articles 3, 9–11; CCB FAQ, sections 1.5–1.5.2.)

For an established EU provider, jurisdiction follows where cybersecurity risk-management decisions are predominantly taken, then the statutory fallback tests for cybersecurity operations and the establishment with most EU employees. For a provider without an EU establishment, the representative must be in a Member State where it offers services. If Belgium is the only such market, the representative must be there. Genuine supply into several Member States changes the available jurisdiction analysis. (NIS2, Article 26; Belgian NIS2 Law, Article 4.)

The NIS2 EU representative can be an EU-established natural or legal person explicitly designated to act for the supplier. For the Belgian route, appoint a person established in Belgium. Use a signed mandate covering authority communications, receipt and escalation of requests, access to evidence, reporting arrangements and backup contacts. The mandate should let the representative perform the role promptly. The supplier remains accountable and exposed to enforcement. (NIS2, Article 6(34), Article 26(3)–(4), recital 116; Belgian NIS2 Law, Article 4(3), (5)–(6), Article 8(33).)

This appointment does not itself satisfy any separate General Data Protection Regulation (GDPR) or AI Act representative requirement. Nor does it automatically make the representative an agent for service of private bank claims.

Belgium's special digital-provider registration period is two months. The CCB's current guidance applies the period to a new entrant from the date it enters scope. The original December 2024 deadline concerns the initial cohort. Record the actual scope-entry date and arrange the filing route before operations begin. (Belgian NIS2 Law, Article 14(1); CCB FAQ, section 4.14.2.)

Prepare the supplier's identity and business-register information, categories, relevant addresses, representative and operational contacts, Member States served and Internet Protocol (IP) ranges. Each legal entity registers separately. A parent registration does not replace its subsidiary's filing. If the overseas supplier cannot register through Safeonweb@Work, the current FAQ directs it to contact info@ccb.belgium.be. Obtain the CCB's instructions for the foreign entity and retain the submission acknowledgement. An enquiry alone is not proof of completed registration. (Belgian NIS2 Law, Articles 13–14; CCB FAQ, sections 3.13.5–3.13.8.)

Maintain the record after filing. Article 13(3) requires relevant changes without delay and within two weeks; Article 14(2) gives a three-month outer limit for its listed digital-provider information. Update promptly and apply the tighter period where the ordinary registration duty also applies. Registration is an administrative obligation, not regulatory approval of the business.

The management body must approve and oversee cybersecurity measures and undertake training. Management can be held liable for violations under the applicable rules. The supplier remains responsible for its risk analysis and implementation. Assign named owners for service security, upstream dependencies, incident decisions and regulator communications. (Belgian NIS2 Law, Articles 30–32; NIS2, Articles 20–21.)

Commission Implementing Regulation (EU) 2024/2690 applies to in-scope MSPs and cloud providers. Its Annex specifies technical and methodological requirements. Build the control programme around risk assessment, incident handling, continuity and recovery, supply-chain security, secure development and vulnerability disclosure, access and asset controls, cryptography, personnel security, training and effectiveness reviews. Document a reasoned justification where a qualified requirement is considered inappropriate, inapplicable or infeasible. (Regulation 2024/2690, Article 2 and Annex.)

For managed AI operations, the evidence should connect those requirements to the actual service: model and integration changes, privileged access, logging, dependency failures, recovery tests and upstream assurance. Retain management approvals, training records, control reviews and remediation decisions. These records also support bank due diligence.

Essential entities face Belgium's mandatory periodic conformity-assessment regime; important entities may use it voluntarily while retaining their security and reporting duties. The available routes include CyberFundamentals, known as CyFun, ISO/IEC 27001 and CCB inspection. For essential entities, the assessment must cover all their networks and information systems; assessor authorization and the chosen route also matter. A certificate held by an upstream cloud provider does not establish the supplier's conformity. (Belgian NIS2 Law, Articles 39–42; Royal Decree of 9 June 2024, Articles 4–8.)

For a new essential entity, current CCB guidance applies the relevant 18- and 30-month assurance milestones from entry into scope or transition to essential status. For ISO, submit the certification scope and statement of applicability to the CCB within 18 months, together with the latest internal audit under current guidance; certification follows by 30 months. CyFun normally requires initial verification by 18 months and the applicable final assurance by 30 months. For direct CCB inspection, submit a CyFun Basic or Important self-assessment, or the ISO information-security policy, scope, statement of applicability and latest internal audit, to the CCB within 18 months and formally request the inspection; report on progress by 30 months. Select and calendar the applicable route. These periods do not postpone the underlying controls or incident duties. No universal “NIS2 certification” settles registration, reporting and other legal requirements. (Royal Decree, Articles 22–23; CCB FAQ, sections 4.11–4.14; CCB, NIS2 18 April 2026 deadline: what essential entities must have in place, updated 16 April 2026.)

Use a common operational response with separate legal assessments. A service failure can trigger the bank contract before it becomes a significant NIS2 incident, a major DORA incident or a personal-data breach.

Apply the supplier's significance tests

Regulation 2024/2690 supplies the relevant thresholds. For an MSP, any of these service events qualifies:

• Complete unavailability exceeding 30 minutes.
• Limited availability for more than one hour affecting more than the smaller of 5% of the service's EU users and one million EU users.
• Compromise of service-related data integrity, confidentiality or authenticity resulting from suspected malicious action.
• Compromise of service-related data integrity, confidentiality or authenticity affecting more than the smaller of 5% of EU users and one million EU users.

These are alternative triggers. The suspected-malicious-data-compromise trigger has no minimum duration or user count. Cloud services have corresponding tests. User calculations include the relevant users associated with business customers, not just contracting banks. (Regulation 2024/2690, Articles 3(3), 7 and 10.)

Apply the general triggers too: actual or potential direct financial loss exceeding the lower of €500,000 and 5% of the supplier's total annual turnover in the preceding financial year; actual or potential exfiltration of its trade secrets; actual or potential death or considerable health damage; and successful suspected malicious unauthorized access capable of severe operational disruption. Incidents that are not individually significant count collectively as one significant incident where they occur at least twice within six months, share an apparent root cause and together meet the financial-loss test. Scheduled interruptions and planned consequences of scheduled maintenance are excluded. (Regulation 2024/2690, Articles 3–4.)

Run the supplier's reporting sequence

Notify Belgium's national computer security incident response team at the CCB through its NIS2 notification platform. Assess awareness promptly; completing a root-cause investigation is not a prerequisite to reporting. The statutory sequence is:

1. Without undue delay, an early warning within 24 hours of becoming aware of a significant incident.

2. Without undue delay, an incident notification within 72 hours of that awareness, with initial severity, impact and available indicators of compromise.

3. Intermediate updates when requested.

4. A final report within one month after the 72-hour notification. If the incident remains ongoing, provide a progress report, then the final report within one month after handling it.

(Belgian NIS2 Law, Articles 34–35; CCB NIS2 Notification Guide v1.3, sections A4–A5.)

The early warning should address suspected unlawful or malicious cause and possible cross-border effects. The final report covers the incident, cause, mitigation and cross-border impact. Where appropriate, promptly inform recipients of significant incidents likely to affect their services adversely. Significant cyber threats can also require protective information for recipients. (Belgian NIS2 Law, Articles 34–35.)

Give the bank time to act

The bank independently classifies its incident under DORA and reports to its competent financial supervisor. Its initial report is due as early as possible, within four hours of major-incident classification and normally within 24 hours of awareness. A later classification starts a four-hour period. The intermediate report is due within 72 hours after the initial notification; update it without undue delay and when regular activities recover. The final report is due within one month after the intermediate or latest updated intermediate report. Credit institutions receive no weekend or holiday extension for initial and intermediate reports. (DORA, Articles 18–19; Delegated Regulations (EU) 2024/1772 and 2025/301, Article 5 of the latter.)

Agree supplier notices early enough to support those clocks, with continuing updates and contacts available around the clock. Do not wait for the supplier's own NIS2 threshold. Preserve each party's assessment, timestamps, filings and receipts. The bank's DORA report does not discharge the supplier's CCB duty.

DORA is the sector-specific regime for covered financial entities under NIS2. That treatment does not extend automatically to their ICT suppliers. The supplier can have direct NIS2 duties while accepting contractual commitments required by the bank. The DORA accountability analysis explains these separate roles. (DORA, Article 1(2); NIS2, Article 4; Belgian NIS2 Law, Article 6(3).)

Keep the bank's classification of a critical or important function separate from regulatory designation of a critical ICT third-party provider. Designation under DORA Article 31 creates a direct oversight relationship. Financial entities can continue using a designated third-country provider only if it establishes an EU subsidiary within 12 months of designation. That conditional requirement does not apply merely because a bank calls its service critical. DORA oversight also preserves applicable NIS2 duties. (DORA, Articles 3(22), 31(12) and 32(8).)

Negotiate commitments the supplier can perform throughout its chain. Obtain upstream cooperation on logs, incident facts, investigations, recovery, audit support, material changes and exit. Identify gaps before promising access to a bank or supervisor. The bank's additional subcontracting requirements for services supporting critical or important functions require particular attention. (DORA, Articles 28–30; Delegated Regulation (EU) 2025/532, Articles 3–6.)

Reuse verified service maps, supplier inventories, control evidence and incident records across reviews. The DORA register guide addresses the bank's separate recordkeeping task. Reusable evidence cannot replace the supplier's representative appointment, registration or reporting.

Map personal data and incident evidence

An EU bank's disclosure of personal data to a separate South African supplier can be a GDPR international transfer even where servers stay in Europe and access is remote. South Africa has no EU adequacy decision. Establish an applicable transfer mechanism, often appropriate standard contractual clauses, with the required assessment and supplementary safeguards. GDPR territorial scope and processor-contract duties need separate analysis. (GDPR, Articles 3, 28 and 44–46; Decision (EU) 2021/914, Article 1, clauses 14–15; European Data Protection Board Guidelines 05/2021, version 2.0, paragraphs 7 and 15–22.)

Under South Africa's Protection of Personal Information Act 4 of 2013, or POPIA, identify who determines purposes and means and who acts as an operator. The supplier may be an operator for bank instructions and a responsible party for its own processing. Apply POPIA's territorial test to the actual arrangement, including South African processing means. Written security terms, authorized processing and confidentiality belong in the operating model. Map any onward transfer from South Africa against section 72. (POPIA, sections 1, 3, 19–21 and 72.)

Keep breach notices distinct. A GDPR processor alerts the controller without undue delay. The controller notifies its supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of the breach, unless the breach is unlikely to risk individuals' rights and freedoms. High-risk breaches also require prompt data-subject communication, subject to Article 34's exceptions. Under POPIA, reasonable grounds to believe personal information was accessed or acquired by an unauthorized person trigger the operator's immediate notice to the responsible party. The responsible party notifies the Information Regulator and identifiable data subjects as soon as reasonably possible under section 22. POPIA supplies neither the GDPR's 72-hour period nor its risk-based reporting exception. (GDPR, Articles 33–34; POPIA, sections 21–22.)

Incident logs can contain personal data, bank secrets and nonpersonal security information. Define lawful recipients, access restrictions and transfer routes for each. Verify authority requests and escalate them promptly; confidentiality should support controlled disclosure rather than obstruct required cooperation. Foreign demands do not themselves settle GDPR transfer conditions. Where applicable, the transfer clauses require notification, legality review and proportionate disclosure. (Belgian NIS2 Law, Articles 5, 26 and 44; GDPR, Article 48; Decision 2021/914, clauses 14–15.)

Finally, verify the South African legal entity and signing authority. Review governing law, dispute forum, service arrangements and enforcement against relevant assets. Confirm that upstream terms support the promised remedies and cooperation. The AI supplier contracts service addresses the wider enterprise contract structure.

The recommended route is a documented Belgian NIS2 programme alongside coordinated bank contracts. Before launch, approve the classification note, group-size evidence, jurisdiction analysis, representative mandate, management responsibilities, control plan, incident workflow and contract changes. Complete registration within the applicable period and retain the actual acknowledgement. Calendar assurance milestones and reassess material changes.

These are proposed work products and business actions. This guide cannot stand in for an executed mandate, completed filing or conformity assessment.

The outcome changes if the actual service is confined to uncovered software delivery, the properly aggregated supplier remains small without a special scope trigger, an EU establishment changes jurisdiction, or services are offered in additional Member States. New data uses, control changes, upstream dependencies or formal critical-provider designation also require reassessment. Preserve those decision points in the launch approval and change process.

Review the supplier's regulatory scope and bank contracts