In today’s bulletin, Charlie discusses using AI when conducting a Business Impact Analysis (BIA) and gives an insight into the different areas that AI can be used within the BIA.

I haven’t written a BIA-focused bulletin for a while, and AI is a subject that continues to fascinate me. This week, I thought I would do some research on how AI should be considered when conducting a BIA and share what I found. A couple of weeks ago, I wrote a bulletin on ‘AI and Business Continuity: 10 Risks BC Practitioners Need to Understand’, so this week’s bulletin, focusing on BIAs, is part of the same series in which I am trying to understand how to incorporate the use of AI into how we deliver business continuity to clients.

One of my responsibilities at Databarracks is to ensure that all our consultants follow good practice and maintain the quality of our consultancy output. When new standards, regulations, threats, or technologies come along, they are incorporated into what we deliver to our clients. If I were not able to use AI tools, my output would be produced much more slowly, and its quality would be harder to maintain. I suspect many individuals and organisations are experiencing the same shift. As AI is likely to become an increasingly important part of the delivery of vital products and services, we need to account for its use when conducting a BIA for an organisation.

Literature on the subject

Surprisingly, there is very little written on incorporating AI into the BIA itself, most business continuity writing concentrates on the risks associated with an organisation’s use of AI. Much of the risk discussed concerns the reputational risk of AI and what happens if AI appears to be working fine, but is producing unethical answers or disadvantaging a group in a way that isn’t immediately obvious. In his article When AI Fails, Everything Fails Differently – New Business Impact Analysis (BIA) [1], Wasim Malik discusses two new concepts that need to be applied when evaluating AI. As well as looking at an RTO and RPO, we need to look at Recovery Accuracy Objective (RAO), which ‘defines the minimum acceptable model performance after recovery’, and also Recovery Fairness Objective (RFO), which ‘ensures fallback or manual processes do not introduce bias that AI was originally deployed to remove.’. These concepts focus on risk mitigation and revising recovery solutions, rather than on how to incorporate AI into your BIA.

Understanding how organisations use AI

AI can be used differently in every organisation. In some sectors, such as financial services, insurance, healthcare, pharmaceuticals and technology, AI is increasingly becoming central to business operations. In other organisations, there is little use of AI at all. AI use can also be at the personal level, with individuals using personally-developed tools to speed up their tasks and make them more efficient, while other organisations have AI as a key part of their workflow, making it essential to their service delivery. AI can be used in a multitude of different processes and activities, including:

• Process automation – automating repetitive tasks, data entry, approvals, and routine administration
• Decision support – analysing information and recommending actions or priorities
• Customer service – using chatbots, virtual assistants, and automated enquiry-handling
• Data analysis and forecasting – identifying trends, predicting demand, and supporting planning
• Risk and compliance – detecting fraud, anomalies, errors. and potential control failures
• Content and knowledge management – creating summaries and reports, and helping staff find information

Because every organisation uses AI differently, it is important not to make assumptions during a BIA. We therefore need to take some time to understand its use and its importance to the process.

Conducting a BIA where AI is used

When conducting a BIA for an organisation that uses AI, the following methodology should be considered:

1. The BIA should be conducted in the same way as you would conduct a normal BIA.
2. AI should be treated as an application and documented in the same way as you would document all the other applications the organisation uses.
3. As with all applications, the AI’s importance in the delivery of products and services needs to be evaluated. Does it provide a quality check, and can that check be omitted for a short time, or is it a core part of the process, meaning the end-to-end process stops without the AI being present?
4. The impact of the loss of AI on the delivery of products and services to customers needs to be considered, which is the normal way of conducting the BIA. What also needs to be considered is what would happen if the AI were to malfunction or produce results which it was not designed to produce. What would be the reputational impact of this? Could it have a major regulatory impact and generate negative headlines, or would the impact be minimal or limited to embarrassment?
5. The ability to use manual workarounds for AI needs to be considered.
6. Can the AI be substituted with another AI system and quickly configured for use, or is the process very difficult, involving learning over time and complex configurations, meaning easy substitution of the system is not possible?
7. Unless the organisation has developed the AI itself, it should be treated in the same way as you would treat a SaaS-provided software service. When looking at the risks, the following needs to be noted:
   a. Failure of the company supplying the AI,
   b. An upgrade to the software which impacts the functionality or user experience,
   c. Changes in costs which impact the viability of the AI’s use,
   d. Where the AI is delivered from and what failover arrangements there are between data centres,
   e. What third parties are involved in the delivery of the AI and what vulnerabilities they bring to the delivery of your AI systems.
8. As with all SaaS services, there needs to be a discussion about who is responsible for backing up the data, any configurations and bespoke elements, and for ensuring that this is carried out. RPO is relevant here and should be considered.
9. How an incident which impacts the AI service would be managed with the AI provider, how communications with them would be coordinated, and how to contact the provider 24/7 if a major outage occurred.
10. The data flows used by the AI need to be mapped so that single points of failure can be identified. The impact of a third party processing the data, or of a cyber attack that could degrade or stop the processing, should also be considered.
11. If a process is halted, can the backlog be processed, and how long does this take?

These are my initial thoughts on conducting a BIA for an organisation that uses AI. Treating AI as a technology and process dependency, and, where appropriate, as a SaaS, provides a practical starting point for understanding its role in the delivery of products and services. However, the risk element is more complex. Unlike traditional systems, AI may remain available while producing inaccurate, biased, or inappropriate outputs, so both loss of service and loss of confidence in its results need to be considered. As the risks associated with AI are still developing and are not yet fully understood, this area will require further guidance and consideration. I’ll continue exploring the topic in future bulletins.

References

[1] Malik, W. (2025) ‘When AI fails, everything fails differently – new business impact analysis (BIA)’, The Business Continuity Institute, 17 November. Available at: https://www.thebci.org/news/when-ai-fails-everything-fails-differently-new-business-impact-analysis-bia.html (Accessed: 17 July 2026).