TOM Basic Package for SMEs: 12 Minimum Measures

Main article: TOM Art. 32 GDPR checklist — it covers 14 typical TOMs for SMEs and the risk-based standard of Art. 32 GDPR; this article covers the twelve measures of the basic package.

The twelve measures are numbered as before. Each point now states three things: what exactly needs to be done, why — with the legal source —, and whether it is a legal obligation or a practice recommendation. Two clarifications up front. First: product names and effort figures in this article come from the first edition (as at: 2 May 2026), are carried over unchanged and have not been re-surveyed for this update; the article states prices not as amounts but through their cost drivers (see FAQ). Second: all sources from the BSIG and the NISG 2026 apply only to entities that fall within the scope of the NIS2 implementation — the next section clarifies who that is. The data protection layer applies regardless.

Practice recommendation on sequence: Start with points 1, 2, 3, 4 and 7 — the five measures the TL;DR names as the top 5 (MFA, encryption, patch management, backup, role concept). Under the mapping table they are assigned to five different areas out of the ten catalogue areas, and for two of them the data protection case pattern leads directly to a notifiable case under Art. 33 GDPR: the loss of an unencrypted data carrier (point 2) and a hardware failure with data loss (point 4). The sequence is a practice recommendation, not a statutory order of priority.

Legal framework: what is mandatory — and for whom

For this package of measures there are two mandatory layers and one voluntary guidance layer. The data protection layer is the broader one: Art. 32(1) GDPR is directly binding; the outcome is documented in the record of processing activities, because every processing activity must include, where possible, a general description of the technical and organisational measures (Art. 30(1)(g) GDPR), and for data processors, where possible, a general description of the measures under Art. 32(1) (Art. 30(2)(d) GDPR). What makes sense here is not a separate TOM per processing activity, but a reference to a central TOM concept.

The second layer is the NIS2 implementation. As a rule it applies where two conditions are met: the entity must be attributable to an entity type in the relevant annex and must additionally meet the size threshold. Certain types are covered regardless of this — in Germany, among others, operators of critical installations, qualified trust service providers, top-level domain name registries and DNS service providers (§ 28(1) BSIG), and in Austria correspondingly § 24 NISG 2026. For determining size, Recommendation 2003/361/EC is authoritative, without Art. 3(4) of its annex; Austria expressly refers to Art. 1 to 6 of that annex (§ 25 NISG 2026). The thresholds are therefore not to be calculated using your own counting method, but according to the concept of an enterprise set out in the annex — before classifying, clarify which units your organisation has to include on that basis.

The third layer is voluntary: BSI IT-Grundschutz and ISO 27001 are voluntary reference frameworks; they can support the adequacy decision under Art. 32(1) GDPR, but are not themselves a mandatory source. This article does not address their individual requirements. Practice recommendation: Anyone who structures their TOM concept along one of the two catalogues thereby also has a structure for the documentation under § 30(1) BSIG and for the self-declaration under § 33(1) NISG 2026.

Check whether you are affected in this order. First, the entity type: Annexes 1 and 2 form part of the BSIG and of the NISG 2026 respectively. Annex 1 lists the sectors of high criticality — in Germany energy, transport, finance (banking and financial market infrastructures), health, water (drinking water and waste water), digital infrastructure including the management of ICT services, and space. Annex 2 lists the other critical sectors: postal and courier services, waste management, manufacture and trade of chemical substances, production, processing and distribution of food, manufacturing, digital service providers and research. Austria lists the same sectors in § 2 and in Annexes 1 and 2 of the NISG 2026; there, public administration belongs to Annex 1, whereas in Germany the federal administration is covered separately under § 29 BSIG. Second, the size threshold in accordance with the relevant row of the following overview. All rows are statutory classification and procedural rules; the Austrian entries are applicable from 1 October 2026 (see below):

In terms of timing: the German NIS2UmsuCG has been in force since 6 December 2025; the Austrian NISG 2026 (BGBl. I No. 94/2025) is applied from 1 October 2026 — this date is based on the account given in the sister article on NIS2 in Austria, not on an official transitional provision cited here. The European reference point for both implementations is Art. 21(1) and (2) of the NIS2 Directive.

Which NIS2 areas the twelve measures cover

The twelve measures cover eight of the ten areas of the statutory minimum catalogue in full or in part; two areas remain without a counterpart and — for entities within the NIS2 scope — must additionally be set up. The mapping is this article's editorial reading, not an official mapping — the legal source is stated in the header row and with each measure.

This article does not assign measures 6 (firewall and segmentation) and 11 (physical security) to any single catalogue item; here they rest on the general clause of § 30(1) BSIG and § 32(1) NISG 2026 respectively. For entities within the NIS2 scope this means: the twelve measures are the working list, not the complete catalogue of obligations.

For the two fully open areas you need two separate documents: a risk analysis and security concept, and a procedure for assessing effectiveness with a documented result. Neither is part of this package of measures — the requirements for them are set out in Section 30 BSIG: 10 mandatory measures and Building an ISMS. You close the four partly open areas with supplements: acquisition and development requirements alongside point 3, further cyber hygiene measures alongside point 5, secured communications alongside point 1, human resources security alongside point 7.

1. MFA everywhere

Practice recommendation: Multi-factor authentication on every access from outside and on every administrator account. Microsoft Authenticator + FIDO2 keys for admins. Costs depend mainly on whether existing licences already include MFA and how many hardware keys are needed.

Why: Catalogue area: multi-factor authentication and secured communications (row 10 of the mapping table) — partly open there, because this point covers only authentication; secured communications must be regulated in addition. Multi-factor authentication is expressly named in the statutory minimum catalogue of risk management measures — in Germany in § 30(2) BSIG, in Austria in § 32(4) NISG 2026, at European level in Art. 21(2) of the NIS2 Directive. What is named in law is therefore the area of measures; the degree of coverage — every remote access and every administrator account — is a practice recommendation.

Practice recommendation on sequence: privileged accounts first, then all remote access, then the remaining accounts. Record the degree of coverage per account type with a date — that is the evidence that supports the documentation under § 30(1) BSIG.

Sources: § 30(2) BSIG (DE) § 32(4) NISG 2026 (AT) Art. 21(2) NIS2 Directive

2. Encryption at rest and in transit

Encrypt data at rest on all end devices and data carriers, and the entire transport layer. What is named in law is the area of measures; the degree of coverage described here is a practice recommendation. BitLocker on all end devices, TLS 1.3 for all web connections.

Why: Catalogue area: cryptography and encryption (row 8 of the mapping table) — fully covered there by this point. The second effect, underestimated in day-to-day practice, lies in data protection law: under Art. 34(3) GDPR, notification of the data subjects is not required where appropriate technical and organisational protection measures — in particular encryption — were applied. That only works as long as the key has not been compromised along with the data. Notification of the supervisory authority is governed independently of this by Art. 33(1) GDPR; it is dispensed with only where the breach is unlikely to result in a risk to the rights and freedoms of natural persons.

Practice recommendation: Keep keys and recovery keys separate from the encrypted data and document where they are kept — otherwise, in an emergency, encryption becomes an availability problem of your own making (see point 4).

Sources: § 30(2) BSIG (DE) § 32(4) NISG 2026 (AT) Art. 21(2) NIS2 Directive Art. 34(1) and (3) GDPR Art. 33(1) GDPR

3. Patch management

Patch on a fixed cycle and handle critical vulnerabilities outside that cycle. The cycle and the response time are practice recommendations, not a statutory deadline; what the law requires is vulnerability management as such. Microsoft Defender for Endpoint, monthly patch cycles, critical patches within 72 hours.

Why: Catalogue area: acquisition, development and maintenance, including vulnerability management (row 5 of the mapping table) — partly open there, because this point covers only maintenance.

Practice cycle: The monthly cycle and the 72-hour handling of critical patches are practice cycles from the first edition of this article; the deadlines in this article that are backed by law are set out in the tables under evidence and notification. The prerequisite for both is an up-to-date asset inventory: what is not inventoried does not get patched. In addition, set out in writing who classifies a vulnerability as critical, and on what criterion, thereby triggering the shortened cycle; without that determination the 72-hour handling cannot be evidenced and the exception list cannot be reviewed. Record exceptions with a reason and a follow-up date.

Sources: Art. 21(2) NIS2 Directive § 30(2) BSIG (DE) § 32(4) NISG 2026 (AT)

4. 3-2-1 backup + immutable

Keep three copies of your data on two different media types, one of them off site, and protect at least one copy against subsequent modification (immutable) — and test the restore, not just the backup. The 3-2-1 scheme is a practice recommendation, not a statutory requirement; what the law requires is backup management as such. Veeam with a hardened repository, quarterly restore tests.

Why: Catalogue area: business continuity with backup management and crisis management (row 3 of the mapping table) — covered there together with point 10. The general clause of § 30(1) BSIG expressly names disruptions to availability as well — not just to confidentiality. In data protection law the same case counts: a hardware failure with data loss is in practice notified as an availability breach under Art. 33 GDPR.

Practice cycle: The quarterly restore test is a practice recommendation from the first edition. For each test, log the date, the volume of data restored and the time required — the time required is the only solid basis for your recovery planning.

Sources: § 30(1) and (2) BSIG (DE) § 32(1) and (4) NISG 2026 (AT) Art. 21(2) NIS2 Directive Art. 33(1) GDPR

5. Anti-malware

Run malware protection on all end devices and servers under central management, not as an individual installation per device. What is named in law is the area of measures; the degree of coverage described here is a practice recommendation. Microsoft Defender for Endpoint (included in M365 E5) or Bitdefender, Sophos.

Why: Catalogue area: cyber hygiene and cybersecurity training (row 7 of the mapping table) — covered there together with point 9, and otherwise partly open: further cyber hygiene measures beyond malware protection and training must be regulated in addition. Central management is therefore not a convenience feature: without it the degree of coverage cannot be documented, and § 30(1) BSIG expressly requires documentation of implementation.

Practice recommendation: Reconcile the console regularly against the asset inventory from point 3. The typical gaps are always the same: privately owned devices brought in by staff, servers outside standard management, and legacy systems nobody looks after any more.

Sources: Art. 21(2) NIS2 Directive § 30(1) and (2) BSIG (DE) § 32(4) NISG 2026 (AT)

6. Firewall + segmentation

Set the firewall to default deny and divide the network into zones so that a compromised segment does not take the entire company with it. Firewall with default deny, network segments office/production/backup.

Why: The hook here is the general clause, not a single catalogue item: § 30(1) BSIG requires appropriate, proportionate and effective technical and organisational measures to avoid disruptions to the availability, integrity and confidentiality of information technology systems and to keep the impact of security incidents small. § 32(1) NISG 2026 formulates the same obligation as reducing the risks to network and information systems, and Art. 21(1) and (2) of the NIS2 Directive as managing those risks on an all-hazards basis.

Practice recommendation: The specific zoning is the practical implementation of this general clause. Keep the backup network strictly separate from the office network — otherwise point 4 loses its effect in an emergency. Justify every rule set release with its purpose, the requester and the date.

Sources: § 30(1) BSIG (DE) § 32(1) NISG 2026 (AT) Art. 21(1) and (2) NIS2 Directive

7. Access control (RBAC)

Assign rights via roles rather than via persons, and only as far as the task requires. Microsoft Entra ID + Conditional Access, need-to-know principle.

Why: Catalogue area: human resources security and access control policies (row 9 of the mapping table) — partly open there, because this point covers access control but touches on human resources security (including suitability and exit processes) only at the margins. In data protection law the access question continues with service providers — the requirements for data processors under Art. 28 GDPR are set out in point 12.

Austria: In addition, the data secrecy obligation under § 6 DSG applies — controllers, data processors and their employees are bound to secrecy. Practice recommendation: document the commitment to data secrecy in the same onboarding step as the assignment of roles.

Practice recommendation: Maintain a role matrix per business unit, tie the withdrawal of rights firmly to the exit process, and recertify privileged roles at least at every full audit and whenever a role changes; file the result with the date and the person who carried out the review.

Sources: § 30(2) BSIG (DE) § 32(4) NISG 2026 (AT) Art. 21(2) NIS2 Directive Art. 28(1) GDPR § 6 DSG (AT)

8. Logging + monitoring

Log security-relevant events centrally and raise alerts on critical patterns — logs are the basis of every notification decision. Microsoft Sentinel or the ELK stack, 90 days' retention, 24/7 alerting on critical events.

Why: Catalogue area: incident handling (row 2 of the mapping table) — covered there together with point 10. In practice this is where it is decided whether you can meet the deadlines from the notification section at all: the notification with an initial assessment within 72 hours (§ 32(1) no. 2 BSIG; § 34(2) no. 2 NISG 2026) and the information required under Art. 33(3) GDPR — the approximate number of data subjects and records, the categories of data, the likely consequences — cannot be produced reliably without logs.

Practice cycle: The 90 days' retention is a figure from the first edition. Align the retention period for logs with the erasure periods in the record of processing activities so that both documents make the same statement.

Sources: § 30(2) BSIG (DE) § 32(4) NISG 2026 (AT) Art. 21(2) NIS2 Directive Art. 33(3) GDPR

9. Training + awareness

Train all staff on a recurring basis — and the management body must take part. Annual mandatory training + quarterly phishing simulation.

Why: Within the NIS2 scope, the management body's participation in training is a personal obligation — expressly regulated in Germany, in Austria and at European level; it applies to the management itself, not just to the workforce. In Austria, specifically designed cybersecurity training is provided for the management bodies; comparable training is to be offered to employees on a regular basis. Catalogue area: cyber hygiene and cybersecurity training (row 7 of the mapping table) — covered there together with point 5.

Austria: The commitment to data secrecy (§ 6 DSG, see point 7) can be combined with the same session — a practice recommendation.

Practice cycle: What is backed by law is the management body's obligation to take part in training — in Germany to take part regularly (§ 38(3) BSIG), in Austria to take part in specifically designed cybersecurity training (§ 31(2) NISG 2026); the specific cadence — annual mandatory training, quarterly phishing simulation — comes from the first edition of this article and is a practice recommendation. Record proof of participation with the date and a list of topics, kept separately for the management body and the workforce.

Sources: § 38(3) BSIG (DE) § 31(2) NISG 2026 (AT) Art. 20(1) and (2) NIS2 Directive § 6 DSG (AT)

10. Incident response plan

Determine in advance who decides, who notifies and whom — because the deadlines run from the moment you become aware, not from the moment the matter is fully clarified. Crisis team, escalation paths, annual tabletop exercise.

Why: Incident handling forms part of the minimum catalogue. What matters is when the deadline starts: the 72-hour deadline in Art. 33(1) GDPR runs from the point at which the controller became aware of the breach — not only after the internal assessment has been completed. Where notification is made later, it must be accompanied by reasons for the delay. Within the NIS2 scope, the three-stage scheme from the notification section applies in addition.

Practice recommendation for the process: detection and activation of the crisis team within the first two hours; containment and initial forensics by hour 8; classification of the categories of data affected, the numbers and the risk by hour 24; drafting of the data protection notification and coordination with the management by hour 48; sending it and documenting the confirmation by hour 72; preparing the information to data subjects in parallel. The annual tabletop exercise is likewise a practice recommendation. To be distinguished from this: within the NIS2 scope a statutory deadline applies here — the first notification stage is due at the latest 24 hours after becoming aware, in Germany as an early initial notification to the joint reporting office of the BSI and the BBK (§ 32(1) no. 1 BSIG), in Austria as an early warning to the competent CSIRT (§ 34(2) no. 1 NISG 2026). The other hour figures in this paragraph are practice recommendations.

Who notifies what: The notification under Art. 33 GDPR goes to the data protection supervisory authority — in Germany, for non-public bodies, to the authority competent under the law of the relevant federal state (§ 40(1) BDSG), in Austria to the Austrian Data Protection Authority (§ 18(1) DSG). The NIS2 notification goes to the joint reporting office of the BSI and the BBK (§ 32(1) BSIG) or to the competent CSIRT (§ 34(2) NISG 2026). Set out both responsibilities, including deputies, in advance in the crisis team, otherwise the question will be settled during the incident itself.

Sources: Art. 33(1) GDPR § 32(1) BSIG (DE) § 34(2) NISG 2026 (AT) § 40(1) BDSG (DE) § 18(1) DSG (AT)

11. Physical security

Secure rooms and devices physically — the best cryptographic key is no help against a server room left standing open. Access control, server rooms locked, visitors accompanied.

Why: The hook is the general clause from point 6 (§ 30(1) BSIG; § 32(1) NISG 2026). The consequences are measurable in data protection terms: the loss of an unencrypted data carrier and the theft of an unencrypted backup hard drive are classified in the case pattern as a high risk and then trigger both the notification under Art. 33 and the communication to the data subjects under Art. 34 GDPR — whereas with effective encryption the exception in Art. 34(3) GDPR applies (see point 2).

Austria — video surveillance: The DSG regulates image recording independently. § 12 DSG determines lawfulness; image recording for the purpose of monitoring employees is not permitted (§ 12(4) no. 2 DSG). § 13 DSG requires image recording to be signposted (subsection 5); retention lasting longer than 72 hours must be proportionate and must be separately logged and justified (subsection 3). Monitoring measures that affect human dignity require a works agreement (§ 96(1) no. 3 ArbVG).

Germany: For employee data, § 26 BDSG is the relevant national supplementary provision; for staff data it is in practice usually the legal basis that has to be named in the record of processing activities.

Sources: § 30(1) BSIG (DE) § 32(1) NISG 2026 (AT) § 12(4) no. 2 DSG (AT) § 13(3) and (5) DSG (AT) § 96(1) no. 3 ArbVG (AT) § 26 BDSG (DE)

12. Supplier audit

Check service providers before engaging them and on a recurring basis thereafter — and set the cooperation out in a contract. Audit the top 20 suppliers annually, data processing agreement with mandatory clauses.

Why: Catalogue area: supply chain security (row 4 of the mapping table) — covered there by this point alone. In data protection law, Art. 28(1) GDPR requires that you work only with data processors providing sufficient guarantees of appropriate technical and organisational measures. Under Art. 28(3) GDPR the contract has a prescribed minimum content: the subject matter and duration of the processing, the nature and purpose, the type of personal data, the categories of data subjects and the obligations and rights of the controller.

Practice cycle: The annual audit cadence for the 20 most important suppliers is a practice recommendation from the first edition. Every data processor also belongs in the record of processing activities with its recipient category; outdated recipient lists — old newsletter or analytics tools that were never removed — are a frequent audit finding.

Sources: § 30(2) BSIG (DE) § 32(4) NISG 2026 (AT) Art. 21(2) NIS2 Directive Art. 28(1) and (3) GDPR Art. 30(1) GDPR

Evidence and documentation: Germany and Austria separately

What is evidenced is not the intention but the implementation — and different rules apply in Germany and Austria. Germany requires all particularly important and important entities to document compliance, but requires regular evidence through audits, examinations or certifications primarily from operators of critical installations. Austria reverses the order: there, the starting point is a self-declaration for all essential and important entities, with evidence from an independent body following only upon request. All rows of the following table are statutory obligations; the Austrian rows are applicable from 1 October 2026 (see legal framework). The column "Applies to" names the respective addressees.

Governance: Responsibility sits at the top. In Germany, the management body of particularly important and important entities must implement the measures under Section 30 BSIG and monitor their implementation; if it breaches this duty, it is liable to its entity for culpably caused damage under the rules of the company law applicable to the legal form (§ 38(1) and (2) BSIG). Added to this is the personal obligation to take part in training regularly (§ 38(3) BSIG). In Austria, the management bodies must ensure and supervise compliance with the risk management measures under § 32 NISG 2026 and take part in specifically designed cybersecurity training (§ 31(1) and (2) NISG 2026).

Practice recommendation on filing: one valid version of the TOM concept with a version status and date, a change history, and one piece of evidence per measure — a console report, a test log, an attendance list, an audit report. The review cadence itself is a practice recommendation (see FAQ); what is backed by law are the deadlines in this table.

If a measure fails: notification and response deadlines

If a measure fails, two deadline systems run in parallel — that of the GDPR and, within the NIS2 scope, that of cybersecurity supervision. They are not mutually exclusive: a ransomware incident with data exfiltration can trigger both. All rows of the following table are statutory requirements; the Austrian entries based on the NISG 2026 are applicable from 1 October 2026 (see legal framework).

A security incident is significant — and therefore notifiable — if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity (Austria: severe financial loss), or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage (§ 2 no. 11 BSIG — unless a specifying statutory instrument under § 56(5) BSIG is issued; § 35(1) NISG 2026).

Sanctions framework: The fines framework applies to infringements of, among other things, the risk management and notification obligations and depends on the class of entity. In Germany up to EUR 10 million against particularly important entities and up to EUR 7 million against important entities; where total turnover exceeds EUR 500 million, by way of derogation up to 2 % or 1.4 % respectively of worldwide total turnover (§ 65(5) no. 1 as well as (6) and (7) BSIG). In Austria, for administrative offences under § 45(1) NISG 2026, up to EUR 10 million or 2 % for essential entities and up to EUR 7 million or 1.4 % for important entities, whichever amount is higher (§ 45(2) and (3) NISG 2026). In data protection law, infringements of the obligations in Art. 25 to 39 GDPR — which include Art. 32 — fall within the framework of Art. 83(4) GDPR: up to EUR 10 million or up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever amount is higher.