FSMA 204 Requirements Explained: Records, Events and Scope

Distinguish legal requirements from internal controls

For implementation, translate each applicable provision into a testable requirement. A register should record the CFR citation, the covered food or event, the required data, the party responsible, the record source, the retention rule, and the test used to verify completeness. Separate what the rule expressly requires from an internal control adopted to reduce error. This prevents a company policy—such as a preferred barcode format—from being mistakenly described as a universal FDA mandate.

Build an evidence-based requirements register

Use the event definition in the regulation before selecting fields. The required KDE set differs by event, and some details depend on whether the activity involves a farm, a fishing vessel, initial packing, receiving, shipping or transformation. A single “FSMA fields” spreadsheet may be useful as an index, but it should link to event-specific specifications rather than imply that every field applies to every transaction.

A realistic acceptance test

For every requirement, identify objective evidence: an actual record, system configuration, approved procedure, training record, export sample or documented test. “The ERP can do this” is not evidence that users enter complete data or that the records can be retrieved correctly. “The supplier sends it” is not enough unless the company can demonstrate how the data are received, validated, linked and corrected when incomplete.

Acceptance test: choose a real or controlled test lot, select a relevant event, and verify the required data from the source record through the traceability export. Record the tester, date, test case, expected result, actual result, discrepancy and closure evidence. Repeat with an exception case such as a split shipment, a rejected receipt or a changed lot relationship.

Requirements register: recommended columns

A practical register can use these columns: requirement ID; CFR section; food or product family; event trigger; required KDEs; record owner; source document/system; retention rule; downstream data-sharing step; validation check; exception route; test evidence; and review date. The register is an internal management tool, not an FDA-prescribed form. Its value is that each legal obligation is connected to a real operational control and a piece of evidence.

Keep legal interpretation and system design separate. For example, the rule may require a data element for a particular event; the company may choose a dropdown list or barcode scan to reduce entry errors. Document the regulatory requirement in one field and the internal control in another. If the software changes, the control can be redesigned without losing the explanation of why the data are required.

Use status values that mean something: not assessed, applicable, not applicable with rationale, implemented, tested, and corrective action open. Avoid a green check mark with no evidence link. A reviewer should be able to open the test record or source document and confirm that the control works.

Change control for requirements and system design

When a regulatory source or internal process changes, perform an impact review rather than updating one checklist in isolation. Identify affected product families, CTE mappings, KDE definitions, supplier/customer interfaces, record exports, procedures, training and test cases. Record which components were reviewed and why a change was or was not necessary.

Before approving a system change, test the affected path using representative data and an exception case. Confirm that the updated field is captured at the correct event, appears in downstream records where required, retains the intended identifier and remains present in the export. Keep the prior configuration or change evidence according to the organisation’s document-control process.

For requirements marked not applicable, keep the rationale and review trigger. “Not applicable” should be a reasoned outcome tied to the food, activity and rule, not an empty cell or a copied answer from another site.

How to review requirement completeness

For each applicable requirement, compare the written procedure, system configuration, actual transaction record and exported evidence. These four layers should agree. A procedure may say a field is required while the system allows it to be omitted; a system may capture it while the export drops it; or an export may show the field without identifying the source. Each mismatch needs its own finding and corrective action.

Use change impact analysis to identify which tests must be repeated after a product, process, supplier or system change. The test should be proportionate to the change but should include any interface where the required identifier or KDE could be lost. Keep a record of why a test was selected and the evidence that it passed.

When an item is not applicable, record the facts and provision supporting that conclusion. This makes the register auditable and prevents a blank field from being mistaken for an assessment that was never performed.

Walk-through: prove one requirement end to end

Select one requirement from the register and follow it from the legal text to a real transaction. Confirm the requirement was correctly interpreted, the procedure describes the correct trigger, the system captures the expected value, the record links to the correct lot and the export retains the value. Save the source citation and test evidence together so the conclusion can be reproduced later.

If any layer disagrees, record the gap precisely. For example, the procedure may require a value but the system field may be optional; the field may be captured but excluded from the export; or the export may include a code with no lookup. Assign the correction to the layer that caused the failure and test the full path again.

This end-to-end method is more reliable than reviewing the register as a list of green status cells. It tests whether the stated control operates in practice.