Business impact analysis, or ‘BIA’, is a process usually associated with business continuity and operational resilience – areas that have been on many organisations’ minds following recent Cloud service provider outages.
It involves identifying your key business activities, then determining how quickly, in what order, and what resources you need to restore them to minimum functionality or availability in the event of a disruption.
How does that relate to risk assessments? What are some practical ways to tackle a BIA? And how can you secure top management support for this activity?
We put these questions, and many others, to Andrew Pattison, our head of GRC (governance, risk and compliance) consultancy, Europe.
In this conversation, Andrew included plenty of real-life examples. He also linked BIAs and risk management to legal requirements like DORA (Digital Operational Resilience Act) and the NIS 2 (Network and Information Security Systems) Directive.
What do you like about BIA?
BIA is probably my favourite type of risk assessment. I love how it’s such a simple process, where you put information in, turn the handle and get information out the other end.
I ask the client questions like:
- What are your key processes?
- What are your key resources?
- What are your dependencies?
- If those resources are disrupted, what’s the impact over time?
If BIA looks at the business impact of an operational disruption, can you really consider it a type of risk assessment?
BIA and risk assessment are separate processes, but they share similar ‘DNA’ – think of them as close cousins.
Also, you need both if you’re doing business continuity or operational resilience. Particularly if you’re aligning yourself to best practice like ISO 22301. Risk assessment looks at the risks, while BIA looks at the impacts – how the business would be affected if it lost access to a key resource, regardless of the reason for that disruption.
However, the processes are similar. You ask the client simple questions, so you get clear answers that inform the plan of action. I never tell the client what they should do – I just enable them to figure this out for themselves.
They’re also linked in that risk assessments look at risks related to your business objectives – what might prevent you from fulfilling your objectives. Meanwhile, BIA is about making sure you’re still able to fulfil your objectives.
In these respects, I consider BIA a type of risk assessment, but they’re not interchangeable.
You say “clear” answers, but the process surely involves a lot of supposition. How do you handle this lack of certainty?
Here’s an analogy. I wear a fitness tracker – a pedometer – around my wrist. Because it’s so visible, people are constantly telling me how useless it is, in the sense that it doesn’t accurately count your steps.
The thing is, I don’t need it to be accurate; I need it to be consistent.
Suppose my counter is telling me that I’ve walked 11,000 steps today, but only 10,000 yesterday. So long as that tracker works consistently, I know that I’ve taken 10% more steps today than I did yesterday. And that’s really all I need to know.
I’m not saying you don’t need accurate risk assessments and BIAs, of course, but consistency is far more important than 100% accuracy. A significant output of both processes is that you get a prioritised plan and approach.
What are the outputs of a BIA?
The big one is that it tells you how you prioritise your recovery plan [business continuity plan, or ‘BCP’] – what systems or other resources you need to bring back up first.
Those priorities are informed by your:
- Maximum acceptable outage [‘MAO’, also known as ‘maximum tolerable downtime’ or ‘MTD’];
- Recovery time objectives [‘RTOs’]; and
- Recovery point objectives [‘RPOs’].
To figure out those numbers, you’ll need a matrix with different levels and types of impact, for example:
- Financial
- Operational
- Reputational
- Environmental
- Health and safety
Whatever works for your organisation! You just need a consistent approach to determining what level of impact is unacceptable – anything above ‘level 3’ or ‘moderate’, for example.
Suppose an organisation determined that after, say, five hours, the impact becomes intolerable. What should it do next?
That’s a really important step: defining the time period after which you truly have a problem – that you can’t achieve what you as an organisation need to get done.
With an MAO of five hours, you might then set your RTO at four hours. The time at which you need to have your service up and running again so you don’t hit that MAO.
Your next step is to look at what that service or system is, so you can understand its dependencies. What resources would you need to make sure you can recover in four hours?
Because of all these interdependencies, things can get complicated. But this exercise is really important for making sure your priorities are right.
This is assuming recovery of the original systems. What if you also looked at workarounds, so that you can set more lenient MAOs and RTOs?
Right, that’s something people often overlook. I have conversations like this in workshops:
- Me: “How long can you function without your email?”
- Client: “Oh, I look at it every five minutes.”
- M: “Right, so what are you doing every five minutes?”
- C: “I produce [this] information, which I send to [John].”
- M: “Where’s John?”
- C: “He sits across my desk.”
- M: “OK, so could you hand him that information physically?”
- C: “Yes, I could.”
- M: “Right, so if you used that workaround, how long could you survive without your email?”
- C: “Oh, probably a week.”
That’s a bit of an extreme example, but it demonstrates the point: BIA is about looking at the business impacts of specific activities.
So, define what the business objectives of those activities are, and how else those objectives might be achieved. You’re looking at the impact of something happening, not its likelihood or how it might happen. Then, you want to figure out ways of reducing that impact.
Can you give another example of how an organisation can increase its MAO?
Take a patient information system in a hospital. Maybe that’s something you need back up, say, every six hours.
However, if you make certain changes – say, print things out and keep physical copies – you can maybe push it from six to eight hours.
Those two hours might not sound like much, but that takes huge pressure off your IT team. Particularly if you can do this for all or most of your systems – because everyone is giving them that extra 33%. That’s valuable time to get more things done, and done well, in a very stressful situation.
Could you give another example?
Sure. Legally, all prescription drugs require a printed label – you can’t handwrite them. So, what can a pharmacy do?
Well, they can take the label-printing machine and connect it to an isolated laptop – i.e. not on the main network. Then, the pharmacist can manually print labels. That’s more time-consuming, of course. But it allows them to continue dispensing medications while still fulfilling their legal requirements.
This is low-tech stuff. But it means that, suddenly, the requirement for the pharmacy’s computer system to be operational is pushed out. It becomes far less urgent to get it back up and running again.
That extra time can give the IT team a chance to prioritise other things, or else make sure they don’t make any mistakes as they bring the system back up again. Going from, say, 6 to 12 hours makes a huge difference. It doubles the MAO.
That’s presumably especially important when you have multiple systems that would otherwise all need to be up and running in those six hours.
That, and you often only have one person, or a handful of people, who can recover them. And those people can’t work non-stop for 18 hours, or whatever. They’ve got to sleep!
I keep saying this in workshops: you can’t expect people to work around the clock, with no breaks.
Organisations often overlook these types of details as they put together their plan. That’s why it’s so important to test them – make sure they work as intended. Exercises also help train staff, teaching them what to do when a disruption occurs.
Organisations should also understand that lots of little changes can collectively make a big difference. I just ask the questions to help them identify what changes they must make.
Looking at many little things can sometimes be overwhelming. How can organisations avoid that?
I’d open with a question like: ‘What are your top 5 critical processes?’ or ‘What are the top 5 things essential to what you’re doing?’ Then, focus on those five.
Because if you’re not careful, someone’s going to produce a list of, say, 25 processes. Which is fine, but you must narrow that list down to the top 5. That way, you keep this entire exercise manageable. Plus it’ll be effective at what it’s trying to achieve.
Sometimes, we still have time and capacity to look at more – in which case, great. We can expand the list.
But I always open with five. In my experience, that gives the right balance of depth and manageability.
So, the common mistake for overcomplicating things is trying to do too much?
Too much, and too quickly. Focus on what’s critical.
Think about laws like DORA and NIS 2: they concentrate on critical systems. On critical infrastructure across the EU.
So, keeping that in mind, I’d define the scope of your risk assessments and BIAs by limiting yourself to what’s critical to your organisation.
Both DORA and NIS 2 require business continuity and operational resilience. But fundamentally, both are about managing your risks. They also require governance – top management support. Do you have any tips for securing that support?
All those things are linked. When you’re looking at risk, you first define what the business objectives are. What are we trying to do as a business? And what are the risks of those objectives not being fulfilled from an IT point of view?
Put differently, you need to understand how fulfilling the IT department’s objectives helps the organisation as a whole meet its overall objectives. That also means you’re looking at the corporate value of your IT objectives.
For example, if you’re a hospital, what’s a key objective for you? Probably that you’re able to deliver surgery on time.
So, to achieve that, what does the IT team need to do? Well, it must maintain access to the hospital’s theatre management system. It needs to be operational 99.9999% of the time between certain hours.
The next obvious question to ask is what may affect the availability of that system, which brings us back to operational resilience and business continuity.
When you come at it from that angle, investing in these types of measures will always make sense to top management. The legal pressure from laws like NIS 2 and DORA will help too.
Is that for both risk assessment and BIA?
Yes. The point of both is that they deliver value to the organisation. So, if you’re clearly linking both back to the overall business objectives, they justify themselves as far as management is concerned. Which frees up time to focus on the assessments themselves.
So, for both risk assessment and BIA, establish exactly what you’re trying to achieve, then focus on that.
The tendency with both assessments is for them to get increasingly complicated. You go down rabbit holes. And you may end up with an impressive-looking spreadsheet with 200 risks or so. Unfortunately, it also doesn’t tell you anything useful.
I prefer the extreme other end. Take a recent client, which had just 23 risks on its spreadsheet. But when you looked into them, they were all proper risks that needed addressing.
There’s a reason we categorise risks by priority: it’s impossible to deal with all of them, and certainly not all at the same time.
It’s a bit like audits – those are done through sampling. There’s no other reasonable way you could do them! If you actually audited everything, you’d have to be there the whole time that the organisation is doing those management system activities.
Do you have any final words of advice?
All these types of activities – risk assessment, BIA, compliance… Almost always, they come down to looking at the realistic resources you’ve got, then figuring out how to get the most out of them. Getting the best ‘bang for buck’, as they say.
This comes down to value – does it provide value to the business? If the answer is no, it’s obviously not worth doing.
Looking for tailored advice on conducting a BIA?
Or need help implementing resilience, so you can meet your compliance obligations?
Our experts can help.
Put your trust in the leading global provider of cyber risk and privacy management consultancy solutions.
We pride ourselves on being the pioneer of the global information security standard, having led the world’s first ISO 27001 certification project. We’ve since continued to lead the way on major data privacy and cyber security developments, including the introduction of the GDPR and DORA.
About Andrew Pattison
Andrew has 30 years’ experience in information security and risk management, having worked in GRC since 1994. He also holds an MSc in Information Systems Management, as well as CISM® and CRISC® certifications.
Now, he’s our head of GRC consultancy, Europe, where among other responsibilities he leads product development relating to DORA, as well as the organisation’s ISO 27001 training courses.
The post BIA (Business Impact Analysis): A Practical Approach appeared first on IT Governance Blog.