Building an ISMS under NIS2: 10-Week Plan for SMEs

1. Legal basis: NIS2 vs. ISO 27001

NIS2 does not require a certified ISMS, but a result: § 30(1) BSIG obliges particularly important entities and important entities to take appropriate, proportionate and effective technical and organisational measures in order to avoid disruptions to the availability, integrity and confidentiality of their IT systems and to keep the impact of security incidents small — and compliance must be documented. § 30(2) sentence 1 BSIG adds to the benchmark: the measures should comply with the state of the art, take the relevant European and international standards into account, and must be based on an all-hazards approach. An ISMS is the established way of producing this result in a traceable and auditable manner.

How far does an existing certificate take you? ISO 27001 addresses the requirements of Section 30 BSIG structurally in all ten areas, but is congruent with them in none. The typical gaps lie in three places: the NIS2 reporting obligations of 24 hours / 72 hours / one month (§ 32 BSIG), supply chain due diligence (§ 30(2) no. 4 BSIG) and the obligations of the management body (Section 38 BSIG); sector-specific particularities are added to this. So those who are certified do not build a new ISMS, but add targeted elements — those who are not certified build the structure along the ten areas of § 30(2) BSIG and decide on certification later. Practice recommendation: build an ISO 27001-compliant ISMS, certification optional.

Who is subject to the ISMS obligation

As a rule, § 28 BSIG ties in with two things at once: the type of entity under Annex 1 or Annex 2 and the size — in addition, the provision covers certain types of entity regardless of size (first and fourth row of the table). Two points are regularly overlooked in this context. First, turnover alone is not sufficient: the turnover threshold only takes effect together with the balance sheet total; the only independent criterion is the number of employees. Second, there is no upper employee limit for important entities — a large company that can only be assigned to a type of entity in Annex 2 remains an important entity and does indeed fall within the scope. Recommendation 2003/361/EC applies to the calculation of the number of employees, annual turnover and balance sheet total, with the exception of Art. 3(4) of its Annex (§ 28(4) BSIG).

Legal situation in Austria: The NISG 2026 was promulgated on 23 December 2025 (BGBl. I Nr. 94/2025) and, under § 51(1) and (2) NISG 2026, becomes applicable on 1 October 2026 — so not yet as at the date of this article. In Austria, the NIS2 Directive is implemented not through the BSIG but through the NISG 2026. The BSIG sections mentioned here have the following Austrian counterparts: risk management measures (10 items, (a)–(j)) § 32 NISG instead of Section 30 BSIG, responsibility of the management bodies § 31 NISG instead of Section 38 BSIG, fines § 45 NISG instead of § 65 BSIG (amounts and tiers in the FAQ on the risk of fines), evidence of effectiveness § 33 NISG (self-declaration) instead of § 39 BSIG. The competent supervisory body is the Cybersecurity Authority (Cybersicherheitsbehörde, Austria) (not the Federal Office for Information Security (BSI)) — the Federal Office for Cybersecurity, directly subordinate to the Federal Minister of the Interior, seated in Vienna (§ 3a(1) and (2), § 3b(3) NISG 2026).

2. Defining the ISMS scope

The scope determines which processes, sites, systems and companies the ISMS covers — and is therefore the reference value for proportionality under § 30(1) BSIG; compliance with the obligation to take measures must be documented under the same provision. In practice, what is left outside therefore also belongs in the scope description, together with a justification. The scope is not the same as being in scope of the law: whether you fall under NIS2 is decided by § 28 BSIG via the type of entity, size and the special cases covered regardless of size (section 1); the scope decides how far your protective measures reach.

Defining the scope:

• Which processes: all / only critical ones / specific ones — at a minimum, the services through which you fall under a type of entity in Annex 1 or Annex 2 belong in it. If the scope is drawn more narrowly than the regulated activity, the evidence gap arises precisely at that activity.
• Which sites — including data centres, production sites and home office workplaces. The site co-determines which physical measures (policy 12) and which emergency scenarios (§ 30(2) no. 3 BSIG) need to be regulated.
• Which IT systems — § 30(1) BSIG targets the availability, integrity and confidentiality of IT systems; the system list is therefore not busywork, but the reference value for the risk analysis, the authorisation concept and the backup strategy. SaaS services procured by business units themselves also belong in it.
• Which subsidiaries — if a subsidiary is itself a particularly important entity or an important entity, the obligation applies to it in its own right. The parent company can specify a central ISMS policy and central measures; the subsidiary implements them operationally. Contracts and delegation chains should be documented. Registration is separate: in Germany via the joint registration facility of the Federal Office for Information Security (BSI) and the Federal Office of Civil Protection and Disaster Assistance (BBK) (§ 33(1) BSIG), in Austria from 1 October 2026 with the Cybersecurity Authority (Cybersicherheitsbehörde, Austria) (§ 29(2) NISG 2026).

Recommendation for SMEs subject to NIS2: put the entire company in scope. Two reasons speak for this: first, you spare yourself the recurring demarcation discussion with every new system; second, registration requires the relevant sector under Annex 1 or 2 to be stated in any case (§ 33(1) BSIG) — registration details and scope description should describe the same reality.

3. Risk analysis + treatment plan

The risk analysis comes first in the catalogue of measures: § 30(2) no. 1 BSIG requires concepts for risk analysis and for information technology security; in Austria, the corresponding content is found in § 32(4)(a) NISG 2026 (applicable from 1 October 2026). At the same time, it provides the justification for the fact that not every one of the ten areas of measures has to be implemented to the same depth — what is required under § 30(1) BSIG are appropriate, proportionate and effective measures, and the risk analysis shows where the priorities lie. An online shop will typically prioritise authentication and access control, a mechanical engineering company the supply chain.

1. Asset Inventory: all IT assets, data classes, business processes. Without a complete inventory, proportionality cannot be demonstrated — the Asset Inventory therefore comes at the beginning and is not an accessory.
2. Threat Analysis: typical threats per asset (ransomware, data breach, outage). ISO 27005 is widely used in practice as a methodological framework; what matters is that the methodology is documented and repeatable.
3. Vulnerability assessment: current level of protection. This is where the link to area 5 (security in acquisition, development and maintenance) becomes visible: open vulnerabilities without a patch path are a risk, not a leftover item.
4. Risk score: likelihood of occurrence × extent of damage. Define the scale and the acceptance threshold in advance and have both approved by the management body — implementing the measures is its task under § 38(1) BSIG.
5. Treatment options: reduce / accept / transfer / avoid. Every decision needs an owner and a date; accepted risks additionally need a documented justification.
6. Statement of Applicability (SoA): which controls are applicable. The SoA comes from the ISO world, but at the same time contributes to the documentation required under § 30(1) BSIG: it shows which measure follows from which risk — and which does not, and why.

Practice recommendation on the cycle: the risk analysis is not a one-off product. An annual run plus an event-driven update for new systems, new suppliers or after an incident has proven itself — this cycle is a practice recommendation, not a statutory deadline.

4. Policies and concepts for all ten areas

The following policies are the set of rules with which the ISMS translates the ten areas of measures of § 30(2) BSIG into verifiable requirements. The following mapping is a practice grid: the law names areas of measures, not policy names — you decide which document covers which area. For Austria, the substantively corresponding catalogue is found in the same order in § 32(4)(a) to (j) NISG 2026 (applicable from 1 October 2026). Which content sits behind which number is listed in the FAQ 'Does the ISMS have to cover all ten areas of measures of Section 30 BSIG?'.

1. Information Security Policy (top level) — scope of application, security objectives, roles and approval by the management body; the document to which all further policies refer. § 30(2) no. 1 BSIG
2. Acceptable Use Policy — what employees may and may not do with devices, accounts and data; the rule that training and sanctions later rely on. § 30(2) no. 7 BSIG
3. Access Control Policy — authorisation concept on a need-to-know basis, role model, regular recertification of rights, onboarding and offboarding workflow. § 30(2) no. 9 BSIG
4. Cryptographic Controls Policy — requirements for data in transit (TLS 1.3 under BSI TR-02102), data at rest (AES-256 for storage media and backups), email security and key management. § 30(2) no. 8 BSIG
5. Backup + Recovery Policy — backup strategy based on the 3-2-1 principle or equivalent, RTO and RPO per business process, tested restore routine. § 30(2) no. 3 BSIG
6. Patch Management Policy — deadlines per criticality level, exception procedure and connection to vulnerability management (CVD process). § 30(2) no. 5 BSIG
7. Incident Management Policy — detection, classification, escalation and the reporting templates for 24 hours / 72 hours / one month under § 32(1) BSIG. § 30(2) no. 2 BSIG
8. Supplier Management Policy — supplier assessment with risk classification, cybersecurity clauses in standard contracts, right to audit for critical suppliers, the supplier's obligation to report incidents to you. § 30(2) no. 4 BSIG
9. Mobile Device + BYOD Policy — management, encryption and separation of private and business use on mobile devices. § 30(2) no. 9 BSIG
10. Clear Desk + Clear Screen Policy — handling of paper, screen locking and meeting rooms; the rule can be checked on a sample basis without tools and is therefore well suited as an entry point into measuring effectiveness. § 30(2) no. 7 BSIG
11. Password Policy — requirements for authentication, flanked by MFA — § 30(2) no. 10 BSIG requires multi-factor authentication or continuous authentication; MFA for all administrative and external access is a common practice recommendation. § 30(2) no. 10 BSIG
12. Physical Security Policy — access, visitor rules, protection of server rooms and archives; the physical side of personnel security and access control. § 30(2) no. 9 BSIG

For area 6 — assessing the effectiveness of the risk management measures — this list deliberately does not provide a separate policy: it is not covered by a code of conduct, but by the documented concepts and procedures of the audit and review level described in section 5 — § 30(2) no. 6 BSIG nevertheless requires concepts and procedures; the documentation of compliance follows from § 30(1) BSIG. In addition, every policy needs three items of information so that it holds up in an audit: a named responsible role, an approval date by the management body and a version number.

5. Internal audit + management review

Internal audit and management review are ISO 27001 practice on an annual rhythm, not a NIS2 obligation: § 30(2) no. 6 BSIG requires 'concepts and procedures for assessing the effectiveness of risk management measures', but no frequency — the only statutorily timed item is the evidence rhythm for operators of critical installations under § 39(1) BSIG (every three years); the remaining statutory deadlines are set out in the overview in section 6.

• Annual internal audit: the complete ISMS scope, by an independent internal or external auditor; ISO/IEC 27001:2022 requires internal audits 'at planned intervals'.
• Annual management review (likewise ISO practice): the management reviews the audit report, incidents and changes in risk
• Continuous improvement: CAPA process (corrective + preventive actions) — every audit finding, every incident and every metric below the defined threshold generates an entry with cause, measure, responsible role and deadline; the status is tracked in the management review. Evidence that findings have been worked off is the practical proof for the effectiveness assessment under § 30(2) no. 6 BSIG.

What the law actually requires: A statutorily timed evidence rhythm exists only for operators of critical installations; it is provided through security audits, reviews or certifications at a point in time determined by the Federal Office for Information Security (BSI) (§ 39(1) BSIG) — deadline and trigger in the deadlines table in section 6. For all other particularly important entities and important entities, there is no statutorily prescribed audit frequency.

How effectiveness becomes measurable: An audit report alone does not answer the question of effectiveness. What has proven itself in practice are metrics per area of measures — such as patch compliance rate, phishing click rate and actually measured recovery time —, quarterly reporting to the management body, an annual penetration test and an external audit every two years. All four rhythms are practice recommendations, not deadlines from Section 30 BSIG. However, they contribute directly to three gaps that experience shows are frequently objected to in audit practice (practice assessment): supply chain security (§ 30(2) no. 4 BSIG), missing documented metrics for the effectiveness assessment (no. 6) and a missing phishing simulation in the area of training and awareness (no. 7).

Who is responsible for the review: The management review is not something that can be delegated. § 38(1) BSIG obliges the management body to implement the risk management measures under Section 30 BSIG and to supervise their implementation; § 38(3) BSIG additionally requires its regular participation in training. In practical terms this means: a review record with date, participants, decisions and deadlines, approved by the management body.

Legal situation in Austria: The NISG 2026 likewise contains no annual audit obligation. Instead of audit evidence, there is the self-declaration to the Cybersecurity Authority (Cybersicherheitsbehörde, Austria) (§ 33(1) NISG); evidence provided by an independent body is only to be furnished upon request (§ 33(2) NISG) — deadlines and start of application in the deadlines table in section 6. The responsibility of the management bodies is governed by § 31(1) and (2) NISG 2026: to ensure and supervise, plus participation in specifically designed cybersecurity training and the regular provision of training to employees.

6. 10-week roadmap

The roadmap spreads the ISMS build over ten weeks, at the end of each of which there is an auditable artefact — the rhythm itself is a practice recommendation, not a statutory deadline: the law specifies content — the ten areas of measures of § 30(2) BSIG — as well as the deadlines from the overview that follows; spreading the build work over ten weeks is a planning recommendation. The plan is cut in such a way that these artefacts can be presented in an audit; compliance with the measures must be documented under § 30(1) BSIG in any case.

Week 8 extends beyond the project period: in practice, awareness training is repeated annually, new joiners usually receive the onboarding module within the first four weeks, and a quarterly phishing simulation with an evaluation of the click rate supplies the metric for area 6. These, too, are practice rhythms — § 30(2) no. 7 BSIG requires basic training and awareness measures without naming a frequency.

Statutory deadlines run in parallel — independently of the project plan

The statutory dates run independently of the project plan and do not shift merely because the ISMS project is still running; the last two rows are practice rhythms included for comparison.

What the plan delivers — and what comes afterwards

After ten weeks, the framework is in place: approved scope, asset inventory and risk register, treatment plan with SoA, the policy set put into force, training records, audit report and review record. What is still missing afterwards is the technical and contractual depth in the ten areas of measures — MFA rollout, cryptography migration, cybersecurity clauses in supplier contracts, tested restore. This second stage only becomes plannable with the risk treatment plan from week 4, because only there is it established which measure follows from which risk. Empirical values on duration are set out in the FAQ.