Certified: The ISACA AAISM Audio Course

In this episode, we’re going to take a step back from the heat of incident response and look at what it means to keep the business running when A I systems are involved. Business continuity is about preparing for disruption so critical operations can continue, even if a key system fails, a vendor goes down, or an incident forces you to restrict functionality. New learners often assume business continuity is only for power outages or natural disasters, but in modern organizations it also covers software failures, cyber incidents, and third party outages that interrupt essential services. When A I becomes part of how decisions are made, how customers are supported, or how data flows are processed, continuity planning must include A I or the organization will discover weak points at the worst possible time. The goal here is to understand how to add A I systems to continuity plans in a way that exposes hidden dependencies and prevents fragile assumptions. By the end, you should be able to explain why A I continuity is different, what weak points tend to hide, and how planning reduces risk without requiring perfection.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

A Business Continuity Plan (B C P) is a documented approach for maintaining or quickly restoring essential business functions during and after a disruption. After the first mention, we will refer to this as B C P. The B C P is not only a technical plan, because it includes people, processes, communications, and decision authority. It describes what must keep working, what can be paused, and what the organization will do when normal operations are not possible. For beginners, it helps to think of B C P as a promise the organization makes to itself, saying we have thought ahead, we know what matters most, and we will not improvise under pressure. When A I systems are introduced, the promise becomes harder to keep if A I is treated as optional or invisible. A I can become a silent dependency, meaning business functions start relying on it without formally recognizing that reliance, which creates hidden weak points.

A hidden weak point is a dependency or assumption that is not documented, not tested, and not understood until it fails. Hidden weak points appear when teams adopt an A I feature gradually and later forget how much of the workflow depends on it. They also appear when A I systems rely on external services, specialized data pipelines, or unique access privileges that are not replicated elsewhere. For example, a customer support team might start using an A I assistant to generate responses, and over time the team becomes faster and reduces staffing assumptions, but the continuity plan may not include what happens if the A I assistant becomes unavailable. Another example is an A I model that depends on a specific data source, and if that data source is blocked during an incident, the model outputs degrade sharply. A continuity plan aims to discover these weak points early and design alternatives.

A practical first step in adding A I systems to continuity planning is identifying which business functions use A I in a meaningful way. This is different from listing every tool, because some A I usage is convenient but not essential, while other usage becomes critical to delivering services. You want to find where A I supports decisions, automation, customer interaction, safety critical tasks, or regulatory reporting, because failures in those areas can cause immediate harm. For beginners, it can help to classify A I usage by how much the business would suffer if it stopped today. If the answer is a small annoyance, continuity planning may be light. If the answer is lost revenue, customer harm, legal risk, or operational paralysis, continuity planning must be stronger. This focus prevents continuity planning from becoming too broad and unmanageable.

Once you identify critical A I supported functions, the next step is to map dependencies, because dependencies are where weak points hide. Dependencies can include model hosting services, network connectivity, identity and access systems, logging and monitoring systems, data pipelines, storage services, and third party vendors. A I systems often depend on multiple layers, such as a front end application, a retrieval system that pulls relevant documents, a model service, and a downstream channel that delivers outputs. If any one layer fails, the overall function may fail or behave unpredictably. The continuity plan should document these dependencies clearly, including which dependencies are internal and which are external, because external dependencies can fail for reasons outside your control. Beginners should see dependency mapping as an honest inventory of what must be available for the A I system to behave safely. Without this map, people will guess during a crisis, and guessing creates delays and mistakes.

A I systems also introduce a continuity challenge because failure is not always obvious, meaning the system might still produce outputs but those outputs may be wrong, unsafe, or based on incomplete data. In a normal system outage, availability problems are visible because the system stops responding. In A I, integrity problems can be subtle, such as the model producing confident but incorrect answers because its data retrieval is broken. This is a dangerous kind of hidden weak point because the business may continue operating with faulty guidance. A continuity plan should include triggers for recognizing degraded quality, not just complete outages. It should also include what to do when outputs are not trustworthy, which might mean switching to manual processes or restricting the system to low risk use cases. Beginners should learn that continuity is about safe operation, not just operation.

Another common hidden weak point is overdependence on a single vendor or a single model capability. If the organization relies on one external service for model access, and that service has an outage, critical functions may stop. If the organization relies on a proprietary feature that cannot be replicated elsewhere, recovery options may be limited. Even when vendors are reliable, disruptions happen, and continuity planning is about being ready rather than being surprised. This does not always mean building a full duplicate system, but it does mean knowing what your fallback is and what the limitations will be. For example, a fallback might be using a simpler rule based workflow, using a smaller internal model for basic functions, or using human review and manual processes temporarily. Beginners should recognize that the best continuity plans focus on maintaining essential outcomes, even if the method changes.

Data dependencies create another set of weak points, especially for A I systems that use retrieval or dynamic context. If an incident forces you to restrict access to a sensitive database, the A I system may lose the context it needs to answer correctly. If data pipelines are disrupted, the model may receive stale or incomplete information. If the system relies on prompt logs or feedback data to adjust behavior, losing that loop can degrade performance over time. Continuity planning should include which data sources are essential, how they are protected, and what happens if they are unavailable. It should also include how to operate safely if only partial data is available, because partial data can be more dangerous than no data if users assume completeness. Beginners should think of data as fuel for A I, and continuity planning must address what happens when fuel is restricted, contaminated, or unavailable.

Access control and security measures themselves can become continuity weak points if they are not planned carefully. During an incident, containment actions might restrict accounts, disable integrations, or tighten filters, which can reduce risk but also reduce functionality. A continuity plan should anticipate that security response may intentionally degrade service in order to protect data and users. This is a mature mindset that prevents conflict between security and operations, because everyone agrees in advance that safety may temporarily outrank convenience. The plan can specify which functions can continue in a restricted mode and which must stop to prevent harm. For beginners, this is an important lesson: continuity planning is not about keeping everything running at any cost, it is about keeping essential functions running safely. If an A I system cannot be trusted during an incident, the safe choice might be to pause it, and the continuity plan should make that pause survivable.

Communication is another area where weak points hide, because people need to know what is happening and what to do when an A I system is degraded or unavailable. If users keep sending requests to a system that is producing unreliable outputs, the incident can worsen. If teams do not know the fallback process, they may improvise risky workarounds, such as using unapproved external A I tools. A continuity plan should include clear guidance on how users will be informed, what they should do differently, and how they should report issues. It should also include internal communication paths so teams can coordinate changes and avoid contradictory instructions. Beginners should see communication as part of continuity, not an optional extra, because confusion is a multiplier that turns small outages into large disruptions.

Testing and rehearsal are essential for finding hidden weak points, because plans that look good on paper can fail in real conditions. Testing does not have to mean complex technical exercises; it can include walking through scenarios and asking what would happen if the A I service was unavailable, if a critical data source was blocked, or if outputs became unreliable. It can include verifying that fallback processes are practical, that staffing assumptions still hold, and that decision authority is clear. For A I systems, testing should include degraded mode thinking, meaning the system still runs but must be restricted, such as disabling certain high risk capabilities while keeping basic functions. Testing also reveals whether people know how to recognize that A I outputs are untrustworthy, which is a critical continuity skill. For beginners, the takeaway is that hidden weak points are often only visible when you simulate failure and watch where uncertainty and friction appear.

As we close, adding A I systems to business continuity planning means treating A I as a real dependency with real failure modes, not as a nice to have feature that can be ignored. A strong B C P identifies which business functions rely on A I, maps the full chain of dependencies, and plans for both outages and subtle integrity degradation. It exposes hidden weak points like single vendor dependence, fragile data pipelines, and unsafe assumptions about output quality. It also anticipates that security response may intentionally restrict capability, and it designs fallback processes that keep essential outcomes moving safely. Communication and testing turn the plan into a living practice rather than a document that gathers dust. When you do this well, the organization is not just prepared for A I outages, it is prepared to operate responsibly during uncertainty, which is the real goal of continuity.