When the Auditor Asked the Question
How a manufacturing company built a working business continuity plan after an audit exposed critical gaps
TL;DR
A precision manufacturing company faced audit failure when they couldn't answer "What happens if your facility is unavailable?" We discovered outdated documentation, conflicting assumptions, and no recovery procedures. After implementing a structured BCP with business impact analysis and quarterly testing, they passed their audit and validated the plan during a real power outage.
Table of Contents
When the Question Came
The owner runs a precision manufacturing company in Lake County. Fifty employees, tight tolerances, demanding customers. The kind of business where a day of downtime means missed deadlines and angry phone calls.
The annual audit was going fine until the auditor asked: "If your facility is unavailable for 24 hours, how do you keep operating?"
There was a silence in that conference room that told the whole story. Backups existed; insurance, too. But a documented business continuity plan? That was a different question.
"We need to fix this," the owner told me. "The auditor wants a real answer by next quarter."
The Situation
The Manufacturer makes precision components for medical devices. When they ship late, surgeries get delayed. That's the kind of pressure the owner deals with every day.
The basics were covered. Good IT infrastructure, cloud email, regular backups. The operations manager even had a binder from 2019 labeled "Disaster Recovery." Nobody had opened it in years.
Real vulnerabilities were exposed by the auditor's question. What if the building floods? What if key people are unavailable? Who makes decisions during a crisis? The answers weren't good enough.
More than documentation was needed. A plan that would actually work when things went wrong. And it needed to pass audit scrutiny.
What We Discovered
I talked to the owner, the operations manager, and the three people running the main departments. Asked them to walk through scenarios. Building fire. Ransomware attack. Key person unavailable. Even the pandemic hadn't been documented.
Everyone had different assumptions. The owner thought the operations manager had emergency contact lists; the operations manager, IT; IT, HR. Nobody had a current list.
The old documentation referenced servers that didn't exist anymore. Software they'd stopped using. People who'd left years ago. Completely useless.
I asked about critical functions. What absolutely has to keep running? This led to debates. Is daily reporting critical or just important? These distinctions matter when you're prioritizing recovery.
The Core Problem
The real issue wasn't that they lacked a plan. They lacked a framework for creating and maintaining one. Even a perfect plan becomes outdated in six months without a process to keep it current.
There was no clear ownership. Nobody's job description included business continuity. It was everyone's responsibility, which meant it was nobody's responsibility.
And there was no way to test their assumptions. You can write procedures all day. Until you try to execute them, you don't know if they work. Never had they conducted a tabletop exercise or recovery drill.
The auditor had exposed a gap that could shut them down. Not just fail an audit. Actually shut them down if the wrong thing happened at the wrong time.
Building the Solution
Business Impact Analysis
We started with a business impact analysis. Sat down with each department. Asked them to identify their critical functions and how long they could be down.
Order processing: 4 hours maximum. Production scheduling: 8 hours. Customer communication: 2 hours. Quality control documentation: 24 hours. These numbers drove everything else.
We mapped dependencies. Order processing needs the ERP system, internet access, and at least two trained people. Production scheduling needs the same ERP system plus access to inventory data. Everything connected.
Recovery Procedures
For each critical function, we documented recovery procedures. Not theoretical procedures. Actual steps someone could follow during a crisis.
"If the building is inaccessible, the operations manager calls the backup site. She logs into the cloud ERP from home. She notifies the production team via the emergency contact tree." Specific. Testable. Clear.
We identified a backup location. A small office space they could activate within 4 hours. Cloud access to all critical systems. VPN for secure connections. Nothing fancy. Just enough to keep critical functions running.
Communication Plan
We built a communication tree. Who calls who. In what order. With backup contacts for everyone. Stored in three places: cloud document, printed binder, and on everyone's phone.
We documented decision-making authority. If the owner is unavailable, the operations manager makes the call. If both are unavailable, the production manager steps in. No confusion about who's in charge during a crisis.
Testing and Maintenance
Here's where most plans fail. They get written and filed away. We built in quarterly testing. Ninety-minute tabletop exercises with department leads. Walk through scenarios. Find gaps. Update procedures.
We assigned ownership. The operations manager owns the BCP. She schedules tests, updates documentation, and reports to the owner quarterly. It's in her job description now. Not everyone's responsibility. Her responsibility.
The Outcome
Three months later, the owner presented the BCP to his auditor. Documented procedures. Tested recovery times. Clear ownership. Quarterly maintenance schedule. The auditor had no findings.
But the real test came six months after that. Power outage on a Tuesday morning. Lightning strike took out the transformer. Building would be dark for 8 hours minimum.
The operations manager activated the BCP. Called the backup site. Notified the team. Critical staff worked from home and the backup location. Order processing continued. Production scheduling continued. Customers got their parts on time.
The plan worked. Not perfectly. They found gaps during the real event. But it worked well enough to keep the business running. That's what matters.
They updated the plan based on what they learned. Added a few procedures. Clarified some steps. Made it better. That's how a living BCP works.
Lessons from the Trenches
Keep It Simple
The owner's first instinct was to build a comprehensive plan covering every possible scenario. I talked him out of it. Start with critical functions. Get those working. Add complexity later if needed.
The plan that works is better than the perfect plan that sits on a shelf. Simple procedures that people can actually follow beat elaborate frameworks every time.
Test It Regularly
The quarterly tabletop exercises revealed gaps they never would have found otherwise. Contact lists get outdated. People change roles. Systems get upgraded. Testing keeps the plan current.
Ninety minutes every quarter. That's all it takes. Walk through a scenario. Find what doesn't work. Fix it. Repeat.
Assign Clear Ownership
Before the operations manager took ownership, the BCP was everyone's job. Which meant it was nobody's job. Now it's in her job description. She's accountable. She makes sure it gets done.
That doesn't mean she does everything. But she coordinates. She schedules. She follows up. Someone has to own it.
Focus on Recovery Time
The BIA revealed their real requirements. Order processing needs to be back in 4 hours. Not "as soon as possible." Four hours. That specific number drove their backup site decision, their cloud strategy, everything.
Vague goals produce vague plans. Specific recovery time objectives produce actionable procedures.
Document Real Procedures
The old documentation said "restore from backup." That's not a procedure. The new documentation says "The operations manager logs into the backup portal at backup.techparts.com, selects the most recent snapshot, clicks restore, waits for confirmation email." That's a procedure.
If someone can't follow your documentation during a crisis, it's not documentation. It's just words on a page.
If You Need to Build a BCP
Start with a business impact analysis. Talk to whoever runs each department. Ask them what functions are critical and how long they can be down. Get specific numbers.
Document recovery procedures for those critical functions. Not theory. Actual steps. Test them. Find what doesn't work. Fix it.
Build a communication plan. Who calls who. In what order. With backups for everyone. Store it in multiple places.
Assign ownership. Put it in someone's job description. Make them accountable for keeping it current.
Test it quarterly. Tabletop exercises work fine. Walk through scenarios. Update procedures based on what you learn.
Don't try to be perfect. Try to be functional. A simple plan that works beats a complex plan that doesn't.
If you're facing an audit or if you just want to be prepared, we can help. We've built BCPs for manufacturers, healthcare providers, professional services firms, and distributors. We know what works and what doesn't.
Talk to us. We'll help you build a plan that actually works when you need it. Not just a plan that looks good on paper.
For more information on business continuity planning, check out these resources: