NIS2 Readiness: Why Cybersecurity Now Needs an Operating Model

The questionnaire arrives before the audit

An Austrian B2B supplier with 60 employees receives a plain email from its most important customer on a Tuesday morning. No formal audit date, no regulator, no panic. Just a supplier questionnaire: current system inventory, owners for critical applications, evidence of a tested backup, incident contact path, overview of key IT providers, and confirmation that management regularly reviews cybersecurity risk.

The company has not ignored security. It has Microsoft 365, an IT provider, a CRM, hosted backups, several n8n workflows, a password rule, and a security policy in SharePoint. Still, nobody can answer the questionnaire cleanly. The system list is outdated. The backup test was never documented. The incident contact path is not written as a runbook. The supplier list lives in finance, not IT. Management knows cybersecurity matters, but cannot see which evidence the operating model produces.

That is how NIS2 will first become visible for many SMEs: not as abstract legislation, but as customer pressure, supplier review, insurance friction, or incident urgency. Some companies are directly in scope; others are not. But almost every company working in digital supply chains needs to show that its digital machine is understood, maintained, and recoverable.

What NIS2 changes in practice

NIS2 is Directive (EU) 2022/2555. It replaced the first NIS Directive, expands cybersecurity expectations across more sectors, and requires essential and important entities to take appropriate and proportionate technical, operational, and organisational risk-management measures. This article is not legal advice and does not replace classification by counsel or the competent authority. It looks at NIS2 from an operating perspective: what evidence, routines, and ownership need to exist so readiness is more than paperwork?

The practical change is the combination of management responsibility, risk-management measures, supply-chain security, incident reporting logic, and continuous evidence. Article 20 requires management bodies of covered entities to approve cybersecurity risk-management measures, oversee their implementation, and follow training. Article 21 includes risk analysis, incident handling, business continuity, backup, crisis management, supply-chain security, secure acquisition and maintenance, effectiveness assessment, cyber hygiene, training, access control, asset management, and MFA where appropriate.

For SMEs, the important point is that the NIS2 question does not end with direct legal scope. The European Commission describes NIS2 as generally applying to medium-sized and large entities in covered sectors, with exceptions and special cases. At the same time, Article 21 explicitly includes the security of direct suppliers and service providers. That creates commercial pressure through the supply chain. A company may not be directly registered, but still receive a questionnaire from a larger customer that has to manage supplier risk.

Germany and Austria also show why cautious wording matters. Implementation is now national-law specific: Germany refers to its NIS2 implementation law and BSI registration routes, while Austria published NISG 2026 in BGBl. I Nr. 94/2025. Classification, responsible authorities, and deadlines should be checked with counsel or the competent authority. The operating foundation, however, remains the same: systems, owners, backups, suppliers, logs, runbooks, and reviews need to be reliable.

Why a policy alone is not enough

A policy is useful. It says what should happen. But NIS2 readiness is not created by placing a PDF in the right folder. It is created when the company can show what actually happens: who owns which system, who has admin access, when the last restore was tested, which supplier touches critical data, which alert triggers action, and who decides during an incident.

The distinction sounds simple, but it becomes large in daily operations. A policy can say that access is reviewed regularly. An operating model shows when the latest review happened, which accounts were removed, which exceptions were accepted, and who made the decision. A policy can require backups. An operating model shows the restore test, duration, data gap, responsible owner, and next improvement.

Many SMEs confuse documentation with evidence. The risk is not that nothing exists. The risk is that the facts are scattered: technical details with the provider, supplier contracts in finance, access decisions in emails, backup status at the hoster, incident knowledge in one person’s head. Under pressure, this has to become one reliable picture.

The cost of operational blindness

Operational blindness costs money long before a regulator asks questions. It costs time, trust, and decision quality. A customer delays approval because the supplier questionnaire is incomplete. A cyber insurer asks about restore tests, but nobody finds the evidence. An incident begins, and the team spends the first hours searching for systems, owners, and contact routes instead of containing the problem.

ENISA’s NIS Investments Report 2025 says organisations report difficulty with patching, business continuity, and supply-chain risk management. For SMEs, ENISA also points to the need for accessible guidance, affordable tools including managed and cloud services, and skills development. This matches SME reality: the problem is rarely lack of intent. It is the lack of a lightweight operating system.

The damage appears in several layers. First, delay: sales, operations, and management wait for answers that should come from the operating model. Second, rework: consultants, providers, and internal teams reconstruct facts that should already be documented. Third, incident risk: if the company does not know which systems are critical, which logs matter, and who reports, the NIS2 incident cadence becomes hard. For significant incidents, NIS2 sets an early warning within 24 hours, an incident notification within 72 hours, and a final report no later than one month after the incident notification. Without a runbook, that is not a form problem. It is a time problem.

Fourth, management friction increases. Leadership is responsible, but cannot see a clear operating view. Decisions then become either too defensive or too late: buy another tool, schedule another audit workshop, build another spreadsheet. That can calm the room briefly, but it does not create durable evidence.

The NIS2 Operations Map

Practical NIS2 readiness begins with an operations map. It is not a full legal classification and not a heavy GRC system. It is the operating view that shows which digital capabilities exist, who owns them, how they are controlled, and which evidence is produced in daily work.

What belongs on the map

The map should start with the systems that keep the business running: customer communication, CRM, billing, identity, hosting, automation, backups, monitoring, and the suppliers behind them. Each entry needs a business owner, a technical owner, a criticality level, a data class, and a simple evidence path. If a system cannot be assigned, restored, monitored, or explained, it belongs near the top of the gap list.

This is also where supply-chain pressure becomes practical. A provider is not just a vendor name in finance. It may host data, administer infrastructure, provide identity, trigger automations, or influence recovery. The map should show that dependency before a customer questionnaire or incident forces the company to reconstruct it.

The six layers are deliberately simple:

Layer	Operating question	Typical evidence
Asset inventory	Which systems, data flows, and automations are critical?	System list with owner, criticality, and data class
Identity and access	Who can do what, why, and until when?	Roles, MFA status, admin accounts, offboarding record
Backup and recovery	What can be restored, and has it been tested?	Restore test, RTO/RPO assumption, backup exception
Logging and monitoring	Which signals show business or security incidents?	Alert rule, log retention, incident ticket
Supplier register	Which providers are part of the risk?	Supplier list, security owner, contract or questionnaire status
Incident and runbook loop	Who reacts, communicates, reports, and learns?	Runbook, contact route, review note

This map translates NIS2 from a list of measures into a running operating model. It connects Article 21 topics such as risk management, incident handling, business continuity, supply-chain security, and effectiveness assessment to concrete work routines. It also keeps the ENISA pain points from becoming isolated workstreams: patching without an asset list is luck, business continuity without a restore test is hope, and supply-chain security without a register is memory.

Planfold frames this map through Plan -> Unfold -> Resonate. Plan means mapping assets, risks, suppliers, and owners. Unfold means building workflows, access controls, backup tests, monitoring, and automation into the digital machine. Resonate means feeding reviews, logs, restore tests, and incident learnings back into the system so readiness does not fade after the first workshop.

How the map becomes evidence

Evidence appears when each layer produces a routine output. The inventory has a review date. Access reviews leave a decision trail. Restore tests record duration, scope, and gaps. Monitoring alerts create tickets instead of disappearing into inboxes. Supplier checks have an owner and status. Incident runbooks are tested before the day they are needed.

That rhythm matters because NIS2 readiness is not one export. It is a repeatable operating pattern. A small, maintained map with monthly review notes is often more defensible than a large spreadsheet created once for an audit workshop and then abandoned.

Warning signs: where SMEs should look first

If you want to know whether your company looks NIS2-ready, do not start with a 120-point checklist. Start with daily warning signs. They show where operations and evidence are drifting apart.

The first warning sign is an outdated system inventory. If nobody can say within an hour which production systems, SaaS tools, automations, and providers are critical, every other measure becomes blurred. Patching, logging, backup, and access control depend on that foundation.

The second warning sign is shared or unclear admin access. NIS2 does not mention access control and asset management as decoration. If multiple people use the same account or provider accounts are not bounded, the trace you need under pressure is missing.

The third warning sign is a backup that is green but has never been restored. A green backup job is not recovery evidence. A small documented restore test is often more valuable than a large backup plan nobody has tried.

The fourth warning sign is monitoring without an owner. Dashboards, logs, and email alerts only help when it is clear who responds, when escalation happens, and which evidence remains. Without that ownership, the customer finds the failure first.

The fifth warning sign is a supplier register that is only commercial. For supply-chain security, it is not enough to know who sends invoices. You need a view of which provider influences which process, data set, and recovery capability.

Technical deep-dive: from tool stock to provable operations

The technical core is not a single platform. It is a data and responsibility model that can start small while remaining automatable. A good first version may consist of a central inventory table, identity reference, backup-test log, monitoring events, runbook board, and supplier register. The important point is not instant perfection. The important point is that each row has an owner, status, and evidence path.

A pragmatic architecture looks like this:

NIS2 readiness operating model
├── Inventory: system, owner, criticality, data class, supplier
├── Identity: roles, admins, MFA, offboarding, service accounts
├── Recovery: backup source, restore test, result, next check
├── Monitoring: signal, threshold, recipient, runbook, ticket
├── Suppliers: service, dependency, security owner, questionnaire status
└── Review: monthly gap list, decisions, automation candidates

At first, this model can stay deliberately lightweight. A structured repository, table model, ticket system, and clear review routine are often better than a large GRC tool nobody maintains. Automation comes after the map exists: n8n can trigger recurring questionnaire checks, missing owner fields, expiring review dates, or backup-test reminders. Ansible, Semaphore, or GitLab workflows can make repeatable infrastructure work visible. Central identity through LDAP, Active Directory, or Keycloak can stabilize roles and offboarding. Logging and monitoring systems can connect signals directly to runbooks and tickets.

The main tradeoff is this: do not start with maximum tool depth while the operating model is unclear. A GRC system without real assets and owners becomes a second archive. A monitoring tool without defined signals becomes noise. An automation without responsible people becomes the next shadow process. Build the map first, then build the loops.

Planfold’s care-free package is not a compliance promise in this context. Planfold does not give legal opinions and does not certify NIS2 compliance. The contribution is implementation: standardise infrastructure, clarify access, test backups, operate monitoring, automate workflows, document supplier and incident paths, and keep reviews rhythmic. That is the work that turns a policy into a digital machine.

A 30-day starter plan for NIS2 readiness

Readiness should not begin as a year-long abstraction. A 30-day starter plan is not enough for full NIS2 classification or every measure. It is enough to move from gut feeling to an initial operating foundation.

Week 1: Map exposure and customer pressure. Collect key customers, sectors, supplier questions, critical systems, and external providers. Note where direct NIS2 exposure may exist and where only commercial pressure exists. Legal classification stays with counsel or competent authorities, but the operating map can start immediately.

Week 2: Assign owners and access boundaries. Every critical system needs a business owner and a technical owner. Review admin accounts, MFA, provider access, and offboarding. Decide which shared accounts need to be replaced first.

Week 3: Test one restore and one incident runbook. Do not choose the easiest test; choose an important process. Restore a file, database, or configuration. Record how long it took, what was missing, and who had to decide. Then test a short incident scenario: who is notified, which log matters, which customer or supplier would be affected?

Week 4: Document evidence and select automation gaps. The first three weeks produce a gap list. Not everything needs to be solved immediately. Prioritise the gaps that directly affect customer questions, incident response, or recovery. Automation then becomes useful: reminders, checks, review tickets, supplier status, backup-test records, and monitoring routes.

How Planfold helps without building compliance theater

NIS2 readiness does not need fear-based communication. It needs a company that can explain and operate its digital machine under pressure. That is the practical difference between compliance theater and operational capability.

Planfold can help build that foundation as a care-free package: inventory, infrastructure standardisation, central identity, backup and recovery tests, monitoring, status alerts, runbooks, supplier and automation overviews, and monthly reviews. The promise is not “we make you legally compliant.” The promise is “we build and operate the evidence foundation your customers, insurers, auditors, and incident teams will want to see.”

If your company has just received its first supplier questionnaire or has realised that cybersecurity can no longer run on the side, start with the map. Which systems are critical? Who owns them? What can be restored? Which suppliers are connected? What happens in the first 24 hours of an incident?

For a broader architecture perspective, the infrastructure modernisation proof is also useful:

The result is not a folder full of reassurance. The result is an operating model that can answer questions before an incident or customer forces them.