Corporate Cybersecurity: what it means to be a NIS2 Important Entity for an electrical equipment manufacturer

The previous brief looked at cybersecurity from the product side: Cyber Resilience Act requirements, RED 2014/53 certification, and IEC 62443 as a preview of the technical framework. That discussion, however operational, covers only half of the problem.

The other half lies in the organization that builds the product, sends it into production, and updates it over its ten-year commercial life. A specification that asks for “secure firmware, secure boot, SBOM” implicitly requires that behind that firmware there is a company structured to remain a trusted supplier throughout the product lifecycle. For this reason, since 2024, the European regulatory framework has not limited itself to technical product requirements: it has extended substantial obligations to the manufacturer’s organization, and identifies by name who falls within scope.

For Herholdt Controls, this perimeter is a formal condition.

NIS2 Important Entity: what changed on 12 April 2025

The NIS2 Directive (Directive (EU) 2022/2555) was transposed in Italy by Legislative Decree 138/2024, in force since 16 October 2024. The law identifies two categories of entities that must comply with specific cybersecurity obligations: Essential Entities, typically operators of critical infrastructure (energy, transport, healthcare, finance), and Important Entities, which operate in strategic sectors whose disruption would have significant impacts on the economy or society.

The National Competent Authority for NIS, the Italian National Cybersecurity Agency (ACN), carried out the registration and classification process between October 2024 and April 2025. Organizations submitted a preliminary declaration; ACN assessed them according to the criteria set out in the decree (business sector, size, role in the supply chain of Essential Entities), and issued a formal determination of inclusion in the national list.

By Determination of the ACN Director General dated 12 April 2025, Herholdt Controls was identified as an Important Entity in relation to the manufacturing of strategic electrical equipment (NACE code C/27, manufacturing section). The determination entails a perimeter of substantial obligations: technical, operational, and organizational measures for cyber risk management; notification of significant incidents to CSIRT Italia (early warning within 24 hours, complete notification within 72 hours, final report within one month); obligation to manage the risk of its own supply chain; administrative penalties of up to EUR 7 million or 1.4% of global annual turnover in the event of non-compliance.

For a supplier of electrical equipment intended for critical infrastructure, inclusion in the NIS2 list is not a bureaucratic consequence. It is the public formalization of a risk exposure that the decree considers, in practice, systemic.

What changes for those purchasing from a NIS2 entity

The most relevant effect for the market does not directly concern the registered entity. It concerns its customers.

NIS2 imposes on regulated entities a formal obligation to manage the risk of their supply chain. In practical terms, this means that every electricity grid operator, every data center operator, and every EVSE operator classified as Essential or Important must now document the cybersecurity posture of its critical suppliers, assess the associated risks, and, where the assessment requires it, formally qualify only suppliers that meet a demonstrable security baseline.

A supplier that today is unable to answer with formal documents a question such as “what is your NIS2 perimeter, and what technical and organizational measures have you adopted as a result?” is systematically excluded from the procurement queues of regulated customers. Not because of a commercial choice by the customer, but because of the customer’s own regulatory obligation.

For this reason, ACN’s classification of Herholdt Controls as an Important Entity is not only an internal fact: it is a qualification record that regulated customers can attach to their supply-chain risk files, making the onboarding dialogue measurable and document-based rather than discretionary.

NIST Cybersecurity Framework: the architectural choice

The security measures adopted by Herholdt Controls following its NIS2 classification have been structured around the NIST Cybersecurity Framework 2.0, published by the U.S. National Institute of Standards and Technology in February 2024.

The NIST framework is not mandatory in Europe and does not replace the formal obligations required by Legislative Decree 138/2024. It is, however, the most widely adopted international reference for the operational structuring of a corporate cybersecurity program, and it is explicitly recognized by ACN among the acceptable standards for the self-assessment of risk management measures.

The choice of NIST CSF as the architectural framework responds to three methodological criteria. The first is coverage: the framework’s six functions (Govern, Identify, Protect, Detect, Respond, Recover) cover the entire cyber-risk management cycle, from governance to incident response, without gaps that would require integration with separate frameworks. The second is maturity: NIST CSF has been continuously evolving since 2014, and version 2.0 incorporates twelve years of lessons learned from organizations of every size and sector. The third is translatability: each CSF function maps precisely to the specific controls of adjacent standards (ISO/IEC 27001, IEC 62443, SOC 2), making the framework an infrastructure on which to build any subsequent formal certifications without redesigning the security program.

Applied to the operating context of an electrical equipment manufacturer, the six CSF functions translate into distinct operational domains.

• Govern: definition of security responsibilities at management level, corporate policies, budget allocation.
• Identify: inventory of assets (hardware, software, data, processes), dependency analysis, assessment of the business context.
• Protect: access controls, credential management, staff training, data protection, network segmentation.
• Detect: continuous event monitoring and anomaly identification.
• Respond: incident containment, internal and external communication, coordination with authorities.
• Recover: restoration of functions, lessons learned, continuous improvement.

None of these six domains is merely an internal good practice at Herholdt Controls. Each is an area of evidence that can be documented before a supervisory authority.

SOC and SIEM: the operational layer of detection

The Detect and Respond functions of the NIST framework cannot be satisfied with written policies. They require operational tools that observe the network and systems 24 hours a day, seven days a week, and reduce the time between the start of an incident and its identification to a window compatible with notification requirements.

Herholdt Controls has implemented two complementary tools for this function: a SIEM (Security Information and Event Management) and a SOC (Security Operations Center).

The SIEM is the technical platform that collects, normalizes, and correlates in real time the logs generated by every system in the corporate infrastructure: firewalls, mail servers, domain controllers, endpoints, business applications, and production automation systems. Normalization makes it possible to treat events from heterogeneous sources uniformly; correlation makes it possible to identify patterns that, taken individually, would be invisible. A single failed authentication attempt on an administrator account is background noise. Five thousand failed attempts from geographically dispersed IP addresses over sixty minutes, correlated with a successful login to the same account, are an ongoing credential-stuffing attack.

The SOC is the team, internal or provided through qualified outsourcing, that works on the data produced by the SIEM. It receives alerts generated by correlation rules, assesses them according to predefined priority criteria, separates false positives from actual incidents, and activates the response process when an incident is confirmed. A SIEM without a SOC is a tool without interpretation: it produces alerts that no one reads. A SOC without a SIEM is a team without visibility: it must infer what is happening from ad hoc reports.

The presence of both, properly integrated and with correlation rules calibrated to the specific operating context (electronics manufacturing, embedded firmware development, component supply chain), is the operational baseline that NIS2 expects from an Important Entity.

Incident Response Plan, Playbook, BIA, Disaster Recovery

The detection of an incident is not the end of the process. It is the beginning.

A cybersecurity incident in a manufacturing company can take many forms: compromise of an internal account, ransomware on a development network share, exfiltration of technical documentation, tampering with a firmware binary in the build chain, or a denial-of-service attack against an exposed service. Each of these forms requires a different response, with different timings, actors, and procedures. Improvising the response at the moment of the incident is the fastest way to turn a containable incident into a systemic crisis.

For this reason, Herholdt Controls has formalized four operational documents that together constitute the response plan:

1. The Incident Response Plan (IRP) is the top-level document. It defines roles and responsibilities during an incident, severity classification criteria, internal escalation rules, communication channels with authorities (CSIRT Italia, ENISA, regulated customers) and with the media, and mandatory notification timelines under NIS2. It does not describe how individual scenarios are managed: it defines the common procedural framework.
2. The Operational Playbook operates one level below. For each plausible scenario (ransomware, compromise of a privileged account, data exfiltration, firmware tampering, physical intrusion into development systems), it describes step by step the operational actions: who is contacted first, which systems must be isolated immediately, which forensic evidence must be preserved, and which external communication is authorized. The Playbook is the document the operational team opens at three in the morning when the SIEM has generated an alert; it is what turns a written procedure into executable actions under pressure.
3. The Business Impact Analysis (BIA) addresses a different question: if a system fails or a service is compromised, what is the impact on business activity, and in what order must systems be restored? The BIA classifies each business process by criticality and defines for each an RTO (Recovery Time Objective: how long we can allow the system to remain down) and an RPO (Recovery Point Objective: how much data we can afford to lose). Metrological firmware configuration systems have a much tighter RTO than an internal document management system; firmware signing systems have an essentially zero RPO. The BIA translates these differences into an operational recovery sequence.
4. The Disaster Recovery (DR) plan is the technical document that, for every critical system identified in the BIA, describes the infrastructure, procedures, and resources required to restore it within the established parameters. Automatic backups, periodic restore tests, redundant infrastructure, geographic replication of critical data, pre-configured emergency environments. A DR plan that is written but never tested is not a plan: it is an intention. Periodic validation of actual recovery times is an integral part of the document.

Together, the four documents close the loop of the NIST framework: Detection → Response → Recovery → Improvement. Without closure, early detection of an incident is information that does not turn into action.

What this means for an OEM customer

For an OEM currently writing a specification for a supplier of electrical equipment intended for connected infrastructure, questions about the supplier’s corporate cybersecurity posture have become as structural as questions about the product.

• Is the supplier classified as a NIS2 entity (Essential or Important) by the national competent authority? In which category, and since when?
• Which information security management framework is adopted (NIST CSF, ISO/IEC 27001, sector-specific framework)?
• Is there a 24/7 operational SOC (internal or through qualified outsourcing) integrated with a SIEM? What Mean Time To Detect and Mean Time To Respond metrics are declared?
• Are the Incident Response Plan and the Operational Playbook formal documents, periodically updated and tested through exercises? Which scenarios do they cover?
• Is there an updated Business Impact Analysis identifying critical processes with their RTO/RPO? How frequently is the Disaster Recovery plan tested?
• Does the supplier formally notify its customers of significant security incidents that may affect their infrastructure, within what timelines, and with what level of detail?

A supplier that answers these questions with formal, documentable references (NIS2 identification code, map of NIST measures, exercise evidence, DR test reports) has integrated organizational cybersecurity into its processes. A supplier that answers with generic commitments of principle is declaring a level of maturity that will have to be built after the contract is signed, in a market where regulated customers can no longer afford to take that risk.

For customers currently evaluating Herholdt Controls as a supplier of electrical equipment intended for connected infrastructure, the starting point of due diligence is not a statement of intent. It is an Italian administrative act, dated 12 April 2025, that identifies it by name.