Sample NIS2 gap analysis — Article 21, logistics SaaS
Executive summary
Baltika Freight Systems OÜ, a 90-person Estonian logistics-software SaaS classified by its management as an important entity under NIS2, runs a partial ISO 27001-style control set. Tested against the ten risk-management families of NIS2 Art. 21(2)(a)–(j), that control set shows material gaps in 4 families, partial coverage in 5, and full coverage in one (multi-factor authentication, point (j)). The sharpest exposure is not a control at all: the incident process — staff email the CTO — cannot meet a single Art. 23 reporting deadline (§4). First moves: stand up incident handling with the 24-hour / 72-hour / one-month reporting path (R1), put the ~30 unmanaged suppliers under a supply-chain security programme (R2), and establish an effectiveness-assessment cycle so the control set stops being paperwork (R3).
Every register row quotes its requirement verbatim from the Art. 21 text fetched during the run; 7 of 10 rows also map to fetched rows from the gateway's security-controls catalog, and the three that matched no fetched control say so instead of carrying an invented reference. The technical implementing regulation under Art. 21(5) was searched and not returned — it is named as out of scope in §6, not silently included.
Scope & method
Baltika Freight Systems OÜ (fictional) sells freight booking and customs-documentation software to forwarders and carriers, with 90 staff and production hosted on a single cloud provider. The engagement's scoping input, provided by the client and not verified here: Baltika is an important entity under NIS2 as a transport-adjacent digital provider. A paid engagement records the classification analysis; this sample takes it as given.
Frameworks in scope: NIS2 Art. 21(2)(a)–(j) — the ten cybersecurity risk-management measure families — and Art. 23 reporting obligations, both fetched from the gateway (Art. 21, Art. 23, eur-lex.europa.eu), tested against the client's existing control set. The technical implementing regulation under Art. 21(5) was searched in the same run; the gateway did not return it, so its requirements are not part of the tested baseline (§6). The one on-topic row that search did return — the Commission's guidelines on the application of Article 4(1) and (2) (European Commission, DG CONNECT) — restates that the Art. 21(2) measures include the specific requirements listed in points (a) to (j), which is the list this register walks.
Evidence basis: in a paid engagement, document review and control interviews — policy suites, runbooks, contracts, and the people who operate them. In this sample the "current state" column derives from the fictional client description instead; it is marked as fiction so the format, not the client, is what you are evaluating.
Show the text form
[NIS2 Directive (EU) 2022/2555]
Art. 21(2) risk-management measures -- ten families (a)-(j)
Art. 23 reporting obligations -- 24 h / 72 h / 1 month
| binds (Art. 21(1)) v
[Baltika Freight Systems OÜ -- important entity (client-provided classification)]
| tested against
[Existing control set -- partial ISO 27001-style] -> gap register (§3)
[Incident process -- "email the CTO"] -> reporting readiness (§4)
[Art. 21(5) implementing acts -- technical & methodological requirements]
searched this run; not returned by the gateway; not cited (§6)Gap register — Art. 21(2)(a)–(j)
One row per measure family. The requirement column quotes the fetched Art. 21(2) text verbatim; the current-state column is the fictional client; verdicts are analyst-assigned and would be confirmed or corrected in senior review.
| Point | Requirement — Art. 21(2), fetched text | Current state at Baltika (fictional) | Verdict | Remediation | Citations | Control mapping |
|---|---|---|---|---|---|---|
| (a) | “policies on risk analysis and information system security” | Annual risk workshop feeding a spreadsheet register; no approved information-security policy suite; no criteria for when to re-assess. | Partial | Approve a policy suite covering risk analysis and information-system security; define re-assessment triggers (R6). | NIS2 Art. 21(2)(a) · RSK-01 — Risk management program · RSK-04.3 — Risk-assessment trigger criteria | cited |
| (b) | “incident handling” | Ad hoc — staff email the CTO, who decides case by case. No classification, no runbook, no on-call rota. | Gap | Stand up an incident-response plan, severity classes, and an on-call rota; build the Art. 23 reporting path (§4, R1). | NIS2 Art. 21(2)(b) · IRO-04 — Maintained incident response plan · IRO-07 — Integrated incident response team | cited |
| (c) | “business continuity, such as backup management and disaster recovery, and crisis management” | Nightly database backups to a second region; restores never rehearsed; no disaster-recovery or crisis-management plan. | Partial | Rehearse restores on a schedule; write and exercise disaster-recovery and crisis-management plans (R5). | NIS2 Art. 21(2)(c) · IRO-02.4 — Incident classes and mission-continuity actions · IRO-06.1 — Response-test coordination with related plans | cited |
| (d) | “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers” | Roughly 30 cloud and data suppliers, no register; contracts on supplier paper with no security clauses; customs-data integrations rely on provider defaults. | Gap | Build a supplier register with security requirements per contract; remediate known supplier weaknesses; reduce single-supplier concentration (R2). | NIS2 Art. 21(2)(d) · TPM-01 — Third-party management program · TPM-03.3 — Supply-chain weakness remediation · TPM-06 — Third-party personnel security · TDA-03.1 — Diversify security technology suppliers | cited |
| (e) | “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” | CI pipeline runs dependency scanning on the booking platform; no vulnerability-disclosure channel; new tooling is bought without a security check. | Partial | Publish a vulnerability-disclosure channel; add a pre-acquisition security assessment step (R7). | NIS2 Art. 21(2)(e) · TPM-04.1 — Pre-acquisition risk assessment | cited — Fetched control covers the acquisition limb; no fetched row on vulnerability handling and disclosure. |
| (f) | “policies and procedures to assess the effectiveness of cybersecurity risk-management measures” | The ISO 27001-style control set was adopted in 2024 and has not been tested since; no internal audit function. | Gap | Establish a recurring effectiveness-assessment cycle — internal audit or equivalent — reporting to management (R3). | NIS2 Art. 21(2)(f) · CPL-02.1 — Internal audit function | cited |
| (g) | “basic cyber hygiene practices and cybersecurity training” | A security-awareness deck at onboarding; nothing role-specific, no exercises. | Partial | Add role-specific training and simulated-incident exercises on top of the onboarding deck (R9). | NIS2 Art. 21(2)(g) · IRO-05.1 — Simulated-event response training | cited — Fetched control covers the training limb; no fetched row on baseline hygiene practices. |
| (h) | “policies and procedures regarding the use of cryptography and, where appropriate, encryption” | TLS on all public endpoints; full-disk encryption on most laptops; no documented cryptography policy — key handling varies per engineer. | Partial | Write a cryptography and encryption policy; standardise key handling (R8). | NIS2 Art. 21(2)(h) | analyst draft — no fetched control maps; held for senior review |
| (i) | “human resources security, access control policies and asset management” | Joiner/leaver checklist exists, but the operations team shares one admin account for the customs-docs backend and there is no asset register. | Gap | Retire the shared admin account for per-person credentials; stand up an asset register; formalise HR security steps (R4). | NIS2 Art. 21(2)(i) | analyst draft — no fetched control maps; held for senior review |
| (j) | “the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate” | Company-wide SSO with MFA enforced on all staff and administrator logins; internal comms on an enterprise messaging platform. | Compliant | Maintain; review emergency-communication arrangements at the next policy cycle. | NIS2 Art. 21(2)(j) | analyst draft — no fetched control maps; held for senior review |
Every requirement is quoted from the Art. 21 row the gateway returned during this run (source: eur-lex.europa.eu, license EUR-Lex-Decision-2011-833). Control links are rows from the gateway's security-controls catalog fetched in the same run. Rows (h), (i), and (j) matched no fetched control and say so instead of carrying an invented reference; §6 names the fetched control rows that were considered and not used.
Incident-reporting readiness — Art. 23
Art. 23 puts significant incidents on a clock: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report not later than one month after that notification — with an intermediate report on request and recipient notification alongside. Baltika's current process is an email to the CTO. Tested obligation by obligation against the fetched text:
| Obligation | Fetched requirement | Baltika today (fictional) | Ready? |
|---|---|---|---|
| Art. 23(3) Significance test | An incident is significant if it “has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned” or considerable material or non-material damage to others. | No criteria — the CTO decides ad hoc whether something counts. | No |
| Art. 23(4)(a) Early warning | “without undue delay and in any event within 24 hours of becoming aware” — indicating suspected unlawful or malicious cause and possible cross-border impact, where applicable. | No CSIRT contact path, no on-call rota, no 24-hour clock. | No |
| Art. 23(4)(b) Incident notification | “without undue delay and in any event within 72 hours” — updating the early warning with “an initial assessment of the significant incident, including its severity and impact” and, where available, indicators of compromise. | No severity/impact assessment capability; indicators of compromise are not collected. | No |
| Art. 23(4)(c) Intermediate report | Relevant status updates on the request of the CSIRT or competent authority. | No owner who could produce one. | No |
| Art. 23(4)(d) Final report | Not later than one month after the incident notification: a detailed description including severity and impact, the type of threat or root cause, applied and ongoing mitigation measures, and any cross-border impact. | None of these facts is captured by the current email thread. | No |
| Art. 23(1)–(2) Recipient notification | Notify recipients of services of significant incidents likely to adversely affect service provision, and communicate measures or remedies recipients can take against significant cyber threats. | No customer-notification procedure exists. | No |
All rows cite NIS2 Art. 23 as fetched during the run (eur-lex.europa.eu); quoted fragments are verbatim.
Verdict: not ready. The email-the-CTO process has no significance test, no channel to the CSIRT or competent authority, and produces none of the artefacts the deadlines demand — a significant incident today would put Baltika in breach of Art. 23(4) within 24 hours of someone noticing. Which national authority receives Baltika's notifications is a Member-State determination a paid engagement records; it is held open here. This is roadmap item R1, ahead of every control gap in §3.
Remediation roadmap
Priority-ordered from the register: the clocked legal obligation first, then the largest unmanaged surfaces, then policy and hygiene work. Effort classes only — Small is policy or configuration work owned by one team, Medium is a cross-team capability build, Large would be structural change (none is required here). A sample carries no cost or calendar estimates; a paid engagement schedules the roadmap with the client.
| Priority | Action | Addresses | Effort class |
|---|---|---|---|
| R1 | Stand up incident handling and the Art. 23 reporting path: severity classes per Art. 23(3), the 24-hour / 72-hour / one-month artefacts, an on-call rota, and the CSIRT contact route. | (b) + Art. 23 | Medium |
| R2 | Supplier register with security requirements in each contract; remediation loop for known supplier weaknesses; reduce single-supplier concentration. | (d) | Medium |
| R3 | Recurring effectiveness-assessment cycle (internal audit or equivalent) reporting to management. | (f) | Medium |
| R4 | Retire the shared admin account for per-person credentials; stand up an asset register. | (i) | Small |
| R5 | Scheduled restore rehearsals; disaster-recovery and crisis-management plans, exercised. | (c) | Medium |
| R6 | Approved information-security policy suite with defined risk re-assessment triggers. | (a) | Small |
| R7 | Public vulnerability-disclosure channel; pre-acquisition security assessment step. | (e) | Small |
| R8 | Cryptography and encryption policy; standardised key handling. | (h) | Small |
| R9 | Role-specific training and simulated-incident exercises beyond the onboarding deck. | (g) | Small |
Method note & refusal discipline
- Requirements fetched through the Ansvar gateway. NIS2 Art. 21 and Art. 23 as provision lookups (eur-lex.europa.eu rows with source URL, publisher, and license preserved), plus three security-controls catalog searches — governance, incident & continuity, supply chain — totalling sixteen control rows. Nothing is cited from model recall.
- The implementing-regulation search failed honestly. The search for the NIS2 technical implementing regulation returned one on-topic row — the Commission's Article 4 application guidelines, cited in §2 — and five off-topic rows, all excluded: Regulation (EC) No 1907/2006 Art. 41; an EIOPA guidance row on rules under DORA for ICT and third-party risk management; Regulation (EU) No 167/2013 Art. 43; Regulation (EU) 2024/1257 Art. 6; and Regulation (EU) No 168/2013 Art. 48. The implementing regulation's technical requirements are therefore cited nowhere in this document, and whether it applies to Baltika at all — Art. 21(5) names the provider classes it covers — is held as an open scoping determination, not assumed.
- Control-mapping discipline. A register row links a control only where a fetched row genuinely covers the requirement; rows (h), (i), and (j) matched none and are marked analyst drafts. Three fetched control rows were considered and not used: AAT-01 and RSK-09.2 (both AI-specific — nothing in Baltika's scope is an AI system) and DCH-05.1 (considered for row (i); judged too narrow to carry it).
- Fiction boundary. The client, its 90 staff, its supplier count, and every current-state cell are invented; the classification as an important entity is stated as a client-provided scoping input. The regulation quotes, URLs, publishers, and licenses are fetched, not invented.
- What a paid engagement adds. Your real policies, contracts, and control owners under interview; verification of the NIS2 classification and the implementing-regulation question; national transposition and sector-regulator enrichment; and a named senior reviewer who confirms or corrects every verdict before it ships.
Sign-off
Senior review: [shown for format — fictional sample, nothing to certify] Reviewer: [named reviewer — CISSP / ISO 27001 lead auditor] Date: [—]
A paid engagement ships only after the named reviewer has validated every verdict and signed here. This sample is published unsigned, on purpose, so you can read the document exactly as it leaves the engine.
Want this for your organisation?
Download the blank NIS2 gap-analysis template (free XLSX) →
Scope a gap analysis →