Most businesses can list their systems. Few can say with any confidence which ones would actually sink the business if they went down for a week. A business impact assessment closes that gap. It ranks your operations by what a disruption would cost, not by gut feeling. This guide covers how to run one, not just what the term means.
Table of Contents
Why “everything is critical” is the wrong answer to a business impact assessment
Ask most teams which systems matter most and the answer is usually “all of them.” That answer is not useful. It gives recovery planning nothing to work with. NIST’s contingency planning guide exists specifically to force a sharper ranking, one that separates what cannot wait from what merely feels urgent in the moment.
Running a business impact assessment: NIST’s three steps
- Determine recovery criticality. For each business process, work out what a disruption would mean. Lost revenue, missed deadlines, regulatory exposure, reputational damage. Be specific rather than vague.
- Identify resource requirements. List exactly what each critical process needs to keep running or to recover quickly: systems, staff, data, suppliers, physical space.
- Identify recovery priorities. Rank everything against everything else. This step is where the real value sits, since it is what turns a long list into an actual plan.
Skip the ranking step and you have produced an inventory, not an assessment.
Setting real recovery targets
| Term | The question it answers |
|---|---|
| Recovery Time Objective (RTO) | How long can this be down before it seriously hurts? |
| Recovery Point Objective (RPO) | How much data can we afford to lose? |
| Maximum Tolerable Downtime (MTD) | At what point does this threaten the business itself? |
Setting these numbers is uncomfortable. Nobody wants to admit a system can be down for four hours rather than four minutes. But a number you can defend is far more useful than an aspirational one nobody can actually deliver against.
Where NCSC’s guidance backs this up
NCSC’s Cyber Assessment Framework makes the connection explicit. Incident response plans should be “integrated with wider organisational business plans,” not treated as a standalone IT document. A business impact assessment is the bridge. It gives an incident response plan the ranked priorities it needs to function when something real happens, rather than treating every system as equally urgent.
How a business impact assessment differs from a vulnerability assessment
Do not confuse the two. A vulnerability assessment looks for technical weaknesses that could be exploited. A business impact assessment assumes something has already gone wrong and asks what that costs. One is about exposure. The other is about consequence. A mature security programme needs both feeding into the same priorities.
A practical first attempt
Do not wait for a perfect, formal process. List your ten most important systems. For each, estimate how long you could survive without it, and what you would need to bring it back. That rough draft, done in an afternoon, already beats no assessment at all. Refine it later, once the basic shape is right.
Feeding the results into what matters
An assessment that sits in a drawer changes nothing. Once ranked, the results should drive your backup schedule, your incident response plan, and your testing priorities. The systems ranked most critical deserve the tightest recovery targets and the most frequent testing, since those are exactly the assets a real disruption would hit hardest.
Common mistakes in a business impact assessment
The first mistake is skipping input from the people who run each process. Management often guesses wrong about what a specific outage would really cost, since they are rarely the ones dealing with it hands-on.
The second mistake is writing the assessment once and filing it away. Systems change. Suppliers change. What counted as critical two years ago may no longer hold. An assessment nobody revisits quietly stops describing the business it was meant to protect.
The third mistake is treating the exercise as a compliance box to tick rather than a planning tool. An assessment produced only to satisfy an auditor rarely gets used for anything else, and the business loses most of its value.
Keeping the assessment alive
An assessment done once and never touched again stays accurate only for as long as the business stays the same, which is rarely very long. Set a review date, ideally tied to your annual planning cycle. Revisit it sooner if you add a major system, change key suppliers, or restructure a critical process. A stale ranking is worse than no ranking at all, since it hands you false confidence instead of a visible gap.
Who should run the assessment
A single IT team producing the whole assessment alone usually gets it wrong. They understand systems, not necessarily the business consequence of losing them. Bring in a representative from each function being assessed. Finance can put a real figure on lost revenue. Operations knows which suppliers cannot be swapped out quickly. Legal knows which regulatory deadlines cannot slip without real consequences following. That spread of input produces a far more accurate picture than IT working alone, and it builds buy-in across the business for whatever the ranking turns out to be.
Frequently asked questions
How is a business impact assessment different from a risk assessment?
A risk assessment asks what could go wrong and how likely it is. A business impact assessment assumes it already has, and asks what that costs and how fast you need to recover.
Do we need external help to do this properly?
Not for a first pass. Internal department heads can produce a workable draft on their own. Outside expertise helps refine the figures later, once the basic structure exists and needs sharpening rather than building from scratch.
How long should a proper assessment take?
A small business can produce a useful first version in an afternoon. Larger, more complex organisations need longer, sometimes several weeks across multiple departments and several rounds of review before the ranking settles.
Does this replace penetration testing?
No. It tells you what matters and how fast you need it back. It says nothing about whether an attacker could reach those systems. Our guide on judging a provider’s penetration testing methodology covers that separate question.
Does a business impact assessment satisfy compliance requirements on its own?
Not entirely, though it supports several of them. ISO 22301, the international standard for business continuity management, requires a business impact analysis as a named step, and the same underlying work strengthens a Cyber Essentials or ISO 27001 submission even where it is not explicitly required. Treat it as good practice that happens to help with audits, not a box-ticking exercise done purely for one.
What happens if we skip this step entirely?
Your incident response plan ends up guessing at priorities instead of knowing them. That guesswork is exactly what turns a manageable incident into a much longer, costlier one.
If you want to know whether the systems your business impact assessment ranks as critical would hold up against a real attack, Aardwolf Security’s testing can tell you. Get in touch to talk through your priorities, or see our full penetration testing services.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
