A NIS2 Project in a Manufacturing SME: How We Design and Govern Infrastructure, Security and Business Continuity

Starting Point: Know the Infrastructure Before You Protect It

The company is a manufacturer with several operating and production areas, and an IT infrastructure that grew by layers: several virtual machines running different workloads, an MES that links the office to the shop floor, industrial devices, numerous Windows endpoints, mobile devices, network storage, Microsoft 365 and a number of technology suppliers.

The assessment brought out a picture that will sound familiar to many SMEs:

• virtualisation on legacy VMware technology, with the hypervisor lifecycle still to be brought under control, and ageing server operating systems;
• monitoring and proactive management that needed improving;
• a backup model that needed strengthening, with operational replicas that are not the same as an immutable backup;
• identity governance, MFA and access control to be reinforced;
• logs that were not centralised, and vulnerability management that was not continuous;
• assets and suppliers to be catalogued better, and documentation to be improved;
• IT and OT to be brought under a single governance model.

None of these points is a scandal on its own. Together they describe a company that works, but cannot say precisely what it owns, what depends on what, or what would happen if one part stopped. It is the most common starting point, and the reason the first job is one of discovery.

NIS2: The First Step Is Knowing What You Have to Protect

The Italian transposition (Legislative Decree 138/2024) requires in-scope entities to adopt appropriate and proportionate technical, operational and organisational measures, based on an all-hazards approach. Article 24 lists, among the minimum elements, risk analysis policies, incident handling, business continuity (including backup management and disaster recovery), supply chain security, vulnerability handling, access control and asset management, and the use of multi-factor authentication where appropriate.

Two observations shape our method. First, the text speaks of proportionality to risk exposure, size and the likelihood of incidents, and it names no products or architectures. No rule mandates a specific technology, and anyone who says otherwise is selling, not explaining. Second, almost every item on the list assumes you know what you own. You cannot manage an unknown asset, assess a supplier you have not catalogued, or restore a system whose dependencies you do not understand.

That is why the project starts from an inventory, not from a product shortlist. The baseline specifications and the deadlines for adopting them are set by the Italian National Cybersecurity Agency (ACN) and run from the notice of inclusion in the national list of NIS entities, so they have to be checked case by case.

From Assessment to Technical Roadmap

The assessment gathered information in four families:

• Asset inventory: hardware, software, servers and virtual machines, endpoints, industrial devices, MES-related assets, cloud services, Microsoft 365, identities and accounts;
• Network mapping: switches, links, segmentation, firewalls, network storage, OT systems and the production network;
• Supplier mapping: which suppliers manage what, and how they access the systems;
• Documentation: the state of existing documentation and the gaps to close, with an owner for each document.

The value of an assessment is not the list, it is the dependency map. Knowing that a production service depends on certain virtual machines, shared storage, a network link and an outside supplier tells you in what order to protect and, above all, in what order to restore.

The roadmap comes out of the assessment: a document of priorities, not a quote. Each intervention is tied to a risk and a decision, which makes it defensible in front of management. The table summarises the reasoning.

Situation	Risk	Decision	Measure
Legacy virtualisation	Patching and lifecycle not under control	Modernise	Roadmap to Proxmox VE and high availability
Operational replica	Not enough against ransomware or disaster	Separate replica from backup	Immutable backup and restore testing
Loosely governed identities	Account compromise	Strengthen identity management	MFA, Conditional Access, least privilege
Scattered logs	Limited visibility	Centralise	SIEM, correlation, retention
Vulnerabilities found but not managed	Exposure that drags on	Continuous process	Identification, remediation, verification
Critical systems managed reactively	Problems found late	Proactive management	Managed service, monitoring, SLAs

From Break-Fix Support to Proactive Management

A change of model sits behind many rows of that table. User support answers a real need: someone has a problem, opens a request, the problem gets solved. But it is reactive by definition, and a critical system should not be checked only when a user opens a ticket.

Proactive management reverses the viewpoint: the infrastructure tells you something is wrong before the user does. In this project the managed service (MSP) covers continuous monitoring, management of servers and virtual machines, patch management, capacity monitoring, alerts, backup verification, monitoring of the network and critical services, Microsoft 365 management, SIEM, vulnerability management, reporting, SLAs with escalation rules, and documentation. They share one trait: they produce evidence. An activity that leaves a trace (a report, a ticket, a log) is an activity you can govern. The model is described on our page about IT support and consulting contracts.

Infrastructure and Legacy Systems: Governing the Lifecycle

"Legacy" does not mean "throw it away now". It means every component has a lifecycle and somebody has to govern it: know when vendor support ends, what can be mitigated in the meantime, when replacement makes sense. An ageing hypervisor or server operating system becomes a problem when nobody has decided what to do with it, not simply because it exists.

For legacy systems the project provides three routes, depending on the case: planned replacement; temporary mitigation with isolation and compensating controls; or documented risk acceptance, reviewed over time. The third is legitimate if it is a written decision, with an owner and a review date, and not an oversight. In a risk management system even "we keep it as it is for now" is a measure, provided it is deliberate and recorded. This is the work we do in IT systems design and secure, resilient IT infrastructure: making explicit the decisions that would otherwise be taken by inertia.

Virtualisation and Workload Continuity

If the platform hosting the workloads is fragile, so are backup, monitoring and recovery. That is why server virtualisation is one of the central items on the roadmap.

The Roadmap to Proxmox VE and High Availability

As the target platform, the roadmap points to Proxmox VE, which we work with regularly (our approach to Proxmox). To be clear: this is a roadmap, and the migration has not taken place. Here is how we designed it:

• a multi-node cluster for high availability: if a node stops, workloads restart elsewhere;
• replicated storage, with the choice between ZFS and Ceph made on the final design rather than on principle;
• Proxmox Backup Server as a component of the backup strategy;
• progressive migration of the virtual machines, in waves;
• maintenance windows agreed with production, each with a rollback plan;
• testing before and after every step, to protect workload continuity.

A migration in a plant that is producing is a business continuity project, not just an IT one: it has to be planned with whoever answers for production.

Replication, Backup and Disaster Recovery Are Not the Same Thing

It is the most common confusion, and the most dangerous. The three words describe three different things.

• Replication: an up-to-date copy of a system, kept elsewhere, meant to restart quickly if the original stops. It answers a failure. But it also replicates mistakes: if a file is deleted or encrypted by ransomware, the replica is deleted or encrypted too.
• Backup: a historical copy, with several restore points over time, kept so that whoever compromised the original system cannot alter it. It answers human error, corruption and attack. To do that it must be separate from the environment it protects and, where possible, immutable.
• Disaster recovery: the plan, not the technology. It states what is restored, in what order, with which resources, in how much time, and who decides. Replicas and backups are ingredients of disaster recovery; on their own they are not a plan.

At the starting point there were operational replicas, useful but not a substitute for an immutable backup. The model we designed is layered: backup of the virtual machines, a local copy for quick restores, an external or cloud copy for serious events, and immutable storage to withstand a compromise, with defined retention, monitoring of jobs and failures, and periodic restore tests.

Two parameters hold the design together. RPO (recovery point objective) says how much data the company can afford to lose, measured in time; RTO (recovery time objective) says how long a service may stay down. There are no universally right values: as a purely didactic example, a stopped production line usually costs more than a document archive, so it deserves a tighter RTO. Process owners set them, and the technology is sized accordingly. Our approach is described on the page about backup and disaster recovery.

A backup that has never been tested is a hypothesis. Only periodic restore tests show whether the plan works and in what order to restore: that order follows from the dependencies found in the assessment, not from improvisation on the day.

For Microsoft 365 (Exchange Online, OneDrive, SharePoint, Teams) the data remains the company's responsibility. The project provides for a backup kept separate from the tenant, with retention, granular restore, protection against deletion and compromise, and activity auditing.

Endpoints, EDR and Encryption

Many incidents begin at an endpoint, and a manufacturer has many kinds: office workstations, industrial PCs, laptops, mobile devices. The project provides coordinated measures: EDR protection, central management, patching, inventory, ransomware defence, application control, disk encryption with centrally managed BitLocker, and uniform policies.

The technologies (we work with solutions such as WatchGuard and Panda) matter less than the governance around them. An EDR with nobody watching the alerts gives false comfort: what we bring is integration with the inventory, the SIEM and policy verification. Read more about our EDR systems.

Centralising Logs with a SIEM

With logs scattered across servers, firewalls, switches and workstations, reconstructing what happened after an incident is detective work. The project provides for a managed SIEM, based on Wazuh and OpenSearch, that collects logs in one place, correlates them, raises detections, keeps evidence for audit and produces reports.

The planned sources are Windows, Linux, Active Directory, Microsoft 365, firewalls, switches, network storage, endpoints, other compatible devices and, where possible, the OT environment. A SIEM is not a legal requirement and does not make anyone compliant: it is a visibility tool. It helps you notice in time what is happening and keep the evidence to understand afterwards what did happen.

From Vulnerability to Remediation

A scan produces a list. A process produces a closure. The vulnerability management we designed is a continuous cycle: assessment, scanning, prioritisation, remediation, re-verification, closure, documentation. The difference is in the last word: without documented closure there is no management.

Prioritisation is the delicate part. The CVSS score measures the technical severity of a vulnerability, not the risk to that company; EPSS estimates the probability that it will be exploited over the following thirty days. Neither tells you alone what to fix first: they have to be combined with how exposed the system is (reachable from the internet or only from the internal network), how critical it is to the business, and which compensating controls exist. On legacy systems, where a patch often does not exist or cannot be applied, you work with mitigations or with a documented, reviewed risk acceptance.

Our job is to govern the cycle. A penetration test completes the picture by looking at the systems as an attacker would, but it is a point-in-time snapshot and does not replace the continuous process.

Microsoft 365, Identity and Access Control

For many SMEs Microsoft 365 holds the mail, the documents and everyone's identity: whoever controls identities controls the company. That is why the identity part of the roadmap is among the first to deliver value.

The planned measures: extended MFA, Conditional Access with context- and risk-based rules, administrative accounts kept separate from everyday ones, least privilege, periodic role reviews, onboarding and offboarding with session revocation, audit logs and security event monitoring on Entra ID, mail protection, plus the backup described above. Identity is the new perimeter, and periodic access review is one of the cheapest and most effective practices you can introduce.

IT and OT: Protecting the Production Environment Too

On a plant floor IT and OT follow different logics: IT favours confidentiality and updates, OT favours availability and stability, with long lifecycles. The MES bridges business systems and production lines; around it sit PLCs, embedded systems, panels, industrial devices and industrial PCs.

The project joins the two worlds on three principles. First, segmentation: the production network is separated from the corporate one, with permitted flows defined and documented. Second, non-intrusive monitoring: reachability and latency of critical systems, and logging where the device allows it. Third, caution: in OT not every scan used in IT is appropriate, because it can interfere with production; tools and windows are chosen to be compatible with the machines, and every activity is coordinated with whoever answers for production.

On the perimeter, the design includes firewalls in high availability, IDS/IPS, monitoring and logging, with continuous technical supervision. It is part of our IT security consulting.

Automation and Supervision: The Role of Hector LIS

The Hector LIS platform is the proprietary tool TN Solutions develops for continuous monitoring: it receives signals from firewalls, servers, workstations and the network, analyses them automatically and without interruption, detects anomalies and passes the relevant ones to our technicians, as defined in the contract. It is designed to integrate with the firewalls we manage, and monitoring data stays on our own infrastructure.

In the project, firewall supervision relies on Hector LIS and ties into the rest of the managed monitoring. The distinction that matters to us is this: automation covers the twenty-four hours, human oversight assesses and decides. Hector LIS does not replace security staff, it widens what they can see; and it is not the owner of the NIS2 intent, which stays with the company and its management.

When an Incident Happens, Technology Alone Is Not Enough

For significant incidents the decree provides three steps towards the Italian CSIRT: an early notification within 24 hours of becoming aware of the incident, a notification with an initial assessment within 72 hours, and a final report within one month of that notification (Article 25 of Legislative Decree 138/2024). In-scope entities need to check which incidents fall under the definition of "significant" and which baseline specifications apply.

Meeting those times takes more than good antivirus: detecting the incident (monitoring, EDR, SIEM), opening a ticket, classifying it, escalating, gathering information and preserving logs, communicating coherently, producing a report. Technology generates the signal; a written, rehearsed process turns it into action. In the project, incident support covers detection, classification, evidence collection, operational support and reporting. The decision to notify, however, remains with the company.

Governance: Access, Suppliers, Assets and Documentation

Everything described above degrades if nobody maintains it. Governance is the least visible and most decisive part. In the project it covers:

• named accounts, MFA, least privilege and periodic privilege review;
• an inventory of access and suppliers, with a simple rule: every external access is justified, tracked and revocable;
• an asset inventory that stays current, not photographed once;
• documented registers, configurations and procedures, with an owner for the documentation;
• periodic logging and reporting;
• SLAs and escalation rules that say who does what, and in how much time.

A configuration that lives only in one person's head is an operational risk before it is a regulatory one.

Design, Implement, Govern

The thread of the project comes down to three phases, which are not sequential but feed one another.

• Design: assessment, inventories, risk analysis, architectures, priorities, roadmap.
• Implement: infrastructure, modernisation, integration, cybersecurity, backup, SIEM, identity, monitoring.
• Govern: monitor, update, handle alerts, verify backups and vulnerabilities, meet SLAs, review access, follow suppliers, report, keep documentation current.

The conceptual map relates the layers:

Layer	Content
Starting point	NIS2, assessment, design
Infrastructure	Servers and virtual machines, network, IT/OT environment
Cybersecurity	EDR, SIEM, firewall, vulnerability management
Governance	Assets, suppliers, access
Continuity	Backup and disaster recovery, Microsoft 365
Operations	Managed service, monitoring, Hector LIS, reports and SLAs

What a Real NIS2 Project Teaches

A few lessons go beyond this project.

1. Start from knowledge, not tools. An honest inventory is worth more than a hasty purchase.
2. Keep replication, backup and disaster recovery apart. If you only have a replica, you do not have a backup.
3. Identity is the perimeter. MFA and access review are among the best measures for cost against effectiveness.
4. Legacy is governed, not ignored. Even accepting a risk is a decision, if it is written down.
5. In OT, caution comes before coverage. Not everything can be scanned or updated whenever you like.
6. A measure that produces no evidence cannot be governed.
7. Technology is not intent. Management is accountable; we design and run the tools that let it act with awareness.

How We Can Help

If your company is on a NIS2 path, or wants to know whether it is, the starting point is always the same: an assessment that says what you have, what depends on what, and which risks really matter. From there you build a technical roadmap that holds infrastructure, security and continuity together, and a management model that keeps it alive. TN Solutions helps companies adapt; it does not certify anyone's compliance, and the assessment of obligations and deadlines stays with the company and its advisers.

For the rules cited here we consulted the official sources: the in-force text of Legislative Decree 138/2024 on Normattiva (in Italian) and the ACN page on the baseline specifications.

Talk to one of our consultants