Back to Blog
    business-impact-analysis

    Business Impact Analysis: How to Run One That Works

    Dustin CollettOctober 24, 2026

    A business impact analysis (BIA) is a structured study of what happens to your company when a process, system or site stops working, and how fast each one has to come back. Ready.gov describes it as a way to predict the consequences of a disruption and gather the information you need to build recovery strategies. The output is a ranked list of what matters most, how long you can live without it, and what it costs you per hour or per day when it is down.

    This guide walks through the steps, a worked example, the manufacturing and compliance angles, and the mistakes we see most often with small and mid-sized companies in Southeastern Wisconsin.

    TL;DR

    • A BIA ranks your business processes by how badly an outage hurts, and sets a recovery target for each one.
    • It comes before the continuity plan. The BIA says what to protect; the plan says how.
    • Leadership sets the maximum tolerable downtime, not IT. IT designs backup and recovery to meet it.
    • Manufacturers must include operational technology (OT), contract penalties and safety, not just servers.
    • A BIA is a living document. Redo it when processes, systems or risks change.

    Table of Contents

    What a business impact analysis actually tells you

    A BIA answers four questions for every function in the company:

    1. What does this function produce, and for whom?
    2. What does it cost us, in dollars and in trust, when it stops?
    3. What does it depend on (systems, people, vendors, data, power, other departments)?
    4. How long can it be down before the damage becomes unacceptable?

    The fourth answer is the one that drives spending. Ready.gov's BIA worksheet frames operational impacts as things like lost income, increased expenses such as overtime or expediting, customer defection and delayed strategic initiatives, and has you record when in the outage each impact begins to bite. An outage that costs little in hour one and a great deal by day three needs a different response than one that hurts in minutes.

    BIA vs. business continuity plan

    People mix these up constantly, and it is one of the questions searchers ask most. The BIA is the diagnosis. The business continuity plan (BCP) is the treatment. Study material for the ISC2 certification puts it simply: before you write a continuity plan, you have to know what you are protecting and how fast it must come back, and that is the BIA's job.

    Business impact analysisBusiness continuity plan
    PurposeIdentify critical processes and the cost of losing themDefine how to keep running and recover
    OutputRanked processes, impact figures, recovery targetsProcedures, roles, contacts, alternate arrangements
    Who drives itLeadership with department headsLeadership, operations and IT together
    WhenFirstBuilt from the BIA's findings

    If you already have a plan but never did a BIA, the plan is probably built on guesses. Our guide to a business continuity plan for small businesses covers the next step once your BIA is done.

    The three stages of a BIA

    The other common question is about the three stages. Standard guidance, as summarized in ISC2 study material, runs like this:

    1. Identify mission and business processes and determine how critical each is. Start with what the business does, not with the technology.
    2. Identify the resources and dependencies needed to resume them. Systems, data, people, facilities, suppliers, internet and phone service.
    3. Identify recovery priorities and targets. This is where maximum tolerable downtime (MTD) and the recovery objectives come in.

    The FEMA business process analysis and BIA user guide pairs the BIA with a business process analysis that documents the activities and tasks people perform, which is a useful way to do stage one if nobody has ever written your processes down.

    How to run a BIA in six steps

    You do not need a consultant's binder. You need the right people in a room and a disciplined worksheet.

    1. Set the scope and name an owner

    Pick the whole company or one site or division. Assign one executive owner. Without an owner the BIA stalls at the first disagreement.

    2. List processes by department

    Sales entry, invoicing, payroll, production scheduling, quality inspection, shipping, client intake, trust accounting, patient scheduling. Aim for 10 to 30 processes in a small company. Ask department heads, not just IT, because a BIA is not only an IT exercise. It needs input from across the business to show how departments rely on each other.

    3. Quantify the impact over time

    For each process, estimate impact at one hour, four hours, one day, three days and one week. Count:

    • Lost revenue or delayed billing
    • Overtime, expediting and rework
    • Contractual penalties and late-delivery charges
    • Regulatory exposure
    • Customer defection
    • Safety risk to people

    Rough numbers beat blank cells. You can refine them later.

    4. Map dependencies

    For each process, list the applications, servers, cloud services, data sets, vendors and people it needs. Note the single points of failure: the one server, the one person who knows the ERP, the one internet circuit.

    5. Set recovery targets

    Assign each process a maximum tolerable downtime, a recovery time objective (RTO) and a recovery point objective (RPO). Our RPO vs. RTO guide explains how the two differ and how they translate into backup design.

    6. Rank, review and sign off

    Sort by criticality. Present the results to leadership and get a signature on the targets. That signature is what turns the document into a decision.

    A worked example: a 40-person Wisconsin machine shop

    The numbers below are illustrative, not data from a real client. They show the method.

    ProcessDepends onCost of 1 day downMTDTarget RTOTarget RPO
    CNC production schedulingERP, shop floor networkIdle machines, missed ship dates4 hours2 hours15 minutes
    Quoting and order entryERP, emailDelayed orders, some lost bids1 day8 hours1 hour
    PayrollCloud payroll, bank portalLate pay, employee trust3 days1 day24 hours
    Engineering drawingsFile server, CAD licensesProduction stalls on new jobs1 day8 hours4 hours
    Marketing websiteHostingMinimal5 days2 days24 hours

    The finding is not that everything needs the most expensive recovery. It is that two or three processes need very aggressive targets and the rest do not. That is how a BIA keeps you from overspending on low-priority systems and underspending on the ones that stop the floor.

    Who sets the downtime number

    A common misconception is that IT decides how long the company can be down. It does not. Maximum tolerable downtime is a business decision about what the company can afford to lose. ISC2 study guidance makes this point: leadership sets the tolerance, then IT builds the strategy to meet it.

    This matters in practice. If the owner says "we can be down two days" without ever pricing it, IT will build a two-day plan. If the BIA shows a two-day outage triggers a late-delivery penalty with your biggest customer, the number changes and so does the budget.

    Manufacturers: include OT, safety and contracts

    For manufacturers, a BIA that stops at email and the file server is incomplete. The NIST and NCCoE guidance on manufacturing cybersecurity notes that integrating IT and OT networks boosts productivity but also gives attackers a bigger landscape to work in. A BIA for a plant should therefore:

    • List the OT systems that control machinery (PLCs, HMIs, SCADA) as dependencies, next to the IT systems.
    • Record which IT systems feed production, for example the ERP that releases work orders to the floor.
    • Assign a safety impact where a failure could harm people or equipment.
    • Capture contract penalties, customer quality requirements and supplier obligations.

    NIST's more recent manufacturing guidance on responding to and recovering from a cyber attack describes cyber incidents as a real threat to safety, production and the economic performance of manufacturers. CISA's Critical Manufacturing Sector implementation guidance is a good companion: it helps you describe your current and target cybersecurity state and prioritize improvements, which is exactly where your BIA results feed in.

    If you are also looking at automation, our AI adoption guide for Wisconsin manufacturing covers how new tools change your dependency map.

    Law firms, dental practices and financial firms

    The method is the same, but the weighting differs:

    • Law firms: matter management, document management, trust accounting and deadline calendars often have very short tolerances, since a missed court deadline cannot be undone.
    • Dental and medical offices: scheduling, imaging and practice management systems drive daily revenue, and patient data adds regulatory obligations.
    • Financial firms: client portals, trading or custodial connections and compliance records need documented recovery targets that an auditor can read.

    In each case the BIA doubles as documentation. When an examiner, insurer or client asks how you know your recovery plan is adequate, a signed BIA is the answer.

    From IT checklist to risk management

    The BIA has grown beyond disaster recovery. NIST's report on using BIA to inform risk prioritization notes that BIA has historically set availability requirements for continuity, and that the process can be extended to understand the potential impacts of many kinds of loss. That is useful for a small company: the same dollar figures that justify a recovery target also help you decide which security investments come first.

    It also links to cyber planning. If ransomware is your most likely scenario, your BIA tells you which systems must be restored first, and our pieces on a ransomware response plan and on why ransomware recovery is a process, not a backup product show how to turn those priorities into a sequence.

    Common BIA mistakes

    • Treating it as a one-time project. The IRS policy on BIA is a reminder that regulated organizations maintain BIAs as ongoing obligations. An outdated analysis gives false confidence. Review it at least yearly and after any major change: new ERP, new plant, acquisition, new cloud service.
    • Letting IT fill it in alone. IT does not know what a late shipment costs or which client contract carries a penalty.
    • Skipping dependencies. The process may be critical, but the real risk sits in the one vendor or circuit behind it.
    • Setting every target to "immediately." If everything is priority one, nothing is. The ranking is the value.
    • Never testing the targets. A four-hour RTO on paper means nothing until you have restored from backup and timed it.

    Our perspective

    We have supported local organizations for years, and the pattern is consistent: companies that treat IT as a cost center buy backup as a checkbox and discover during an outage that nobody ever decided what had to come back first. The BIA is the cheapest way to fix that.

    We think of IT as infrastructure, like power or plumbing. You would not size a generator without knowing which loads must stay on. A BIA is that load list. It is also why we run our work on a fixed cost per user with a standardized, fully loaded stack: monitoring, backup and disaster recovery, security and documentation are built in, so recovery targets are not a negotiation over add-ons after something breaks.

    Our advice to owners is plain. Set the downtime tolerance yourself, in dollars, with your department heads. Make us prove we can meet it. Test it. Then put it on the calendar to revisit.

    , Dustin Collett

    Where we can help

    If you want a BIA that leads to something concrete, our IT & Security Assessment reviews your environment, finds the gaps between your business needs and your current setup, and gives you a prioritized plan. For a quick starting point, try the free IT risk score. If the BIA shows you need ongoing ownership of backup, monitoring and recovery, that is what our managed IT services provide, with 24/7 monitoring and defined SLAs at a fixed per-user cost.

    FAQ

    What is the difference between a BCP and a BIA?

    A BIA identifies your critical processes and the impact of losing them. A BCP is the action plan, built on those findings, for continuing operations and recovering. Do the BIA first, or the plan protects the wrong things.

    What are the three stages of a BIA?

    First, identify business processes and how critical each one is. Second, identify the resources and dependencies needed to resume them. Third, set recovery priorities and targets such as maximum tolerable downtime.

    How long does a BIA take for a small business?

    That depends on size and how well your processes are documented. A company with 20 to 100 employees can usually work through the department interviews and worksheet in a few weeks. The harder part is getting leadership to agree on dollar figures and sign off the targets.

    How often should we update it?

    At least annually, and whenever processes, systems or risks change. An outdated BIA can leave you with recovery targets that no longer match how the business really runs.

    Sources