Food Plant Hit by Ransomware or Cold Chain Breach? When NIS2 Art. 23 Requires a 24-Hour Report

On 30 May 2021, JBS SA — the world's largest beef producer by sales — paid $11 million in Bitcoin to recover from a ransomware attack that halted every US beef facility for approximately three days. The attack shut down around 20% of US beef processing capacity, and the US Department of Agriculture could not publish wholesale meat price reports on June 1 because too little market data was available [4]. If JBS had operated as an EU important entity under NIS2, its security team would have needed to file an early warning with the national CSIRT within 24 hours of first becoming aware of the attack — before forensics were complete, before the ransom decision was made, and before a single facility had restarted [1].

This guide maps three food sector incident scenarios — ERP ransomware, cold chain monitoring failure, and OT/SCADA plant attack — to the Article 23(3) significance test. It shows how the threshold analysis differs by incident type, why cold chain failures create two parallel reporting obligations rather than one, and what a food-sector-specific response procedure looks like. CISOs, compliance officers, and food safety managers at EU food manufacturers and processors meeting the Annex II size thresholds should complete this analysis before an incident, not during one.

For the full Article 23 notification framework across all sectors, see our Article 23 incident notification reference. For sector-level NIS2 obligations including risk management and supply chain requirements, see our food industry NIS2 compliance guide.

Who This Article Is For: NIS2 Scope for Food Sector Entities

Food production falls under NIS2 Annex II, Sector 7: “Production, processing and distribution of food.” The directive covers the industrial food chain from initial processing through wholesale distribution. What is excluded matters as much as what is included.

In NIS2 Scope (Annex II Sector 7)	Excluded from NIS2 Scope
Industrial food manufacturers (meat processing, dairy, bakery, beverage)	Primary agricultural producers (farms, fisheries, crop growers)
Food processors (cold-cut facilities, ready meals, canning, freezing)	Food retailers (supermarkets, greengrocers, market traders)
Wholesale food distributors supplying retailers or HoReCa at scale	Transport-only cold chain operators (no processing activity)
Integrated food groups with processing and distribution under one legal entity	Restaurants, canteens, and food service operations

The size threshold applies at entity level: 50 or more employees, or annual turnover and balance sheet total exceeding €10 million. The Finnish Food Authority — one of the first national competent authorities to publish dedicated food-sector NIS2 guidance — confirmed this scope and noted that storage-only operators and food-contact material manufacturers are also excluded [3].

Food sector entities are classified as important entities under Annex II, not essential entities. The Article 23 reporting obligation applies identically to both tiers. The maximum fine for an important entity is €7 million or 1.4% of global annual turnover, whichever is higher. Supervision is reactive (ex-post): the competent authority investigates after a complaint or incident, rather than conducting proactive audits.

One distinction most compliance resources omit: food sector entities are not covered by Commission Implementing Regulation (EU) 2024/2690, which sets quantitative significance thresholds for cloud providers, DNS operators, content delivery networks, and managed security service providers [8]. That regulation's financial trigger — a direct loss exceeding €500,000 or 5% of annual turnover, whichever is lower — does not apply to food manufacturers. For a food entity, the significance test is the qualitative two-limb test in Article 23(3), applied by the competent authority with proportionality discretion. There is no safe harbour figure to calculate, and the assessment must be documented.

The Art. 23(3) Significance Test in a Food Processing Context

Article 23(3) establishes two criteria — meeting either one is sufficient to classify an incident as significant [1]:

• Art. 23(3)(a): the incident has caused, or is capable of causing, severe operational disruption of the services or financial loss for the entity
• Art. 23(3)(b): the incident has affected, or is capable of affecting, other natural or legal persons by causing considerable material or non-material damage

“Capable of causing” is the operative phrase in both limbs. Your significance assessment must consider potential impact, not only confirmed impact at the moment of assessment. A ransomware variant with confirmed lateral-movement capability already present in your ERP environment is “capable of causing” severe disruption even when first detected on a single host.

For food processors, the two limbs map to distinct impact categories:

Art. 23(3) Limb	Food Sector Trigger Conditions
(a) Entity-level harm	Production halt (revenue loss in food OT environments frequently exceeds €1 million per hour [6]). Ransom payment. Forced product disposal. ERP outage preventing production scheduling or order management.
(b) Third-party harm	Supply shortfall leaving named retailer or HoReCa buyers unable to fulfil commitments. Product recall risk affecting end consumers. Wholesale market price disruption. Contamination risk from unavailable cold chain records.

When JBS's US facilities halted in May 2021, the USDA was unable to issue wholesale meat price reports on June 1 because too little market data was flowing [4]. A single processor's incident disrupted public pricing data — a textbook example of third-party harm under Art. 23(3)(b). An EU food processor with comparable share in a protein category would trigger this limb through supply disruption to downstream buyers before a single consumer was directly harmed.

As a practitioner's working threshold — not a regulatory safe harbour — the Art. 23(3)(b) limb becomes relevant when your production halt would leave a named downstream buyer unable to fulfil their own contractual commitments, or when your absence from the market disrupts pricing transparency. Document your version of this threshold in your significance assessment procedure, and confirm it with your legal counsel and the competent food authority's published guidance.

The awareness timestamp is the most consequential detail in Art. 23. The 24-hour clock begins when the entity “becomes aware” of the significant incident. An automated security alert confirming malicious code on ERP servers constitutes awareness. You do not need confirmed root cause, attacker attribution, or damage quantification before the clock starts. Build a written protocol naming who confirms the awareness moment and how that timestamp is logged — a competent authority examining a late notification will always ask for this documentation first [1].

Scenario A — ERP Ransomware: The JBS 2021 Attack Mapped to NIS2 Art. 23

JBS SA was attacked on Sunday 30 May 2021 by the REvil ransomware group, widely attributed by the White House to a Russian criminal organisation [4]. The attack targeted IT systems. JBS proactively shut down industrial production networks as a containment measure — not because OT was directly compromised, but because the business decision to prevent lateral spread to production systems was rational and appropriate [5]. All US beef facilities stopped. By approximately June 2, most had restarted. The company paid $11 million in Bitcoin.

Applying Article 23(3) as if JBS were an EU important entity:

NIS2 Art. 23(3) Limb	JBS Scenario Analysis	Verdict
(a) Severe financial loss or operational disruption	$11M ransom plus three days of 100% facility shutdown. USDA confirmed the disruption publicly on June 1 [4].	Met — clearly
(b) Considerable damage to others	~20% of US beef processing capacity offline for three days. Downstream retailers and foodservice buyers unable to source product. USDA wholesale price reporting suspended [4].	Met — clearly

Under NIS2, the 24-hour early warning would have been required by end of Monday 31 May — before JBS had completed forensic investigation, before it decided whether to pay the ransom, and before production had resumed. The early warning is not a forensic report. It requires three things: the nature of the incident (ransomware, IT systems), a preliminary significance assessment (yes — all facilities halted), and initial containment actions taken. The full investigation follows in the 72-hour notification and the 30-day final report [1].

ERP ransomware: what changes the Art. 23(3)(a) threshold. Not every ERP outage crosses the significance line. The variable is how tightly ERP is coupled to active production:

• ERP down, production continues on local procedures: Art. 23(3)(a) accrues slowly. If lines run 12–24 hours on cached or paper-based data, the financial loss builds gradually. Significance may not be clear-cut in the first few hours.
• ERP down, production scheduling immediately halted: Art. 23(3)(a) is met rapidly, especially in just-in-time environments where live ERP data governs recipe compliance, batch allocation, and regulatory weight certification.
• ERP down, supply chain visibility lost: Art. 23(3)(b) activates when named downstream buyers cannot receive order confirmations, dispatch data, or food safety documentation they are legally required to hold from you.

Document which ERP modules are production-critical versus administrative in your incident response playbook. This classification directly determines your Art. 23(3)(a) timeline and must exist before an incident occurs.

Scenario B — Cold Chain Monitoring Failure: The NIS2 + EU 853/2004 Double Trigger

Ransomware encrypts the SCADA system managing cold chain temperature monitoring at a meat processing facility. Physical refrigeration continues — compressors run on separate industrial controllers — but the digital temperature logging system is unavailable. A 14-hour gap opens in the temperature audit trail before the SCADA system recovers.

This scenario creates two independent reporting obligations that run in parallel, not sequentially.

NIS2 Art. 23 trigger. The cyber attack on the temperature monitoring SCADA is a cybersecurity incident affecting a network and information system. If it causes or is capable of causing severe operational disruption (Art. 23(3)(a)), or if the resulting audit-trail gap creates food safety risk capable of damaging downstream parties (Art. 23(3)(b)), it meets the significance threshold. A 14-hour temperature record gap covering perishable meat products is almost certainly capable of causing considerable material damage to a downstream buyer who depends on that documentation for their own food safety compliance [1].

EU 853/2004 trigger. Regulation (EC) No 853/2004 sets mandatory temperature requirements for food of animal origin throughout the cold chain [9]:

Product Category	Maximum Permitted Temperature (EU 853/2004, Annex III)
Meat — carcasses (beef, pork, lamb)	≤ +7°C
Poultry	≤ +4°C
Offal	≤ +3°C
Minced meat (chilled)	≤ +2°C / ≤ −18°C frozen
Meat preparations (from species other than poultry)	≤ +2°C
Frozen products	≤ −18°C

When temperature monitoring records are unavailable, processors face a binary choice: condemn and dispose of potentially affected product, or defend the food safety case to the national food authority without documentary evidence. In practice, most processors opt for disposal — the liability exposure from releasing potentially unsafe product into the market is unbounded, and food authority inspectors treat absent records as evidence of a compliance failure, not a neutral data gap [10].

Dual notification in practice. Notify the national CSIRT under Art. 23 (cybersecurity incident) and notify the national food authority concurrently (food safety compliance gap). Do not sequence these: waiting for the cyber investigation to conclude before contacting the food authority is not compliant with food law. The two obligations are triggered by different events — the cyber attack and the resulting record gap — and have different recipients and different clocks. Your Food Safety Officer must be in the incident response team from the first hour for any incident touching cold chain or HACCP-critical monitoring systems. For supply chain documentation requirements that feed into this process, see our supply chain security guide.

Scenario C — OT/SCADA Attack: When the Production Line Goes Dark

In August 2024, a Spanish meat processing plant was attacked by the RansomHub group, which took over the facility's SCADA system and halted production directly [6]. This is qualitatively different from the JBS scenario: where JBS's IT environment was compromised and OT shutdown was a precautionary containment decision, an OT-targeted attack removes the decision entirely — the production line stops because the control system is compromised.

The Art. 23(3)(a) threshold is reached more rapidly in an OT incident than in an ERP-only attack. Production revenue losses begin immediately, with no paper-based fallback for a PLC managing line speeds, HACCP critical control points, or automated portioning and weight compliance equipment. More than a third of food manufacturers report that one hour of OT downtime costs at least $1 million in revenue [6].

How attackers reach food OT environments. The most common path: initial compromise via phishing or VPN credential theft → lateral movement through the corporate IT network → process historian or engineering workstation → OT network via legitimate remote access tools [7]. The assumption that OT and IT are air-gapped in food facilities — while widespread in older estate environments — is routinely exploited. Remote maintenance access, vendor software update connections, and USB-injected malware all create the connectivity that attackers require [7].

Under Art. 21(2) of NIS2, incident handling procedures must cover all network and information systems — including OT [2]. A generic IT incident playbook will not cover the recovery time objective for production line restart, the authority protocol for isolating SCADA systems without a standard change-approval process, or the manual override procedures for HACCP monitoring during an OT incident. These elements require a dedicated OT runbook. For the full six-phase incident response framework applicable across sectors, see our NIS2 incident response playbook.

Building Your Food-Sector Incident Response Procedure

The four phases below adapt the NIS2 incident response model to food production realities. Each phase contains a food-specific element that generic sector-agnostic playbooks omit.

Phase 1 — Detect and Classify (0–4 hours). Establish whether the incident is IT-only, OT-only, or both. Run a parallel food safety check simultaneously: is cold chain monitoring affected? Are HACCP critical control point records intact? Has any temperature threshold potentially been exceeded without a complete log? The answer determines whether the response runs on one compliance track (NIS2) or two (NIS2 plus food authority notification). This decision must be made within the first 30 minutes, because it changes containment priorities — an incident affecting digital food safety records cannot be contained the same way as a pure IT data breach.

Phase 2 — Contain and Notify (4–24 hours). File the Art. 23 early warning before the 24-hour mark, even with an incomplete picture. The early warning obligation does not require a complete incident analysis — it requires timely notification of an incident that has reached or is likely to reach the significance threshold. Containment actions must preserve forensic evidence: do not wipe, restore, or reimage systems without first creating forensic copies. If cold chain records are involved, initiate the food authority notification concurrently with the CSIRT notification.

Phase 3 — Investigate and Report (24–72 hours). Submit the 72-hour incident notification with estimated impact, preliminary root cause if identified, and actions taken. Run the food safety compliance track in parallel: product disposition decisions, food authority status updates, and downstream customer notifications must be documented alongside the NIS2 compliance track. Compliance Officer owns the Art. 23 filings; Food Safety Officer owns the product disposition decisions.

Phase 4 — Recover and Close (72 hours to 30 days). Submit the final Art. 23 report by day 30. Update the significance assessment procedure based on what the incident revealed about actual production system dependencies. Revise asset criticality classifications if ERP or OT dependencies were not correctly mapped before the incident.

Role	Primary Responsibility in Food-Sector IR
CISO / IT Security Manager	Leads cyber response, coordinates containment with OT team, primary interface with national CSIRT
Food Safety Officer	HACCP critical control point assessment, temperature record status, product disposition decisions, food authority contact
Compliance Officer	Art. 23 filings (24h, 72h, 30-day), dual-notification coordination, legal log of all authority contacts
OT Security Lead (if applicable)	Production line containment decisions, SCADA isolation authority, OT recovery sequencing
Board / Executive Sponsor	Management accountability under Art. 20; escalation decisions; approval for external communications

The Food Safety Officer role is the element most commonly absent from generic NIS2 IR templates. In a food sector incident touching cold chain, HACCP systems, or OT equipment, the Food Safety Officer's decisions about product safety run on a different clock and a different regulatory framework than the cybersecurity response. Both must run simultaneously from the first hour.

Frequently Asked Questions

Our ERP outage was caused by a failed vendor patch, not a cyber attack. Does Art. 23 apply?

No. NIS2 Art. 23 applies to cybersecurity incidents — events that compromise the availability, authenticity, integrity, or confidentiality of network and information systems through a violation of security. A failed patch update without malicious intent or external breach does not qualify. Document the root cause clearly in your incident log so you can evidence this distinction if the competent authority asks [1].

We have 48 employees and €13 million annual turnover. Are we in NIS2 scope?

The standard NIS2 threshold is 50 or more employees OR annual turnover exceeding €10 million — meeting either criterion is sufficient. With 48 employees but €13 million turnover, you meet the turnover threshold and are in scope. Confirm against your member state's national transposition and check whether your national food authority has published entity registration guidance specific to the food sector [3].

Must we notify both the CSIRT and the food authority simultaneously for a cold chain cyber incident?

Yes — the two obligations run in parallel, not sequentially, because they are triggered by different events. The NIS2 Art. 23 early warning is triggered by the cybersecurity incident, due within 24 hours of awareness. The food authority notification is triggered when product safety compliance cannot be demonstrated — typically when temperature records are unavailable. Both can activate from the same root incident but have different timelines, different recipients, and different required content. Waiting for the cyber investigation to conclude before contacting the food authority is not compliant with food safety law.

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 Article 23: Reporting Obligations — nis-2-directive.com
2. NIS2 Directive Article 21: Risk-Management Measures — nis-2-directive.com
3. NIS2 Cybersecurity Directive in the Food Industry — Finnish Food Authority (Ruokavirasto)
4. JBS S.A. Ransomware Attack — Wikipedia
5. JBS Attack Puts Food and Beverage Cybersecurity to the Test — Claroty
6. From Farm to Fallout: Ransomware's Impact on the Food Chain — TXOne Networks
7. The Implications of the NIS2 Directive for the Food Industry — TXOne Networks
8. NIS2 CIR 2024/2690: Cybersecurity Requirements for EU Digital Infrastructure — Advisera
9. Regulation (EC) No 853/2004 Annex III — legislation.gov.uk
10. NIS2 for the Food Industry: Challenges & Implications — Forenova