How do we run a business impact analysis that the business owns, process by process?

Start

You are analysing the impact of losing one critical service

A business impact analysis shows how the harm grows as a service stays down, and the point at which it becomes Severe. The pack gathers it process by process, with the service's business owner, one workbook per critical service. Gathering is led by the resilience coordinator. The business owner answers for the result.

• Then: Is the service's business owner in the room, answering for it?

Decision

Is the service's business owner in the room, answering for it?

The business owner is the manager accountable for the service. The business owner gives the answers and answers for them. The resilience coordinator gathers them, and the site or unit continuity leads and the technical recovery lead are consulted. An analysis answered by IT alone is IT's view of the harm, not the business's. If you cannot tell who the owner is, answer no.

• Yes: Open with what the service delivers, and to whom
• No, or not known: Name the business owner and book the workshop with them

Step

Name the business owner and book the workshop with them

Name the manager accountable for the service before any rating starts. IT proposes what is achievable later; the business owner decides what the business needs. Invite the people who run the work, and consult the continuity leads of the sites the service runs from and the technical recovery lead.

• Then: Is the service's business owner in the room, answering for it? (back to an earlier step)

Step

Open with what the service delivers, and to whom

Start the workshop with the questions on the pack's Service sheet: what the service delivers and to whom, what a customer notices first when it stops, which activities one piece of work passes through, when it is busiest and where the work is done. The Service sheet prints the impact scale and what each level means. Rate with your own risk register's scale, so the business and the register agree, and check that Severe is its top level before you rate anything.

• Then: Is the service broken into its processes?

Decision

Is the service broken into its processes?

A process is one activity the service is made of, such as picking or loading for dispatch. Walk one piece of work, such as one order, from start to finish and list the activities. The pack says three to eight is usual. If the list is missing, or you cannot tell whether it covers all of the service, answer no.

• Yes: Do you know when each process is busiest?
• No, or not known: Walk one piece of work through and list its activities

Step

Walk one piece of work through and list its activities

Give each process the name the people who do the work use, and number them in the order the work flows. An activity that stops whenever another stops belongs with it. With more than eight, group small activities that always stop together, or split the service in two and analyse each part. A small organisation may need only three to five processes.

• Then: Do you know when each process is busiest?

Decision

Do you know when each process is busiest?

Ask which months, days and shifts are the busiest for each process. The outage to rate is one that begins then. If nobody can say, or only for some processes, answer no and ask the people who run the process.

• Yes: Rate the harm at each time point, whatever the cause
• No, or not known: Ask the people who run each process when it peaks

Step

Ask the people who run each process when it peaks

Record the busiest months, days or shifts in the people's own words. They set the starting point for the harm ratings. The pack also carries them to the test plan and to the return to the normal set-up after a failover, which are planned to keep away from them.

• Then: Rate the harm at each time point, whatever the cause

Step

Rate the harm at each time point, whatever the cause

For each process ask: if it had stopped for this long, starting at its busiest time, how bad would the harm be? Rate each impact area on your scale and enter the worst level. The pack's default time points are 4, 8, 24, 48, 72, 120 and 168 hours. A service that cannot tolerate 4 hours needs earlier points of your own. Ask what happens when the process has stopped, not how long the systems usually take to return. The level can stay level but never falls. Name the area that reaches the level first, in the business's words.

• Then: Is the least each process needs to keep going written down?

Decision

Is the least each process needs to keep going written down?

The least a process needs, at its reduced level, covers people, sites, equipment, the systems and suppliers it cannot run without, and its vital records. Where only one person knows how, that is a single point of failure. If any process lacks this, or you cannot tell, answer no.

• Yes: Take the worst rating at each time point as the service's level
• No, or not known: Record the least each process needs, systems and suppliers by ID

Step

Record the least each process needs, systems and suppliers by ID

For each process record the people and skills, the sites that could do the work, the equipment and its stand-ins, and the vital records it could use with the systems down, with where they are. Give systems and suppliers by their IDs in your dependency register, or write none, and add to the register any that are missing.

• Then: Take the worst rating at each time point as the service's level

Step

Take the worst rating at each time point as the service's level

The service's level at each time point is the worst of its processes' levels, including a process that never reaches Severe, because it can raise the level before the downtime is reached. The maximum tolerable downtime is the first time point at which the service reaches Severe.

• Then: Does the service reach Severe by the last time point?

Decision

Does the service reach Severe by the last time point?

Read the service row. If it reaches Severe at some time point, that time point is the maximum tolerable downtime. If it never reaches Severe within 168 hours, the pack asks whether it is a critical service at all. Complete every process's ratings first: a missing rating is not a pass.

• Yes, at some time point: Note where a cyberattack would change the answer
• No, never: Ask whether it is a critical service at all

Outcome

Ask whether it is a critical service at all

A critical service is one whose disruption beyond its maximum tolerable downtime would cause Severe harm on your scale. If none of its processes gets there, check the ratings with the business owner. If they stand, the service may not belong on the critical list. The pack has the list approved with the policy, so take that question to whoever approves it: the board, or a board risk committee it has delegated to; the management board in a two-tier structure; executive management where there is no board. This workshop does not decide it.

Step

Note where a cyberattack would change the answer

The analysis rates harm whatever the cause. After a destructive cyberattack, recovery starts with the foundations, rebuilt from sources you can trust, so a service can take longer to return than a technical failure would suggest. The objectives matrix sets the downtime beside the time a recovery would take after an attack. A service that would be back after its downtime needs a different plan.

• Then: Take the results to the business owner's objectives

Step

Take the results to the business owner's objectives

The service's level at each time point and what drives the harm go to the Impact Analysis sheet of the objectives matrix, where the downtime calculates again and must match. The analysis sets no recovery objective. The business owner agrees a recovery time shorter than the downtime, a recovery point and a workaround that keeps the harm below Severe.

• Then: Keep the analysis with the objectives and review it with them

Outcome

Keep the analysis with the objectives and review it with them

Keep the workbook with the objectives matrix, and keep a copy that can be reached when the main systems are down. The pack's default is to review it at least every 12 months, and after a significant incident, a recovery test that missed an objective, or a significant change to the service, its suppliers or its risks.