Allergen management for hospitality: a practical operations guide

Last updated: April 2026 · ~8 min read

Allergen management in hospitality is not a single document, a single training session, or a single sticker. It is an operational chain that starts at the supplier specification and ends at the plate in front of a guest. If any link in that chain is hand-typed, retyped, or relies on someone's memory, the chain is fragile. This guide lays out the chain in full, where it commonly breaks, and what a defensible operation looks like in practice. It is written for hospitality teams, not legal teams, and it is the operational companion to our Natasha's Law guide and our Owen's Law guide.

1. The chain, in one paragraph

Allergen data lives at the ingredient level. Ingredients combine into recipes. Recipes combine into menus. Menus combine into events (or services, in a non-event venue). Events combine guests with dietary requirements. The job of allergen management is to make sure that for every guest, every dish on their plate has been checked against every allergen they cannot eat, and that the checked information is on a printed record (a label, a menu, an event order) that the kitchen and floor team can act on.

2. The 14 allergens you have to track

UK and EU regulation centres on a list of 14 named allergens. Hospitality operators have to recognise and emphasise each one in ingredient lists. The list is closed and identical across PPDS, prepacked, and (under the proposed Owen's Law) non-prepacked allergen disclosures.

• Celery
• Cereals containing gluten
• Crustaceans
• Eggs
• Fish
• Lupin
• Milk
• Molluscs
• Mustard
• Peanuts
• Sesame seeds
• Soybeans
• Sulphur dioxide and sulphites
• Tree nuts

3. The four failure modes that cause incidents

1. Hidden allergens in compound ingredients. A gravy that contains wheat. A chocolate that contains soy lecithin. A stock that contains celery. The headline ingredient on the menu hides the allergen, and a memory-based labelling system never surfaces it.
2. Stale data after supplier reformulation. A supplier silently adds mustard to a sauce. The recipe and label do not change. The next service that uses it is non-compliant and the operator does not know.
3. Verbal advice that conflicts with the label. A guest asks a server about an allergen. The server gives a confident answer based on memory. The label or menu disagrees. The server's answer wins because the guest hears it first; the kitchen plates accordingly.
4. Late dietary requirements that never make it to the kitchen. A guest emails on the day with a peanut allergy. It reaches the sales manager and stops there. The kitchen sees the original event order, not the updated one.

4. From ingredient data to kitchen-ready output

A defensible operation runs allergen data through a single chain with no manual retyping at any step. In practice this means:

• Every ingredient in the system has its 14-allergen profile recorded once, ideally imported from supplier specifications.
• Every recipe inherits its allergen profile by composition; if the recipe contains the ingredient, it inherits the allergens, including from compound sub-ingredients.
• Every menu inherits its allergen matrix from its recipes; the matrix updates automatically when an ingredient or recipe changes.
• Every event inherits the menu and the per-guest dietary requirements; the system pre-checks each guest's plate against the menu.
• Every printed output (PPDS label, menu, Catering Event Order, per-guest sub-menu, allergen matrix) is generated from the same underlying data, never typed.

When this is in place, a supplier change updates everything downstream automatically. When it is not in place, the operator is maintaining the same data in a recipe book, a costing sheet, a menu, an allergen sheet, and a label. Five places to keep in sync, which is what causes the incidents above.

5. How allergen management changes for private events

Private events add a step that does not exist in regular service: per-guest dietary intake. The guest list is fixed, and each guest has been individually surveyed, so the operation is responsible for per-guest decisions, not just per-menu disclosures. That demands:

• Per-guest profiles. Each guest's dietary requirements captured against the booking, with a clear distinction between allergies (safety-critical) and preferences (vegan, low-carb).
• Per-guest sub-menus. Where a guest cannot eat the standard course, a substitute course generated, named, and added to the Catering Event Order before service.
• A printed event-day record. A document the brigade and floor team work from, with allergens flagged inline against each course and each restricted guest.
• An audit trail. If an incident occurs, the operator can show what was on the menu, what dietary information was held, what the system flagged, and what was served.

6. The training that still matters

Software replaces the steps that should not depend on memory. It does not replace the steps that should always depend on judgement. The training that still matters: front-of-house pointing the guest to the written source rather than guessing; the kitchen escalating ambiguity rather than improvising; the manager treating "may contain" as a genuine cross-contact statement, not a precautionary fig leaf for sloppy data. A good system makes those judgement moments rarer, but it does not remove them.

7. Where Havenue fits in

Havenue's Safety Engine is built around exactly the chain described above. Ingredient profiles flow into recipes, recipes into menus, menus into events. Per-guest dietary requirements run deterministically against the menu, and any guest whose plate is at risk is flagged with a generated, kitchen-ready substitute course. The Catering Event Order, PPDS labels, and allergen matrices are derived from the same data, so a supplier change or a late dietary update never has to be re-keyed in multiple places.

See also: the dietary Safety Engine on the home page, how the Havenue Brain digitises existing PDF recipes, and the unified event operations dashboard.

This guide is a practical overview for hospitality operators and is not legal advice. Compliance under Natasha's Law, the Food Information Regulations, and the proposed Owen's Law remains the responsibility of the operator. For specific compliance decisions, consult your local authority Environmental Health Officer or a qualified food-law adviser.