How to Review an Event Menu: The Catering Allergen Matrix

A practical check of the event menu: which fields to include in the allergen matrix, who confirms the ingredients, and how to accept the serving line.

A catering allergen matrix is needed when the menu has a neat "nut-free" label, but that label alone says nothing about the sauce or the shared buffet line. That is why at Aventura we check more than just dish names. We need one up-to-date table that links the ingredients, possible cross-contact and the responsible catering employee. The cards on the line must match this version.

The allergen matrix helps manage this chain. It does not replace the kitchen's technical documents, medical advice or a specialist's assessment of a specific risk. Its task is simpler and more practical: to prevent different versions of the menu from diverging between the client, the kitchen, the waiters and the guests.

What Is a Catering Allergen Matrix?

A catering allergen matrix is a working spreadsheet covering every menu item. It shows the composition of the dish and its constituent ingredients, flags controlled components against the applicable list, describes possible cross-contact, and records how the guest is informed. Each row has a version, a status, and the catering employee who confirmed the data.

The matrix is built from the raw data up to the finished dish. First, the caterer checks the recipe, labels, and raw material specifications. Then it breaks down sauces, dressings, semi-finished products, drinks, and garnishes. Only after that does a row appear for the banquet sheet or buffet card.

A dish name is too short for this kind of check. A salad may contain a complex dressing and a topping. A dessert may contain a ready-made mix with several components.

A drink may contain a syrup or a garnish. If the team looks only at the name, part of the composition stays outside the discussion.

The British Food Standards Agency offers the allergen matrix as one way to keep records on dishes and update them when a recipe or ingredient changes. It is a useful organisational model. It does not turn the British list of allergens into a Russian standard, nor does it make a particular template a mandatory state form.

When a broader catering brief is needed, we separately work through the catering format for an event: timing, venue, guest flows, service, and budget. The allergen matrix addresses a narrower task — it preserves traceability of composition and serving.

Scope of the document and responsibilities

The matrix helps the team cross-check information and actions, but it does not prove the absence of product traces. The food operator must confirm the recipe, raw materials and kitchen process. The client and the organiser verify that the answer has been received, transferred to the working version and passed to the serving line without distortion.

In the Russian context, it is useful to separate three layers. The first is the labelling requirements for purchased products and the list of components in point 14 of part 4.4 of article 4 of the technical regulation. The second is information about the product and the catering service.

The third layer is the contractual terms of a specific off-site catering arrangement. They cannot be reduced to the phrase "14 allergens are mandatory in Russia": the number 14 refers to the European model, while TR CU 022/2011 lists components differently.

We do not call the internal table a legally established form. TR CU 022/2011 and the Rules for the Provision of Public Catering Services do not contain a mandatory form called an "allergen matrix for catering". The table remains a project tool that helps gather verifiable information in one place.

We formulate promises to guests just as carefully. If the kitchen has not confirmed a separate process, one cannot write "completely safe", "trace-free" or "suitable for all allergy sufferers". An honest note — "composition confirmed, possible contact on the shared line cannot be ruled out" — is more useful than a confident but unconfirmed promise.

What data should be collected during registration?

Registration requires an operational request, not a medical history. We ask which products or components need to be excluded, whether the request relates to a specific participant and whether we can contact them for clarification. The catering team does not need a diagnosis, a description of the reaction or medications to plan a menu if the task can be solved through a precise dietary condition.

A free-text field for "special requests" mixes preferences, religious restrictions, intolerances and the risk of an allergic reaction. The team receives answers of varying precision and starts clarifying them right before the event. It is better to separate the type of request in advance and leave a short explanation only for details that affect preparation or serving.

A working form may include the following fields:

1. Request category. Preference, religious restriction, intolerance, allergic risk or another condition.
2. What needs to be excluded. A specific product, ingredient or group of components in the guest's own words.
3. Participation format. Which meals and catering points are available to this participant.
4. Is a follow-up contact needed? A checkbox for cases where the request cannot be translated into an unambiguous condition.
5. Service identifier. A registration or order number instead of distributing the full guest list.

It is determined in advance who sees the original answers. The full register should not circulate in a general chat or end up at the buffet counter. Catering usually only needs an anonymised summary of requirements, the number of portions, the serving format and the coordinator's contacts.

If event catering is brought in after registration has opened, the team first checks the fields already collected against the kitchen's actual task. Sometimes the wording has to be clarified through the coordinator. The original answers are not sent to everyone on the project team: only the agreed condition goes into the working table.

The principle of minimisation is enshrined in article 5 of Federal Law No. 152-FZ: the amount of data must correspond to the purpose and must not be excessive. Health information has a separate legal regime. Therefore, the text of the form, the legal basis for processing, the access circle and the storage period are best checked with the person responsible for personal data. There is a separate guide on the general route of the form, confirmations and status changes in event participant registration.

Fields of the Working Matrix

The matrix should contain enough data for verification, but it should not become a copy of the kitchen's entire technical documentation. Each row links a specific dish to the source of its composition, applicable labels, serving control, and current status. If a field cannot be verified, it is formulated as an open question and an owner is assigned.

The "may contain traces" column is not filled in based on the client's assumption. The basis is supplier data and the catering side's assessment of the process. If the food operator cannot confirm the conclusion, the row remains with the status "under re-check".

The matrix is conveniently issued as an appendix to the final menu, but it should not be hidden in a long email thread. At the beginning of the document, the event name, menu version, confirmation date, and file owner are indicated. Below, a change log is kept: which item changed, why the row was reopened, and who issued the next version.

Such a log is not needed for bureaucracy. It shows why a card printed yesterday is no longer suitable for today's delivery.

The status of a row should influence the team's action. "Confirmed" allows the information to be used in the card and when answering a guest. "Under re-check" prohibits serving the item as suitable for a specific restriction.

"Removed" means that the dish, the card, and the mention in the staff sheet are taken out of circulation. If statuses exist only in the table and change nothing on the line, the matrix remains an archive rather than a control tool.

The source of composition is recorded separately. For a simple product, this may be a label. For a complex item, a recipe and information on composite ingredients are needed.

A reference "according to the chef" does not provide traceability: if an employee or batch changes, the team will not be able to repeat the check. The client does not have to store all technical documentation, but they must understand which document the catering answer is based on and where that document can be found quickly.

At the brief stage, we ask to show one completed test row before preparing the entire matrix. This reveals discrepancies in terms, statuses, and responsibilities. If the test row is clear to the kitchen, the manager, and the coordinator, the rest of the menu is assembled using the same logic. If everyone reads it differently, the form should be corrected before mass completion.

Every special request needs a bridge from the table to the actual portion. An entry in the form does not yet mean that a suitable dish has been prepared, separated, labeled, and delivered to the right point. The control link looks like this: guest request - confirmed item - specific portion - serving employee.

Who confirms each line?

The composition is confirmed by the catering employee responsible for the recipe and production, not by any project manager. The food coordinator on the organizer's side collects versions, asks questions and verifies data transfer. The client approves the service format and the rules for working with guests. The venue confirms the terms of delivery, storage, water, cleaning and service routes.

We usually divide the roles as follows:

• the technologist or an authorized kitchen employee confirms the composition, ingredients and production process;
• the catering manager is responsible for passing on the current version and fulfilling the agreements;
• the food coordinator links the menu, registration, cards, special portions and the command center;
• the person in charge on the line knows where the matrix is kept and to whom a disputed issue should be passed;
• the registration employee passes on only the agreed minimum of data;
• the project manager decides whether to stop a disputed item or change the serving format.

The phrase "catering has taken everything into account" does not close the check. You need the name of the person responsible, the version of the table and the method of confirmation. If an open question affects serving, it must have a deadline and a person who will come back with an answer.

When organizing a corporate event, catering intersects with the program, the venue, registration and guest services. Therefore, the owner of the matrix must be inside the project's overall command center, rather than working separately from the scenario of the day.

Menu versions and change control

Any replacement of an ingredient or supplier can change a row in the matrix. The same applies to a new sauce, side dish, garnish, semi-finished product or drink. After a change, the affected item goes back for re-verification, and the old card is removed from the line. Until it is confirmed again, staff do not use the previous label when answering a guest.

The working file must have a single owner and a clear version name. A date in the name is useful, but it is not enough if several people create copies. It is better to keep one current source and issue exports for the kitchen, print and command centre from it after confirmation.

The change procedure can be broken down into five steps:

1. Catering reports which item and which component have changed.
2. The kitchen manager re-checks the composition and possible cross-contact.
3. The coordinator updates the matrix and marks the previous row as no longer valid.
4. The team updates the cards, the banquet sheet, the list of special portions and the staff instructions.
5. Before opening, the same item undergoes re-verification on the line.

A message saying "replaced with an equivalent" is not acceptable. An equivalent product may have a different composition or different labelling. Until the data is confirmed, the dish remains in "under re-verification" status or is removed from service.

How do you check the cards and the service line?

A card must clearly relate to a dish and match the current matrix. A coloured icon without clear text is easy to confuse. We check the exact name, the position of the sign, readability, the absence of an old version and the guest's route to additional information. We separately verify sauces, drinks, bread and garnish, which are often placed nearby without their own card.

At a buffet, we look not only at the signs. Shared tongs can move from one container to another. Guests move cutlery and plates around.

Garnish or sauce is added after the main assembly. Therefore, a confirmed special portion often requires a separate controlled service route, which the catering operator determines.

Before opening, the coordinator walks the line in the order in which the guest will see it:

1. Checks the ID and name of each item against the final banquet sheet.
2. Matches the card with the latest version of the matrix.
3. Checks sauces, drinks, bread, extras and garnish as separate elements.
4. Locates special portions and checks their labelling and storage location.
5. Clarifies which utensils belong to each container and who monitors their position.
6. Asks a service employee to show where they get an accurate answer to a question about composition.
7. Checks who staff report a discrepancy to and who is authorised to stop an item.

The phrase "ask a waiter" only works when the waiter opens the current record or quickly contacts the person responsible. An answer from memory is not acceptable. Staff should calmly say: "I will check the matrix" if there is no confirmation nearby.

Food also forms part of the full accessible participation route. In the article on inclusive corporate events, we explain separately why a preference, religious restriction, intolerance and allergic risk cannot be combined under a single coloured label.

Dry run before opening

A dry run is needed to test people's actions, not the beauty of a spreadsheet. We give an employee a real scenario: find a dish, open the right row, check the card, show a special portion and pass the question on to the person responsible. If the chain breaks, the issue is logged and the test is repeated after it is fixed. The result is recorded by the catering coordinator, who is present on the line.

For a short dry run, a few control situations are enough:

• a guest asks about the ingredients of a sauce that is not mentioned in the dish name;
• the card on the line does not match the latest version of the menu;
• a special portion arrived without clear labelling;
• a utensil from a shared item ended up with a separate portion;
• the serving employee does not know where the matrix is kept;
• the supplier reported an ingredient substitution after the cards were printed;
• a late guest request could not be agreed with the kitchen in time.

Each issue gets a location, a fact, an owner and a deadline for re-checking. A general note like "fix the labelling" is too vague. It is better to write: "At the coffee break station, the card for item M-12 shows the previous name; the catering manager changes the card and shows it to the coordinator before the line opens."

After the fix, the team repeats the same step under the same conditions. A message saying "done" does not count as a check. We use the same approach in the technical rehearsal of an event: a defect is closed by a repeat test, not by the performer's confident answer.

What to do if the composition is not confirmed?

An unconfirmed item cannot be presented as suitable for a specific restriction. The team stops the disputed serving, checks the current matrix against the primary source, obtains an answer from the authorized catering employee, and only then communicates the confirmed result to the guest. If there is no answer, this must be stated directly. The guest is offered only the alternative whose composition and serving have already been verified.

The working procedure is as follows:

1. Record the exact question and the dish ID.
2. Do not answer based on the name or from memory.
3. If necessary, stop the serving of the specific item.
4. Check the matrix version, label, specification or technical card.
5. Obtain confirmation from the responsible catering staff member.
6. Update the card and the working spreadsheet if a discrepancy is found.
7. Offer only a pre-confirmed alternative.

A backup should not mean "give something similar". If an alternative portion has not passed the same check, it remains unconfirmed. The decision on whether a dish is suitable for a specific person is not made by the event organizer or by a waiter based on the appearance of the plate.

For the command center, the message is formulated without a diagnosis or unnecessary personal details: "On line B, stop item M-12 until the composition is verified; responsible person - catering manager; next check after the card is replaced". The general logic of roles and escalation can be linked to the event crisis management plan.

Plan B without medical promises

Plan B describes the team's organisational actions. It must not turn an article or a brief into a medical instruction. The organiser appoints those who stop serving, call the emergency service, meet the crew, show the way and pass information about the dish to the responsible specialists. The procedure is checked before the event together with the command centre, the venue and the caterer.

The plan records:

• the exact address of the venue, the entrance and the route for the emergency service;
• the employee who calls 112;
• the person who meets the crew and clears the passage;
• the catering manager who provides the composition, recipe and packaging of the product;
• the project manager who stops the disputed item;
• the procedure for keeping the matrix, the card and the data on actual servings for review;
• the way to inform the team of the confirmed fact without spreading information about the guest's health.

We do not include diagnostics, a list of symptoms, medicines or dosages in such an article. These decisions belong to medical care and trained specialists. For the project, the boundary of competence matters: the team quickly calls for help and ensures access, rather than making a diagnosis.

The backup is checked before the guests arrive. The coordinator must know the address, the entrance and the meeting point. The kitchen manager must be able to quickly find the data on the dish. The command centre must understand who stops serving and who issues the confirmed message.

Final catering acceptance

Final acceptance links the documents to what is actually on site. We use an internal checklist or an annex to the standard service acceptance. We do not call it a mandatory state "allergen act", because no such established form exists. The result of acceptance is recorded by the responsible coordinator before the line opens for guests.

Before opening, the following is recorded:

1. The final version of the menu and matrix.
2. All actual substitutions after approval.
3. Matching of names, codes and cards.
4. The status of special portions and the procedure for serving them.
5. Placement of utensils and measures against mixing them.
6. Staff access to up-to-date information.
7. The name of the catering manager in the kitchen and on the line.
8. The result of a short run-through and repeat tests.
9. Open restrictions, removed items and confirmed alternatives.

In the contract and annexes, it is better to record observable actions. The wording "take guests' allergies into account" does not explain what exactly the client is accepting. A working condition sounds more specific: the caterer provides a matrix of the established structure, reports changes, labels approved items, conducts briefings and participates in checking the line.

The allergen matrix is useful when the kitchen, catering manager, coordinator and serving staff work with the same version. Then a guest's question does not trigger a chain of guesswork. The team opens the confirmed record, checks the specific portion and honestly reports the limits of control.

Sources

• Eurasian Economic Commission: TR CU 022/2011 “Food products in terms of their labelling”
• ConsultantPlus: Rules for the provision of public catering services, Russian Government Resolution No. 1515
• ConsultantPlus: Federal Law No. 152-FZ “On Personal Data”
• UK Food Standards Agency: Allergen checklist for food businesses
• Food Safety Authority of Ireland: Safe Catering Pack, section on allergens
• University of Reading: Delivered Catering Allergen and Dietary Requirements Process Guide
• University of Bath: Allergies and dietary requirements in event catering
• EMERCOM of Russia: 112 - the emergency operational services call number