Compliance Guide

FSMA 204: the FDA gave you until 2028. Your retailer didn’t.

The FDA’s Food Traceability Rule — FSMA Section 204 — now carries a compliance date of July 20, 2028, a 30-month extension from the original January 2026 deadline. The rule itself didn’t change. And for many brands, the binding deadline isn’t the FDA’s at all: major retailers have rolled out their own traceability programs with requirements already in effect.

What the rule requires

If you manufacture, process, pack, or hold foods on the FDA’s Food Traceability List(FTL) — a list that includes cheeses, shell eggs, many fruits and vegetables, seafood, nut butters, and ready-to-eat deli items — FSMA 204 requires you to:

  • Maintain a written Traceability Plan.
  • Assign Traceability Lot Codes to FTL foods at specific points.
  • Capture Key Data Elements (KDEs) at every Critical Tracking Event(CTE) — receiving, transforming, packing, shipping.
  • Produce those records to the FDA within 24 hours of request.

The rule doesn’t mandate specific technology. But the 24-hour retrieval requirement and the multi-party data-sharing reality make disconnected spreadsheets impractical for most covered operations. In practice, compliance means clean, connected lot-level data across your supply chain.

Why the extension isn’t a reprieve

Three reasons the 2028 date shouldn’t slow you down.

First, retailer programs are already live — several major grocers built their own traceability requirements with earlier effective dates, and your supplier agreement doesn’t wait for the FDA.

Second, the data work is the long pole: standardizing lot codes, connecting receiving to shipping records, and getting co-packers and distributors passing KDEs cleanly is a multi-quarter effort for a brand whose records live in three systems that disagree.

Third, the same lot-level data discipline FSMA demands is what GS1 Sunrise 2027’s 2D barcodes carry — the two deadlines converge on the same fix: a product master and lot-tracking layer that’s actually right.

Where brands actually fail

Not at the plan-writing stage — at the data layer underneath it. Lot codes formatted six different ways across receiving, production, and shipping. KDEs that exist on paper BOLs nobody can retrieve in 24 hours. Product master records where the same item carries different identifiers in the ERP, the GDSN pool, and the co-packer’s system. A traceability plan written on top of that data is a document, not a capability.

The blast radius of a recall is set by how well that lot genealogy is linked before the call comes in — not after. The Blast Radius demo models three scenarios on Cinderhaven’s synthetic data: one contained lot, one shared-ingredient lot that expands to 47× the scope, and a packaging lot crossing all product lines. The difference between Scenario A and Scenario B isn’t ingredient risk — it’s whether the genealogy exists.

What to do, in order

First, determine your FTL exposure — which of your products (and which of your ingredients) appear on the Food Traceability List. Second, audit the lot-code and KDE data you’d actually be asked to produce: can you trace one lot from receipt to shipment today, in under 24 hours? Third, fix the data layer — standardized formats, connected records, validation at the points where data enters.

That second step has a fast, fixed-cost version: the Data Health Snapshot — send your product master or transaction extract, get written findings with the defects, the cost, and a top-10 fix list in one week. The full Product Data Health Audit includes FSMA 204 exposure assessment by SKU.

Start with a conversation.

Thirty minutes. Bring your product list; I’ll tell you your likely FTL exposure and what a scoped readiness assessment looks like. No deck, no obligation.

Get in Touch