How Multi-Site Food Operations Map HACCP to NIS2 Art. 21(2)(a) — and Build One Audit Trail for Both

A cyberattack on a food processing facility rarely looks like a breach of personal data. It looks like a temperature deviation on a pasteurisation line, a conveyor routing anomaly, or a chilling cycle that fails to complete on schedule. These are physical events with food safety consequences — and they can be triggered remotely by an attacker with access to the plant’s SCADA system.

This convergence is the core challenge for food businesses navigating NIS2 Article 21(2)(a). The directive requires “policies on risk analysis and information system security” — a mandate that sits on top of, and does not replace, the HACCP obligations food operators already carry under Regulation (EC) No 852/2004. For multi-site operations, satisfying both frameworks without duplicating documentation is a material compliance problem, not just a paperwork issue.

This guide maps the HACCP seven-step methodology to the NIS2 Art. 21(2)(a) risk analysis requirement, identifies where the two frameworks diverge (and where they converge), and shows what a dual audit trail looks like in practice for wholesale food distributors and industrial processors covered by NIS2 Annex II.

Which Food Businesses Fall Under NIS2 Annex II

NIS2 Annex II, sector 4 defines the in-scope population as food businesses engaged in “wholesale distribution and industrial production and processing” — using the definition of “food business” from Article 3, point (2), of Regulation (EC) No 178/2002 [4]. That definition captures any undertaking carrying out activities related to any stage of production, processing, or distribution of food, whether for profit or not.

In practice, this narrows the NIS2 Annex II scope to three categories:

• Industrial food processors: manufacturers of packaged goods, dairy, meat, beverages, and other processed products at industrial scale
• Wholesale food distributors: operators moving food products between producers and retailers or food service clients at commercial volume
• Vertically integrated operators: companies that process and distribute, including those with their own cold chain logistics

Retail food businesses, restaurants, farm-level primary producers, and agricultural operators are explicitly excluded from Annex II sector 4 scope — NIS2 applies only after primary production, which aligns with the same boundary drawn by Regulation 852/2004 Article 5(3) for HACCP obligations [3].

The size threshold applies as it does across all of NIS2: medium-sized entities and above, meaning at least 50 employees or annual turnover above €10 million. Smaller food businesses fall below the threshold regardless of production volume, unless a member state chooses to extend scope downward under national transposition.

Food businesses in scope are classified as Important Entities under NIS2 — not Highly Critical (Annex I). The distinction matters for penalty exposure: Important Entities face a maximum administrative fine of €7,000,000 or 1.4% of total worldwide annual turnover, whichever is higher, under NIS2 Article 34 [2].

Entity Type	NIS2 Annex	Classification	Max Fine
Industrial food processor / wholesale distributor (50+ employees)	Annex II, sector 4	Important Entity	€7M or 1.4% turnover
Retailer, restaurant, primary producer	Not in scope	Not covered	—
Food business under 50 employees	Threshold not met	Not covered (unless MS extends)	—

What Article 21(2)(a) Requires: Risk Analysis Policy and Information System Security

Article 21(2)(a) of Directive (EU) 2022/2555 mandates “policies on risk analysis and information system security” as the first of ten minimum security measures [1]. Two separate policy documents are implied: one covering how your organisation identifies and assesses risks to network and information systems, and one setting out how those systems are secured.

The risk analysis policy is not a risk register — it is the methodology that produces the register. It must address: how threats and vulnerabilities are identified, how likelihood and impact are scored, what risk acceptance criteria apply, and how often the analysis is reviewed. Article 21(1) frames all measures as requiring an “all-hazards approach” proportionate to the entity’s size, exposure, and the likelihood and severity of incidents — including their societal and economic impact [1].

The information system security policy (ISP) sets out the security architecture, roles and responsibilities, and control objectives. For food operators, this must explicitly address operational technology (OT) systems — SCADA, distributed control systems (DCS), and programmable logic controllers (PLCs) — not just office IT. A policy that describes email security and endpoint protection while saying nothing about production line controllers does not meet the all-hazards framing of Article 21(1).

Both policies must be kept current. Article 21(1) requires measures that ensure “a level of security of network and information systems appropriate to the risks posed” — which is necessarily dynamic. A risk analysis completed in 2024 that has not been reviewed after a change to your ERP integration, a new cold chain monitoring system, or a factory expansion is unlikely to satisfy a competent authority inspection.

Why HACCP Alone Does Not Satisfy Art. 21(2)(a)

HACCP under Regulation 852/2004 Article 5 is a food safety methodology designed to identify biological, chemical, and physical hazards in food production and establish critical control points (CCPs) where those hazards can be controlled [3]. Its seven-step structure — from hazard identification through documentation — is comprehensive for physical contamination pathways. It is not designed to model cybersecurity threats.

HACCP’s hazard identification step (Article 5(2)(a)) targets hazards “that must be prevented, eliminated or reduced to acceptable levels” in the food production process [3]. In practice this means Salmonella in poultry, Listeria in ready-to-eat products, allergen cross-contact, and foreign body contamination. Cyberattacks on control systems, ransomware halting production lines, and unauthorised remote access to SCADA do not appear in any HACCP hazard category — because HACCP was written in a world where production line control systems were not internet-connected.

The gap is not theoretical. HACCP critical limits (Article 5(2)(c)) define the parameters that separate safe from unsafe production — temperature thresholds on pasteurisation, pH ranges in fermentation, allergen separation procedures on shared lines. These limits are enforced by monitoring systems that are, in most modern facilities, connected to SCADA or DCS platforms. The monitoring procedures under Article 5(2)(d) assume the instrumentation is operating correctly. HACCP has no step that asks: what happens to this critical limit if the control system receives falsified inputs?

This is the precise gap that NIS2 Article 21(2)(a) fills. A food operator with a fully documented HACCP plan, verified CCPs, and corrective action records has zero NIS2 Art. 21(2)(a) compliance unless they have also performed a cybersecurity risk analysis covering the network and information systems that underpin those CCPs.

The SCADA Convergence Point: When a Cyber Breach Becomes a Contamination Risk

The clearest demonstration of why cybersecurity risk is food safety risk in a SCADA-dependent facility came not from food processing but from water treatment. In February 2021, an attacker gained remote access to the SCADA system at the Oldsmar, Florida water treatment plant and raised the sodium hydroxide dosing level from 111 parts per million to 11,100 ppm — a concentration that would have rendered the water dangerous to drink. The attempt was caught by an operator watching the screen in real time.

Food processing facilities run on the same class of SCADA architecture. A pasteurisation line is controlled by a system that monitors and adjusts temperature setpoints in real time. A fermentation vessel relies on pH and temperature sensors feeding a DCS. A chilling tunnel’s refrigeration curve is governed by a PLC. In each case, if an attacker with network access to the control system can alter the setpoint — reduce pasteurisation temperature, raise fermentation pH, or shorten a chilling cycle — the HACCP critical limit is breached without any physical intervention.

The NIS2 all-hazards approach in Article 21(1) explicitly covers “the physical environment” of network and information systems [1]. For food operators, this language closes the loop: a risk that begins as a network intrusion and ends as a failed CCP is within scope of the cybersecurity risk analysis required by Article 21(2)(a). The question is not whether SCADA manipulation constitutes a food safety risk — it clearly does at HACCP-governed production steps. The question is whether your risk analysis has modelled it.

The JBS Foods ransomware attack of June 2021 illustrates the operational dimension. BlackSide ransomware halted operations across nine beef processing plants in the United States and Australia, affecting approximately 20% of US beef processing capacity. The attack did not manipulate production parameters — it encrypted the systems controlling them. The food safety consequence was indirect: uncontrolled shutdown of refrigeration and processing lines, with the associated hygiene and cold chain risks that follow unplanned stoppages. The company paid $11 million in ransom to restore operations. For NIS2 purposes, this event would trigger both an Article 21(2)(a) risk review and, depending on its significance, an Article 23 notification obligation — the subject of a separate article in this NIS2 food sector compliance series [5].

Building a Dual Risk Register: Mapping HACCP CCPs to NIS2 Controls

The most efficient approach for a food operator subject to both Regulation 852/2004 and NIS2 is a single, integrated risk register that captures both food safety hazards and cybersecurity threats, linked at the asset level. For SCADA-dependent CCPs, this means treating the control system as a shared asset with two risk dimensions: physical process integrity (HACCP scope) and network security (NIS2 scope).

The integration point is the asset. For each production step governed by a CCP, identify the control system component that enforces the critical limit, then assess cybersecurity threats to that component as part of the same risk analysis exercise.

HACCP CCP	Critical Limit	Control System	Cyber Threat	NIS2 Art. 21(2)(a) Control
CCP-1: Pasteurisation	72°C for 15 seconds (or equivalent)	SCADA temperature controller	Setpoint manipulation via network access	Network segmentation; change management; access control
CCP-2: Metal detection	Rejection of all metal above threshold	PLC rejection actuator	Threshold parameter modification	PLC integrity monitoring; privileged access management
CCP-3: Cold chain chilling	Core temperature ≤7°C within X hours	Refrigeration DCS	Cooling curve falsification; remote shutdown	OT network monitoring; remote access governance
CCP-4: Allergen separation	No cross-contact between allergen-containing and allergen-free lines	Conveyor routing PLC	Logic modification routing allergens to free line	Change management; software integrity

For each SCADA-linked CCP, the risk analysis must address three questions: Who can access the control system, and through which network paths? What is the impact if a parameter is falsified or the system is made unavailable? What is the likelihood given the entity’s current security posture?

The answers feed both frameworks: a likelihood/impact score for the cybersecurity risk register (NIS2) and a residual risk assessment for the HACCP corrective action procedure (Article 5(2)(e) of Regulation 852/2004 [3]). The corrective action for a SCADA-linked CCP should include a “cyber scenario” alongside the standard “technical failure” scenario — what the operator does if the system is compromised rather than simply malfunctioning.

For CCPs with no SCADA dependency — manual temperature checks at goods receipt, for example — the NIS2 risk analysis still applies to the information systems that record and report those checks, but the convergence risk is lower. Prioritise integration efforts at SCADA-controlled CCPs first.

This approach also connects to the Article 21(2)(d) supply chain requirement. SCADA vendors, remote maintenance providers, and third-party monitoring services for cold chain sensors are direct suppliers under Article 21(2)(d). Their access to control systems serving CCPs is a supply chain security risk that must appear in both the HACCP supplier assessment and the NIS2 supply chain risk analysis. For a deeper treatment of incident response obligations when a breach affects a CCP, see the companion article on NIS2 Article 23 for food operators.

Multi-Site Food Operations: Entity-Level Risk Analysis Across Facilities

NIS2 applies to legal entities, not physical sites. A food company operating five production facilities under a single company registration produces one risk analysis under Article 21(2)(a) — but that analysis must cover the network and information systems across all five sites, because incidents at any one site affect the entity.

This creates a challenge that single-site operators don’t face. Each facility may run different SCADA platforms, different ERP integrations, and different network topologies. The aggregated risk is not simply the sum of individual site risks — it is shaped by shared infrastructure. An ERP system connecting all five sites is a single asset with exposure across the entire entity. A ransomware attack encrypting the central ERP halts production at all five plants simultaneously, regardless of which site was the entry point.

The risk analysis for a multi-site operator must therefore include:

• An asset inventory spanning all sites, distinguishing site-local OT assets (SCADA per facility) from shared IT assets (ERP, central logistics platforms, shared monitoring dashboards)
• Cross-site data flow mapping, identifying which systems at Site A can be accessed from Site B — and which of those paths could be exploited
• Aggregated risk scoring, reflecting the compounded impact of a shared-infrastructure breach versus a site-local breach
• Site-specific HACCP alignment, where CCPs vary by facility (a dairy site and a canning site have different CCP profiles and different SCADA risk surfaces)

The risk analysis methodology — the Article 21(2)(a) policy document — should define how site-level risk assessments are conducted, how they are aggregated, and at what threshold a local risk is escalated to the entity-level register. This is original work for most food operators: HACCP is conducted facility-by-facility, and there is no equivalent of the multi-site aggregation exercise in the Regulation 852/2004 framework.

For the practical mechanics of structuring a NIS2 risk assessment — including scoring criteria and risk appetite definitions — the risk assessment guide provides a methodology-agnostic framework applicable to both IT and OT environments.

Art. 21(2)(a) Documentation: What Auditors Will Ask to See

NIS2 Article 20 places responsibility for approving and overseeing cybersecurity risk management measures directly on the management body — the board or equivalent governing structure [2]. For food operators, this means the same executives who sign off on food safety audits must also approve the Art. 21(2)(a) risk analysis policy and information system security policy, and must demonstrate ongoing oversight of their implementation.

A competent authority inspection under NIS2 Article 32 (for Important Entities) will typically look for the following documentation trail for Article 21(2)(a):

• Risk analysis policy: version-controlled document defining the risk identification methodology, assessment criteria, risk appetite, and review schedule. Must be current — a policy predating the last significant change to production IT/OT is a gap.
• Risk register: the output of applying the methodology, listing identified risks, scores, treatment decisions, and residual risk. For food operators, this should include SCADA-linked CCP risks.
• Risk treatment plan: what actions have been taken or are planned to reduce each risk to acceptable levels, with owners and timescales.
• Management approval record: evidence that the management body reviewed and approved the risk analysis and the resulting security policies. Board minutes, a signed resolution, or a formal management decision record.
• Review records: evidence the risk analysis is updated when material changes occur (new systems, new sites, identified incidents, changed threat landscape).
• Information system security policy: a separate policy document — not a section in the risk analysis — setting out security objectives, control measures, and responsibilities, covering both IT and OT environments.

One important point on scope: the Commission Implementing Regulation (EU) 2024/2690, which sets technical and methodological requirements for cybersecurity risk management measures under Article 21(5), does not apply to food businesses. The CIR covers only specific entity types — digital infrastructure providers, cloud service providers, managed service providers, and others enumerated in Article 21(5) of the directive. Food businesses covered by NIS2 Annex II are not in that list. This means food operators are not subject to the CIR’s prescriptive technical requirements, but also cannot rely on CIR compliance as a safe harbour demonstrating Art. 21(2)(a) conformity. The proportionality standard in Article 21(1) is the applicable benchmark: appropriate and proportionate measures given the entity’s size, exposure, and risk profile.

Frequently Asked Questions

Does NIS2 apply to a food company with 60 employees and €15 million annual turnover?

Yes, if the company is engaged in wholesale food distribution or industrial production/processing. A company with 60 employees and €15 million turnover meets the medium-sized entity threshold (50+ employees or €10M+ turnover) and falls within Annex II sector 4 scope, meaning it is an Important Entity with the obligations and penalty exposure that classification entails [2].

Is our existing HACCP documentation sufficient for Art. 21(2)(a) compliance?

No. HACCP documentation satisfies Regulation 852/2004 Article 5, which requires identifying physical, chemical, and biological hazards at CCPs. NIS2 Art. 21(2)(a) requires a separate risk analysis covering threats to network and information systems, including the OT systems that enforce HACCP critical limits. The two frameworks address different hazard categories and require different policy documents, even where the underlying risk — such as SCADA manipulation — is the same event [1][3].

Does Commission Implementing Regulation 2024/2690 apply to food businesses?

No. CIR 2024/2690 applies only to the specific entity types listed in NIS2 Article 21(5), which covers digital infrastructure providers, cloud services, managed services, and similar. Food businesses are not in that list. Food operators should apply the Article 21(1) proportionality standard directly, without CIR constraints or safe harbour protections.

Does each production facility need its own Art. 21(2)(a) risk analysis?

No — NIS2 applies per legal entity. A multi-site operator produces one risk analysis that covers the network and information systems across all sites. However, that analysis must reflect the full asset inventory and risk landscape across all facilities, including site-specific SCADA systems and inter-site data flows. It is practical to conduct site-level assessments that feed into the entity-level register, but the management-approved risk analysis policy is a single entity-level document.

Which national competent authority is responsible for NIS2 oversight of food businesses?

NIS2 Article 8 allows member states to designate existing sector-specific authorities as competent authorities for NIS2 purposes. For food sector entities, this is typically the national cybersecurity authority (such as BSI in Germany, ANSSI in France, or the relevant NCA in the operator’s member state) rather than the food safety authority. Member states were required to designate competent authorities and notify the Commission by 17 October 2024. Contact your national NCA to confirm which authority has jurisdiction over your sector in your country of establishment.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. NIS2 Directive (EU) 2022/2555, Article 21 — Cybersecurity risk-management measures
2. NIS2 Directive (EU) 2022/2555, full text including Annex II — EUR-Lex
3. Regulation (EC) No 852/2004 on the hygiene of foodstuffs, Article 5 (HACCP) — EUR-Lex
4. Regulation (EC) No 178/2002, Article 3(2) — food business definition — EUR-Lex
5. The NIS2 Directive — European Commission Digital Strategy