A compliance officer receives a fresh ISO/IEC 27001:2022 certificate from the auditor and, in the same week, a question from the board: “so are we NIS2-compliant?” The question sounds reasonable — both things concern the same territory, speak a similar language and demand similar evidence. The trouble is that the certificate answers a different question. It attests that an information security management system conforms to a standard, not that the organisation performs the duties imposed by law.
This article is not a mapping tutorial; that one — which control answers which requirement — is our guide to mapping NIS2 requirements onto security standards. What interests us here is its boundary: obligations with no counterpart in any control of any standard, because they are legal parameters rather than security practices. Thresholds for qualifying an incident as significant, the addressee and the clock of a notification, a documented reporting path to the competent national team, personal accountability of the head of the entity. A crosswalk misses these not through bad workmanship, but because there is nothing on the other side to line up against.
Poland is the worked example, deliberately. NIS2 is a directive, so the concrete obligations live in national law, and the gap between “the directive says” and “your act requires” is where a false sense of compliance grows. The mechanism repeats in every member state; only the article numbers change.
Does an ISO 27001 certificate settle NIS2 compliance?
It does not. A certificate is a statement by a certification body that a management system conforms to a standard — a document about the system, not about the performance of a legal duty. The supervisory authority asks something else: did you file the early warning on time, did the head of your entity complete the annual training, did the person handling security tasks produce a criminal record certificate. The certificate answers none of these, because the standard never poses them.
The author of the mapping says the same, and bluntly. In the technical guidance to Implementing Regulation 2024/2690 — the document from which most crosswalks circulating on the market originate — ENISA states:
“Their partial or complete implementation does not assume compliance or conformity with the requirements of the regulation.”
— ENISA, Technical implementation guidance on cybersecurity risk-management measures, version 1.0, June 2025, p. 9.
The sentence concerns the guidance and examples of evidence in the ENISA document itself. If a European agency declines to guarantee compliance with its own guidance, written expressly for the regulation, it is hard to expect that guarantee from a standard written a decade earlier for a different purpose.
This is not an argument against ISO 27001. It is an argument against treating the certificate as evidence in proceedings about something else. The standard is good scaffolding — we return to that below. Wrong is only the belief that scaffolding replaces the building.
What exactly does ENISA reserve in its June 2025 guidance?
The key reservation sits on page 10 of the document and reads, verbatim:
“The mapping should not be interpreted as a measure of equivalency among different standards or frameworks. It simply refers to relevant requirements in these standards or frameworks without assessing whether these fully cover the requirements of the regulation.”
— ENISA, Technical implementation guidance on cybersecurity risk-management measures, version 1.0, June 2025, p. 10.
The second sentence carries the whole weight, and it is the one summaries lose. ENISA does not say “the mapping is incomplete” or “needs supplementing” — both would imply somebody compared the scopes and found gaps. It says something stronger: no coverage assessment was performed at all. The table records thematic adjacency — here a requirement of the regulation, there a control of related content — and that is where its role ends. Anyone who appends “therefore the control satisfies the requirement” is producing a judgement its author deliberately withheld.
This has a concrete evidentiary consequence. If your documentation presents an Annex A control as evidence that a requirement has been met, citing the ENISA mapping, you are citing a document that does not contain that conclusion. The counter-argument is not “your mapping is wrong” — it is “the mapping is not about that”. The difference is slight in conversation and decisive in proceedings.
The mapping method itself we covered separately, in the guide to mapping NIS2 requirements onto security standards. We reproduce neither the table nor the instructions for building it here, and deal exclusively with what remains on the far side of the boundary drawn above.
Key takeaway: the reservation on page 10 does not say the mapping is inaccurate. It says the mapping contains no coverage assessment — and therefore cannot be evidence of compliance, however good it may be.
Which standards did ENISA actually map the requirements to?
To five documents and to national frameworks — and the list is routinely extended in secondary coverage with items that are not in it. The guidance states (pp. 9-10) that each requirement was mapped to ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST Cybersecurity Framework 2.0, ETSI EN 319 401 V3.1.1 (2024-06) and CEN/TS 18026:2024, and additionally to the national NIS2 frameworks submitted by member states and collected in Annex I of the document.
CIS Controls are not on that list. This is not a criticism of CIS Controls — it is a very good catalogue and many organisations use it rightly. It is information about the precise reach of the ENISA reservation: it covers the five items named, and any crosswalk extending beyond them is somebody’s own work, which ENISA neither underwrites nor stands behind. If your compliance matrix was built from a summary rather than from the document, check whose mapping actually sits inside it — before it reaches the documentation you show an auditor.
Two limitations from the same page complete the picture. The mapping covered horizontal standards only, and only for selected topics; detailed standards and technical specifications appear solely in footnotes. The standards named are moreover examples — the choice belongs to the entity, guided by the context of its activities, and the document neither establishes a new standard nor duplicates existing ones.
One practical detail saves half a day of searching. The mapping tables are not in the PDF — in version 1.0 ENISA publishes them separately, as a spreadsheet on its own website (footnote 6, p. 10). Working with the PDF alone, you have implementation guidance, examples of evidence and tips in front of you, but not the mapping. Two different tools for two different jobs.
Who is bound by the ENISA guidance, and who is not?
The ENISA guidance supports Implementing Regulation 2024/2690, and that covers a narrow group of entities. The document names the group explicitly (p. 2): domain name system service providers, top-level domain name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers.
The reason for the narrowing is in the document’s own executive summary. For most critical sectors, member states set the requirements at national level; for several subsectors of digital infrastructure and ICT service management they were set at Union level because of the cross-border nature of those services. Outside that group the guidance may — as ENISA states on p. 7 — merely “provide indications”, useful to other bodies for improving their own cybersecurity.
Polish law restates that split directly. Article 8b(1) of the National Cybersecurity System Act, as amended on 23 January 2026 (Journal of Laws 2026, item 252, in force since 3 April 2026), requires exactly the same list of entities to apply the risk-management measures set out in Regulation 2024/2690. Paragraph 2 refers all other key and important entities to measures laid down in Commission implementing acts adopted under Article 21(5) of Directive 2022/2555 — that is, somewhere else.
For a hospital, a manufacturing plant or a water utility this carries a non-obvious consequence: the ENISA guidance is good practice for them, not a measure of compliance. It cannot carry an argument before the supervisory authority, because the regime that binds them is a different one. This is among the most frequent misunderstandings we see when reviewing documentation — a team painstakingly reproduces the structure of the ENISA guidance without first checking whether it is the addressee at all.
Note: before you start comparing your documentation against the ENISA guidance, establish whether your entity falls within the catalogue in Article 8b(1) of the National Cybersecurity System Act. That determines whether Regulation 2024/2690 is a source of obligation for you, or merely supporting material.
What changed in Polish law on 3 April 2026?
NIS2 stopped being a directive to read and became a duty to perform — with national deadlines, a national authority and national forms. The Act of 23 January 2026 amending the National Cybersecurity System Act (Journal of Laws 2026, item 252) was promulgated on 2 March 2026 and entered into force a month later, on 3 April 2026. It implements Directive 2022/2555 and anchors Implementing Regulation 2024/2690 in the Polish legal order.
The vocabulary changed too, and not cosmetically. The “operator of essential services” is gone, replaced by key entity and important entity — existing operators became key entities by operation of law. The glossary gained definitions of managed service provider and managed security service provider, along with the notion of the head of a key or important entity. Material written before April 2026 is out of date in its terminology, and with it in some of its article references.
The most important practical novelty is an obligation easy to overlook because it does not look like a security obligation at all. A key or important entity files an application for entry in the register within 6 months of the day it meets the criteria (Article 7c(1)), and reports any change of data within 14 days (paragraph 3). Nobody sends an invitation — qualification follows from the act itself, and registration is your move.
The application moreover carries a declaration by the head of the entity in the wording prescribed by the act: “Aware of the criminal liability for submitting a false declaration arising from Article 233 § 6 of the Act of 6 June 1997 – Penal Code, I declare that the data contained in the application are true” (Article 7c(5)). It is hard to imagine a clearer signal that this is a different category of obligation from implementing a control from an annex. An ISO 27001 certificate says nothing about whether the application was filed on time — that question does not fall within the scope of certifying a management system.
Why do thresholds for a significant incident fit into no standard?
Because a threshold is a legal parameter set outside the organisation; a standard can at most describe how to apply it. The act defines a significant incident as one that “causes or may cause a serious degradation of quality or an interruption of the continuity of the service provided by a key entity or an important entity, financial losses for that entity, or affects other natural persons, legal persons or organisational units without legal personality by causing serious material or non-material damage” (Article 2(7), as amended). The definition is qualitative — it names no outage hours and no user count.
The numbers come from two different acts, depending on who you are. For entities in the digital catalogue, the cases in which an incident is deemed significant are specified by Regulation 2024/2690; the ENISA glossary reduces this to one line: “Significant incident: an incident that meets the criteria of Article 3 of the regulation” (p. 168). For everyone else the thresholds are set by the Council of Ministers in a regulation — Article 11(4) requires it to address the number of users affected, the duration of the incident’s impact, the geographical spread and other sector-specific factors, expressly excluding entities for which the Commission has already set them.
Set this against what a standard can do. ISO/IEC 27001:2022 requires the assessment of events and a decision on their classification, but leaves the classification criteria to the organisation — they are to follow from its own risk analysis. That is sensible in a standard applied worldwide and across every industry. It is also the exact opposite of the logic of regulation, where the criterion is imposed, identical across the sector and independent of how your organisation rates its own risk.
ENISA itself points outside itself at this juncture. Listing the criteria worth including in a categorisation scheme — business impact, data sensitivity, legal and regulatory impact, scope and scale, type of attack, criticality of affected systems — it closes with “other criteria on what constitutes a significant incident as per this regulation” (p. 33). Build the categorisation at home, the author is saying, but check in the legal act what counts as significant.
Worth correcting here is the belief that recurs most often in NIS2 conversations: that the organisation sets its own thresholds. Until 3 April 2026 that reading still had some footing in practice; it has none today. The organisation sets its own categorisation scheme and its own handling priorities, but the threshold at which the notification clock starts is input data, not a decision. That distinction determines whether an incident procedure works under pressure or stalls on the question “is this a significant one yet?”.
Practical note: an incident categorisation scheme aligned with ISO 27001 is a necessary condition, not a sufficient one. Until you write into it the thresholds from the legal act that applies to you, you are classifying incidents in a methodologically correct and practically useless way from the standpoint of the reporting duty.
What reporting deadlines does the national act impose, and where do they come from?
There are three deadlines, and all of them run from the moment of detection or from the notification, not from the closure of incident handling. Article 11(1) of the National Cybersecurity System Act, in the wording in force since 3 April 2026, obliges a key entity and an important entity to:
- submit an early warning about a significant incident without undue delay and no later than within 24 hours of its detection, to the competent sectoral CSIRT (point 4);
- submit the incident notification itself without undue delay and no later than within 72 hours of detection, to the competent sectoral CSIRT (point 4a);
- provide an interim report on incident handling — at the request of the competent sectoral CSIRT (point 4b);
- provide a final report no later than within one month of the notification referred to in point 4a (point 4c).
Trust service providers operate under a stricter regime: they report a significant incident within 24 hours of detection (Article 11(1a)). If handling has not concluded by the final-report deadline, the act provides for a progress report and the final report shifts to one month from closure (Article 12b).
Note three things that no security control will settle. First, the addressee: the competent sectoral CSIRT, not any response team you happen to know — determining which one it is, is a legal and organisational task. Second, the channel: all these documents go through the ICT system referred to in Article 46(1). Third, the content: Article 12 enumerates six elements of the early warning, including the moment of occurrence and detection, the incident’s duration, and whether it concerns other member states.
On top of this comes an external communication duty. In the event of a significant cyber threat, the entity informs users about possible preventive measures, and about the threat itself provided this does not increase risk (Article 11(2a)); it informs them about a significant incident where that incident adversely affects service provision (Article 11(2b)). This is a communication decision with market consequences, taken under time pressure, against a criterion written into the act.
A standard describes incident response as a process: detect, assess, respond, learn. The act adds an addressee, a clock, a form and a channel. Those four are not “a better implementation of ISO 27001” — they are a separate layer of obligation, one that has to be designed, assigned by name and rehearsed before the phone rings.
What else will you not find in Annex A to ISO 27001?
Several obligations that the act describes with a precision unattainable for an international standard — because they are anchored in national institutions. These are the ones that most often fall out of crosswalks, and the ones that most often surface during an inspection.
A criminal record certificate. Before a person begins the tasks referred to in Article 8 or Article 11, they present the entity with information from the National Criminal Register attesting to the absence of convictions for offences against the protection of information; only then does the head of the entity admit them to those tasks (Article 8f(1)). ISO 27001 has a control for screening candidates, but it names neither the instrument, nor the catalogue of offences, nor the point at which admission becomes permissible.
Annual training for the head of the entity. The head of a key or important entity, and any person to whom their cybersecurity duties have been entrusted, undergo training once per calendar year, with a scope set by the act, and participation is documented (Article 8e). The standard requires awareness and competence; it sets no frequency, names no individual and demands no proof in that form.
Contact points. At least two people must be designated for contact with the entities of the national cybersecurity system — at least one in micro and small enterprises. Failing to designate them is expressly listed among the grounds for a penalty on the head of the entity (Article 73a(1)(6)).
A reporting channel for users. The grounds for a penalty also include failing to provide users with the ability to report a cyber threat, incident or vulnerability related to the service provided (Article 73a(1)(7)). This is a product requirement: it concerns the service you sell, not an internal process.
Each of these obligations has a distant relative in the standard. None has a counterpart that could be entered into a crosswalk without losing what matters about it — and what matters is usually the detail the standard deliberately leaves open.
Who is accountable when a duty goes unperformed?
The head of the entity — by name, and also when the duties were entrusted to somebody else. Article 8c(1) assigns to the head of a key or important entity accountability for the duties listed there, from the application for entry in the register, through the management system, to incident handling and reporting. Paragraph 2 adds a rule boards should read twice: where the head of the entity is a collective body and no responsible individual has been designated, all its members bear the accountability. Paragraph 3 closes the most common escape route — accountability persists even where some or all duties have been entrusted to another person with their consent.
The act goes further and enumerates what falls to the head of the entity (Article 8d): decisions on preparing, implementing, operating, reviewing and supervising the information security management system; planning adequate financial resources for cybersecurity duties; allocating cybersecurity tasks and supervising their execution; ensuring personnel are aware of those duties; ensuring the entity’s compliance with the law and its internal regulations.
The financial-resources point is the hardest to reproduce in a standard. A standard speaks of providing resources; the act turns underfunding into the personal problem of a named human being. Article 73a provides for a financial penalty on the head of the entity for failing to perform the duties under Articles 8d, 8e, 8f, 11 and a dozen other provisions, in an amount not exceeding 300% of the remuneration received, calculated on the rules used for holiday pay equivalent (paragraph 4), and up to 100% in public entities (paragraph 5). That penalty is independent of the one imposed on the entity itself (paragraph 3).
This is the point at which a conversation about compliance stops being a conversation about documentation and becomes a conversation about corporate governance. We name the pillar in which NIS2 sits governance, risk and compliance precisely because the first word comes first for a reason: without settling who is accountable by name, the other two have nothing to rest on.
What does a false sense of compliance actually cost?
It costs most in hours, but the currency is quantifiable too. A penalty on a key entity may not exceed EUR 10,000,000 or 2% of turnover from business activity in the preceding financial year, whichever is higher, and may not be lower than PLN 20,000 (Article 73(3)). For an important entity the ceiling is EUR 7,000,000 or 1.4% of turnover, with a floor of PLN 15,000 (paragraph 4). Where the breach causes a direct and serious cyber threat to defence, state security, public order or human life and health, the competent authority imposes a penalty of up to PLN 100,000,000 (paragraph 5).
Those figures impress on a slide and change little, because no board plans a breach. The real cost surfaces elsewhere — in the twentieth hour of an incident, when it turns out nobody knows which sectoral CSIRT is competent, the account in the ICT system under Article 46(1) was never created, and the person meant to create it never produced the criminal record information and formally should not have held those tasks. The 24-hour deadline runs from detection and does not pause while you work out who does what.
One thing protects against that, and it is not a certificate: a rehearsed notification path with names assigned, thresholds written in and the channel tested. Building it takes weeks. Discovering its absence during an incident takes minutes and costs far more.
What does ISO 27001 genuinely deliver on the road to NIS2?
It delivers the scaffolding — a real, measurable saving, not a consolation prize. An organisation with a working management system already has what is most expensive in implementing statutory duties: a risk assessment process, documentation discipline, the habit of collecting evidence, a rhythm of management reviews and internal audits, assigned roles. It adds a layer to an existing structure rather than starting from zero.
That is why two claims which look contradictory are in fact about two different things. Our guide to mapping NIS2 onto ISO 27001 and NIST shows that mapping onto recognised standards accelerates and lowers the cost of reaching compliance — the truth about effort. This article says that mapping does not exhaust the scope of obligations — the truth about the catalogue of requirements. The first answers “how long will this take”, the second “is this everything”. Answering only one leads astray: without the first you overpay, without the second you never finish.
To head off over-reading: “ISO 27001 is not enough” does not mean “ISO 27001 does not help”.
How do you tell a scope gap from an implementation gap?
The distinction is practical: the two gaps demand different work and different money. An implementation gap is where the standard supplies a mechanism you have not switched on, or switched on too narrowly — you fix it inside the existing management system. A scope gap is where the mechanism is absent from the standard altogether, because the obligation originates in a legal provision — you fix it by building a new element and giving it an owner. Mistaking one for the other ends in another internal audit cycle instead of an organisational decision.
The table organises the cases we most often see when reviewing documentation at certified entities approaching their statutory duties.
| Duty under the national act | Does ISO 27001 supply a mechanism? | What the standard leaves unsettled | Gap type | What must be added |
|---|---|---|---|---|
| Event categorisation and classification decision | Yes — assessment and decision process | Threshold values for the sector | scope | Thresholds from the regulation applicable to the entity, written into the procedure |
| Early warning within 24 h (Art. 11(1)(4)) | Partly — contact with authorities | Addressee, clock, channel, six content elements | scope | Identified sectoral CSIRT, account in the Art. 46(1) system, notification template |
| Final report within one month (Art. 11(1)(4c)) | Yes — post-incident analysis | Deadline counted from notification, required content | implementation | Extending the post-incident report with Art. 12a elements and tracking the deadline |
| Criminal record verification (Art. 8f) | Partly — candidate screening | Instrument, catalogue of offences, point of admission | scope | Procedure for obtaining the register information before admission to duties |
| Annual training for the head of the entity (Art. 8e) | Partly — awareness and competence | Named individual, frequency, proof of attendance | scope | Annual board training cycle with documented attendance |
| Personal accountability of the head of the entity (Art. 8c) | Partly — roles and responsibilities | Effect for collective bodies, persistence despite delegation | scope | Resolution designating the responsible person, or conscious acceptance of collective accountability |
| Informing users about an incident (Art. 11(2b)) | Partly — communication plan | The statutory criterion that triggers the duty | scope | Decision criterion and pre-drafted messages in the crisis plan |
| Evidence of control effectiveness | Yes — internal audit and reviews | — | implementation | Usually nothing; extending scope to the systems in the regulated service suffices |
The conclusion is uncomfortable but useful: most of the difference between a certificate and compliance consists of scope gaps, not implementation gaps. No better internal audit or wider certification scope removes them, because they concern matters the standard does not regulate by design. They require a decision, a name and an entry in a procedure.
Where do you start if you hold ISO 27001 and are unsure about NIS2?
Start by establishing your own status; everything downstream depends on it. Check whether you are a key or an important entity, and whether you fall within the catalogue in Article 8b(1) — that settles whether your source of technical requirements is Regulation 2024/2690 with the ENISA guidance, or an entirely different act. This one step eliminates the most expensive error we see: reproducing a document that does not apply to the entity.
Then, in this order: identify the competent sectoral CSIRT, open an account in the ICT system under Article 46(1) and run a test notification through it. Write the thresholds for treating an incident as significant into your categorisation scheme — as numerical values in the procedure, not as a cross-reference to a provision. Settle the accountability under Article 8c by name and plan the annual training cycle under Article 8e together with how attendance will be documented. At the end — and only at the end — line up the evidence you already hold against the statutory duties. That is when you see how much of it can genuinely be reused, and it is usually more than you expect.
If you would like that map drawn faster and from outside, we deliver both variants as a service. A NIS2 readiness check answers where you stand and what is missing — split into scope and implementation gaps, in the logic of the table above. NIS2 compliance implementation takes that diagnosis through to a working notification path, assigned accountabilities and documentation fit for a supervisory authority.
Key takeaway: ISO 27001 gives you scaffolding and genuinely shortens the road, but NIS2 compliance is settled in places the standard does not describe — at thresholds, deadlines, addressees and names. Start by establishing your entity’s status, not with a control crosswalk.
Sources:
- ENISA, Technical implementation guidance on cybersecurity risk-management measures, version 1.0, June 2025 — p. 2 (entities covered), p. 7 (audience and character of the document), pp. 9-10 (list of standards, reservations), p. 33 (incident categorisation criteria), p. 168 (glossary).
- Act of 5 July 2018 on the National Cybersecurity System (Journal of Laws 2018, item 1560; consolidated text Journal of Laws 2026, item 20), as amended by the Act of 23 January 2026 amending the National Cybersecurity System Act and certain other acts (Journal of Laws 2026, item 252, in force since 3 April 2026).
- Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements of cybersecurity risk-management measures.
- Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 (NIS2) — Article 21(2) and (5), Article 23(11).
