Testo official store
Free delivery
Secure payment
Testo official store
2026-08-26
Imagine it’s just past 11 a.m. In a central production kitchen, 15 batches are running simultaneously. Chicken in the combi-steamer and vegetables in the pressure cooker. The early shift has been cooking for six hours. Everything is going according to plan until the first batch comes out of the steamer and goes into the blast chiller. From the moment the cooler door closes, the process becomes invisible. And no one knows exactly what’s happening behind that door.
It is precisely this moment, the transition from cooking to cooling, that is one of the most critical control points in the entire production chain. Yet the risk lies not with the kitchen staff but with the process itself, which is structurally reaching its limits.
In this article, you’ll learn why heating and cooling food is so challenging from a microbiological standpoint. You’ll also learn what risks arise in practice and why the problem almost never lies with the people involved.
Hospitals, schools, company cafeterias, airline galleys, and airline catering, they all have one thing in common: They don’t cook to order, but rather in advance, and food production is physically separated from consumption. Large quantities are prepared in advance, stored chilled or frozen, and later reheated. This process is called “Cook & Chill” or “Cook & Freeze,” and it is now the standard in professional institutional food service.
The advantages are obvious: efficiency, predictability, and consistent quality. But the process comes with a responsibility that is often underestimated. This is because every additional step in the production chain - cooking, cooling, storage, and reheating - is a step with critical control points. Each of these steps has its own threshold values. And each of these steps has a clock that is ticking.
The European reference values for this are clearly defined: Poultry must be heated to a core temperature of at least 75 °C. After cooking, the product must be cooled to below 3 °C within 90 to 120 minutes. For reheating, the rule is: reheat to at least 70 °C in a maximum of 30 minutes. The exact values vary depending on the country and operational specifications, but the structure is always the same: a target value and a time window that closes.
Why are these time windows so narrow? The answer lies in microbiology. Between 5 and 63 °C, the so-called danger zone, pathogenic germs multiply exponentially. If a microorganism survives the cooking process as a spore, it waits to germinate in exactly this temperature range.
A textbook example of this is Bacillus cereus, a spore-forming agent that is mainly found in starchy foods such as rice, pasta or potato sauces. Cooking kills vegetative cells. The spores, however, survive without any problems. If the product is left in the danger zone for too long, these spores germinate and the bacteria produce cereulide, an emetic toxin that is exceptionally heat-stable. It can even survive autoclaving at 120°C for an hour.
In plain language, this means that no heating step in an ordinary kitchen can render this toxin harmless once it has formed. A subsequent correction is simply not possible. The only option is to destroy the batch or consciously accept the risk. Neither of these are optimal solutions.
For this reason, the cooling phase is an absolute safety requirement and not an optional quality control step. Even the slightest deviations can lead to an irreversible problem.
If the risks are so clear, why is monitoring still so patchy in so many facilities? The answer does not lie in the employees’ knowledge. It lies in the design of the monitoring system itself.
In practice, facilities today essentially have two options available. Option one: a wired measurement system that connects the probe to a data logger via a cable. On paper, this is the more robust solution: continuous data, traceable curves. In practice, however, it’s an inconvenient compromise. The cable gets in the way, catches on doors, makes cleaning according to HACCP standards more difficult, and limits how the batch can be positioned in the device. Furthermore, the data is stored in a silo; it must be read, interpreted, and transferred individually. The result is predictable: at some point, employees set the sensor aside because operations would otherwise not run smoothly. And what no one says out loud becomes standard practice.
Option two is even more common in many facilities: manual measurement using a hand-held thermometer and a paper log. Someone has to remember to take a reading at the end of the cooking process. Then again during the cooling phase. Then again at the very end. Timing depends on a kitchen timer, which is easy to forget to start or which might go off while you’re busy with two other batches. And this happens during a shift in which 5, 10, or 15 batches are running simultaneously.
The values are not recorded immediately upon measurement. The values may be recorded down quickly from memory at the end of the shift, or, in the worst case, the entry may even be forgotten entirely.
Measurement according to the fact: The basic structural problem
Both approaches, cable-based and manual, face the same structural problem: The measured values are interpreted only after the process step has been completed.
If an employee at a checkpoint determines that a batch may have exceeded its time window, the process is already complete. The employee can no longer intervene but must decide: destroy the batch, with all the associated costs, or accept the risk without data that would clearly justify this decision.
And even if everything runs smoothly: Where is the data? The data logger and the paper log are separate data sources. If HACCP software is used, the data from the loggers and the paper log is missing there as well. These silos are not interconnected. Every transition between the systems results in a data discontinuity, yet another source of errors, delays, and gaps. Furthermore, the complexity of an audit, in which all data is reviewed at a later date, increases immeasurably.
The result: deviations only become apparent when it is too late to respond to them. Documentation is compiled retroactively instead of being generated during the process. For audits, this means searching for evidence of something that happened yesterday in a system based on paper and memory.
Four vulnerabilities that reinforce each other
In companies that use Cook & Chill or Cook & Freeze processes, the problems typically boil down to four recurring vulnerabilities:
Documentation effort: Measuring, writing things down, setting timers: for every single batch, throughout the entire shift. This effort can quickly add up to hours and distract qualified kitchen staff from their actual duties with administrative work.
Human errors: Measurements overlooked during peak operations, incorrectly recorded values. In teams with high turnover or language barriers: processes that are carried out without being fully understood. This leads to uncertainty in implementation and errors that aren’t even recognized as such.
Lack of transparency: No company has an easy overview of which batch is currently where in the cooling phase. Planning happens on the basis of empirical knowledge, not on the basis of live data, which costs capacity.
Missing data in the test case: All data must be available in its entirety during an audit. Otherwise, if the auditor wants to know the values for a specific batch of a specific day, this could quickly become an unpleasant pitfall.
These four weaknesses reinforce one another. The burden of documentation leads to human error. Human errors create precisely the data gaps that become a problem during audits. And underlying it all is the fundamental structural problem of discontinuity in monitoring. What is recorded in most facilities today are snapshots rather than continuous temperature curves. And what is missing is proof that there were no deviations in between.
Cook & Chill is a safe process if it is implemented consistently and verifiably. The risks of heating and cooling food are real and microbiologically based. The time slots are non-negotiable. And today's monitoring practice in many companies is structurally insufficient to meet these requirements reliably and seamlessly. The question that arises from this is not "How can we better train our employees?" but: How do we build a process that works properly, even when operations are running at full speed?