Brewery continuity and recall readiness for small teams

Most small breweries don't fail during a crisis because they lack good people. They fail because the response lives inside one person's head, and that person is either off-shift, on vacation, or elbow-deep in a tank when the call comes in. A distributor reports foreign material in a can. A fermenter blows a seal at 2 a.m. The city issues a boil-water notice mid-brew. And suddenly a five-person crew is improvising a recall while trying to remember which lots went where.

A real brewery continuity plan isn't a binder that sits on a shelf until an auditor asks for it. It's a working system — a short risk register, tiered runbooks, and a couple of tabletop scripts you actually rehearse. The goal isn't to predict every disaster. It's to make sure that when something breaks, the first 30 minutes don't get wasted figuring out who's in charge.

This is the connective tissue between operational work you've probably already done. Your traceability, your QC sampling, your maintenance program — continuity planning is what ties them together so they function under pressure instead of falling apart.

Why continuity plans quietly rot in small breweries

The pattern is almost always the same. Someone writes a plan because a distributor or insurer asked for one. It's thorough — twelve pages, contact trees, decision matrices. Then it gets saved to a shared drive and never touched again.

Two years later, half the phone numbers are dead, the "recall coordinator" quit, and nobody remembers the plan exists. When an actual incident hits, the crew does what people do under stress — they wing it. Sometimes that works. Often it doesn't, and the damage compounds because early decisions were made without the right information.

The root problem is that most plans are written for a large-company reality that doesn't match a small brewery. A regional producer might have separate people handling quality, ops, legal, and comms. In a 4,000-barrel brewhouse, the same person covers three of those roles and also drives the delivery van on Fridays. A plan that assumes clean role separation is a plan that assumes staff you don't have.

The other issue is that continuity gets treated as a single document instead of a set of connected systems. Recall readiness depends on lot tracking. Downtime response depends on maintenance history. Contamination response depends on your QC data. If those pieces aren't already solid, no continuity binder will save you — it'll just point at gaps you never filled.

Start with a compact risk register, not a novel

The instinct is to catalog everything that could possibly go wrong. Resist it. A risk register that lists 60 scenarios is one nobody will maintain. What actually works for a small team is a tight list — usually 10 to 15 risks — scored on two axes: how likely it is, and how badly it hurts if it happens.

Here's the structure that tends to survive contact with reality:

Notice a few things. Every risk has one named owner — not a committee. Every risk points to a runbook, so the register isn't just a worry-list, it's an index. And the scoring keeps you honest about where to spend effort. A high-likelihood, moderate-impact risk like "key person out sick" deserves as much attention as a rare-but-catastrophic one, because it happens constantly and almost nobody plans for it.

Worth flagging: breweries almost always overweight the dramatic risks (recall, fire, flood) and underweight the boring ones. The thing that actually disrupts small producers most often isn't a contamination event — it's a cascade that starts with a mundane equipment failure and spirals because there was no plan for it. Which is exactly why your continuity work should sit on top of a real preventive maintenance and reliability framework, not float above it disconnected from operations.

Tiered runbooks: match the response to the severity

The single biggest mistake in small-brewery continuity is treating every incident like a full emergency. If a stuck fermentation triggers the same all-hands panic as a recall, people burn out and start ignoring the process entirely. Tiering fixes that.

1. 1
   Tier 1 — Public safety or regulatory exposure. Contamination, foreign material, anything that could reach a consumer or trigger a reportable event. This is where the recall machinery kicks in. Decision authority moves up immediately; the owner or designated coordinator is looped in within the first call.
2. 2
   Tier 2 — Production or continuity threat. Batch loss, line breakdown, a supply disruption that endangers your schedule. Serious, costs money, but contained inside the building. Handled by shift and production leads with a defined escalation trigger if it worsens.
3. 3
   Tier 3 — Operational friction. Staffing gaps, minor equipment issues, a delivery vehicle down. Real problems, but routine. These get lightweight runbooks — mostly checklists and coverage plans.

Each runbook should fit on one or two pages and answer the same four questions in the same order: Who leads? Who gets notified? What are the first three actions? When do we escalate? Consistency across runbooks matters more than exhaustive detail, because in a crisis people default to muscle memory. If every runbook opens with "who leads," nobody wastes time hunting for it.

A Tier 1 recall runbook in particular should link straight to your lot-tracking and traceability records. The runbook's job isn't to re-explain how traceability works — it's to say go here, pull this, identify affected lots, notify these parties in this sequence. The faster you can define the scope of a recall, the smaller and cheaper it stays.

Here's a quick visual of the tiered runbook workflow.

The runbook's job isn't to re-explain how traceability works — it's to say go here, pull this, identify affected lots, notify these parties in this sequence. The faster you can define the scope of a recall, the smaller and cheaper it stays.

The recall runbook deserves special attention

Recalls are the one scenario where speed and precision directly determine cost. A recall where you can isolate three specific lots is annoying. A recall where your records are fuzzy and you have to pull everything you shipped that month is a business-threatening event.

A workable first-hour sequence for a Tier 1 product-safety incident:

1. 1
   Log the report. Time, source, product, code date, nature of complaint. Written down immediately, not reconstructed from memory two hours later.
2. 2
   Freeze the suspect inventory. Put a hold on anything matching in your warehouse, taproom, and cold storage before it moves.
3. 3
   Trace the lot. Pull the batch record and packaging log. Identify every lot that shares the same risk — same brew, same tank, same shift, same ingredient batch.
4. 4
   Map the distribution. Where did those lots go? Which accounts, which distributors, how many units.
5. 5
   Assess severity. Is this a quality complaint or a genuine safety issue? This determines whether you're doing a voluntary market withdrawal or a full recall with regulatory notification.
6. 6
   Notify in sequence. Distributor, then affected accounts, then regulators if required. Consistent messaging, one designated spokesperson.
7. 7
   Document everything. Every call, every decision, every quantity. This record is what protects you afterward.

The quiet failure point is step 3. Breweries that treat QC as a checkbox instead of a data trail can't trace confidently, so they over-recall out of caution. Teams that run a real QC sampling and prevention program not only catch problems earlier — they can define recall scope tightly because they have the sampling records to prove which lots were clean. Prevention and traceability are what make a recall survivable instead of ruinous.

Tabletop exercises: the part everyone skips

A plan you've never tested is a guess. Tabletop exercises are how you find out that the "recall coordinator" is also out every Wednesday, or that nobody actually has admin access to the distributor portal.

You don't need a consultant or a full day. A useful tabletop is 45 minutes, run quarterly, using a simple script. Someone reads a scenario, the team walks through their real response using the actual runbooks, and someone notes where things stall.

A basic script looks like this:

1. 1
   The injection

   "It's Saturday, 4 p.m. A taproom guest says a can of your flagship IPA had visible sediment and an off smell. The person who normally handles complaints is at a wedding. What happens now?"

2. 2
   First round of questions

   Who takes over? Where's the runbook? Can we find the batch record for that code date right now — not in theory, actually pull it up?

3. 3
   Escalation prompt

   "Two more complaints come in from a distributor account by Monday. Same product, different lot. Does that change your response tier?"

4. 4
   Debrief

   What worked? What took too long? What did we assume we had access to but didn't?

The value isn't in getting the "right" answer. It's in surfacing the gaps while the stakes are zero. The first tabletop almost always reveals the same category of problem: single points of failure. One person knows the passwords. One person understands the lot-numbering logic. One person has the distributor's cell number. The exercise turns those invisible dependencies into fixable action items.

“

Run the tabletop with the actual runbooks open and capture action items in a shared task list immediately so fixes don't vanish.

Run the scenarios that match your top risks from the register. Rotate who plays the lead so knowledge spreads. Keep the debrief notes — the delta between your first tabletop and your fourth is the clearest sign that your continuity plan is actually alive.

Where the whole system connects (and breaks)

Continuity planning fails when it's built as a standalone project. It works when it sits on top of the operational data you're already maintaining.

Your maintenance logs tell you which equipment risks are real and how fast you can recover. Your QC records determine how confidently you can trace a contamination event. Your lot-tracking system defines how tightly you can scope a recall. Your shift-handoff records are what let a Tier 2 problem get resolved by whoever's on shift instead of waiting for the one person who was there when it started.

The continuity plan is the layer that says, in a crisis: pull from here, decide like this, notify in this order. If any of those underlying systems are weak, the crisis exposes it. Breweries that already have structured operational records recover faster — the information exists and can be retrieved under pressure, rather than being reconstructed from memory and text-message threads.

This is also where centralizing your records genuinely pays off. When batch records, QC results, maintenance history, and distribution data live in separate spreadsheets, shared drives, and someone's notebook, tracing a lot at 4 p.m. on a Saturday becomes an archaeology project. When they're connected in a single operational system, step 3 of the recall runbook goes from "spend two hours reconstructing which lots shared a tank" to "run the query." The plan doesn't create that capability — your data model does. The plan just uses it well.

When a full continuity program makes sense — and when it's overkill

This full approach makes sense when:

1. 1
   You're self-distributing or in wholesale, where a recall touches multiple accounts
2. 2
   You're producing above roughly 2,000–3,000 barrels and losing a batch actually hurts
3. 3
   You have a co-packing relationship, which adds a whole layer of quality-escape risk outside your walls
4. 4
   Your team is small enough that key-person risk is genuinely severe

This is probably overkill when:

1. 1
   You're a taproom-only nano operation selling everything on-site with same-week production, where recall scope is naturally tiny
2. 2
   You have fewer than three people and the "plan" is realistically just a shared understanding

Who should not skip this entirely: Anyone who packages and ships product. But if you're a brand-new brewery still fighting to get consistent batches out the door, don't spend three weeks building tabletop scripts before your core production is stable. Get the fundamentals — traceability, QC, maintenance — reliable first. The continuity layer is only as good as what it sits on.

A real scenario

A mid-sized production brewery — around 6,000 barrels, self-distributing across two states, seven full-time staff — got a distributor call about hazy sediment in a pale ale. No plan tiering, no runbook. The head brewer was out of town.

What followed was three days of scrambling. Nobody was sure which lots shared the affected tank because batch records were split between a whiteboard photo and two spreadsheets. Out of caution, they pulled roughly six weeks of that SKU from accounts — far more than was actually at risk. The direct cost of destroyed and credited product landed somewhere around $18k–$22k, plus strained distributor relationships and a week of lost production time managing the fallout.

Afterward they built the compact version of what's described here: a 12-item risk register, three tiered runbooks, and a quarterly tabletop. Eight months later a similar complaint came in — different SKU, same category of issue. This time the on-shift lead pulled the runbook, froze inventory within the hour, traced the exact two lots that shared the tank and ingredient batch, and confirmed via QC records that surrounding lots tested clean. The recall covered those two lots only. Recovered product loss was a few hundred dollars. The whole thing resolved in under two days, and the distributor's takeaway was that the brewery had it together.

The difference wasn't better luck or better people. It was that the second time, the response didn't have to be invented on the spot.

Bringing it together

A brewery continuity plan for a small team should be embarrassingly practical: a short risk register that names owners, tiered runbooks that fit on a page, a recall sequence tied to your actual lot data, and tabletop exercises you run often enough that the muscle memory sticks. It doesn't need to be long. It needs to be usable at 4 p.m. on a Saturday by whoever happens to be on shift.

The breweries that weather incidents well aren't the ones with the thickest binders. They're the ones whose underlying systems — maintenance, QC, traceability, handoffs — are solid enough that the continuity plan has something real to stand on. Build those first, connect them, then rehearse the response. That's what turns a crisis from a business-threatening event into a bad afternoon.