Critical Tracking Events (CTEs): FSMA 204 Activities Explained

Do not classify events by ERP transaction name alone

The rule identifies harvesting, cooling before initial packing, initial packing of certain raw agricultural commodities, first land-based receiving of food obtained from a fishing vessel, shipping, receiving and transformation as Critical Tracking Events. The definitions and conditions in Subpart S determine whether a real operation qualifies. A warehouse button labelled “receipt” is not, by itself, proof that the regulatory receiving event applies; nor does an internal “production complete” label settle whether transformation occurred.

Test event-to-event continuity

Walk the process with operators and trace a representative product from physical movement to its record. Note who controls the food, what changes, where the activity occurs, which identifiers are available at that moment and which record is created. Compare the observed process with the exact event definition. If the site performs several activities, map each separately—even if one software transaction captures multiple fields.

Manage exceptions without losing the audit trail

For example, a distributor may receive a lot, store it and ship cases onward without transforming the food. Its event map should distinguish receiving from shipping and show how the lot identifier and required KDEs are retained across both. If the distributor later combines, manufactures or otherwise transforms product, reassess the operation and the input-output traceability relationship rather than reusing the storage-only map.

For each event, retain a trigger definition, applicable food scope, required KDE list, record owner, source system, downstream handoff, exception route and successful test. Include partial shipments, cancelled transactions, returned product, missing supplier data and corrections. Corrections should preserve a traceable history; silently overwriting the original value can make it impossible to explain what happened.

Event mapping worksheet: minimum useful detail

For each event, document the physical trigger in plain language, the exact rule definition, the product categories assessed, the required data list, the person who knows the facts at the time, the record generated and the next process that uses it. Include a diagram of the real workflow where the operation is complex. This reduces the risk that staff classify an event based on a software screen or a department name.

Validate the map with at least two perspectives: operations confirms that the workflow matches reality, and quality/regulatory confirms that the event interpretation and required data are supported by the rule. IT then verifies that the system captures and exports the agreed data. No one function can fully validate the map in isolation.

When the operation changes, update the map before the new process becomes routine. A new packing line, third-party warehouse, rework route or product format can change which records are generated and how lot relationships are maintained.

Event review meeting: a practical agenda

Bring the process owner, quality/regulatory representative and system owner together. Start with a physical walk-through and ask the operator to show where the food is, what happens to it, what record is created and which identifier is visible. Then compare the observed steps with the event definition and data requirements. This avoids designing the map from an old procedure that no longer reflects the operation.

For each event, ask what could make the record incomplete: an offline step, an outsourced activity, a shift handover, a manual override, a late supplier document or a system that uses a different identifier. Agree on an exception route and an evidence owner. Do not treat “we will fix it later” as a control unless the procedure defines how the affected record is identified and closed.

Finish by selecting one test transaction and following it into the next event. The meeting is not complete until the group has confirmed the record link works or assigned a corrective action with a clear owner and retest.

Evidence hierarchy for event decisions

Use the regulation as the primary authority for the event definition and required records. Use FDA explanatory material to clarify how the agency describes implementation, while checking the document’s status. Use the company’s process map, work instructions and sample records to establish what actually happens at the facility. These sources answer different questions and should not be treated as interchangeable.

If the physical process and the written procedure disagree, do not choose whichever is easier. Record the discrepancy, confirm the actual workflow with the process owner and decide whether the procedure or operation needs correction. Then reassess whether the discrepancy affected previous records or event classifications.

Keep the final event decision concise: facts, provision, conclusion, record requirements and reviewer. A clear decision is easier to maintain than a long narrative with no explicit conclusion.

Example: the same facility performs several activities

A facility can receive, store, repack and ship a covered product. Do not force all these steps into one generic “warehouse event.” Map each actual activity, determine which regulatory event definitions apply and identify the data generated at each stage. If an activity does not meet a defined CTE, document the rationale rather than inventing a new regulatory event.

Where one software transaction combines operational steps, the underlying record should still make the relevant event and lot relationships understandable. A combined screen is not a problem by itself; the risk is that the system obscures which required data relate to which event.

Review the map whenever the facility adds an activity, changes process flow or starts handling a new product form.