The first step is to identify the overall IT environment, which means having a thorough understanding of the business function. If the business generates sales revenue, knowing the sales amounts, which include the number of customers and transactions, is important. Sales revenue translates to lost sales during an outage.

A BIA is possible to perform on a CBF that doesn’t generate sales revenue. For example, an email system is a CBF for many organizations. It may serve 5,000 employees and pass tens of thousands of emails daily. Even though it doesn’t generate any direct sales revenue, most organizations would identify it as a CBF.

Identifying the environment may include determining what is critical, including getting a big picture of the IT systems within the scope of the BIA. Depending on the scope, this step could include collecting diagrams and technical documentation, which would help to determine which components are critical.

A BIA can be completed on an entire organization or only portions of it. For example, for a small company with less than 100 users, a BIA could be completed on the entire company. On the other hand, a company with several offices spread throughout the country may require several BIAs, instead of just one enormous BIA. Individual BIAs could be done for any of the small offices and for different functions within the organization. For example, a single BIA could be done for online sales and another one for database support.

After completing this step, the administrator will have a better idea of what systems to include in the BIA and will also be able to identify the stakeholders.

Stakeholders are those individuals or groups that have a direct stake or interest in the success of a project. For example, a vice president of sales would have a direct stake in the success of sales. Stakeholders know the CBFs.

A stakeholder can help ensure that adequate resources are available, which includes simple matters, such as ensuring personnel are available for interviews for the BIA, and larger issues, such as identifying the MAO.

Individual stakeholders can identify any system or function as critical because they are responsible for losses due to outages. They are also responsible for dedicating resources to protect the systems. Because these are their responsibilities, the stakeholders’ opinions matter the most.

Some BIAs are designed to focus on a specific CBF from the beginning. For example, a BIA could be commissioned specifically for an online website. Thus, the processes involved are the only thing left to identify.

Another BIA could be focused on a remote office, so the first thing that would need to be done is to identify what functions are done at the remote office. For example, the majority of the work at the remote office may be done offline, such as providing presentations to client sites on a regular basis. Based on this scenario, the people there could still do these presentations even if they lost all IT functions for a week or more. In this case, none of the functions would be considered critical.

On the other hand, a remote office may sell products or services, which means the office needs constant connectivity with the main office during business hours. If the remote office loses connectivity, employees can’t close a sale. If these employees generate a lot of revenue, the organization might consider connectivity as a critical function.

Critical resources are the resources needed to support the CBFs and processes. They could include hardware, such as servers or routers, and software, such as the operating system and applications.

When identifying critical resources, the supporting infrastructure must be included. For example, a web server must be operational 24 hours a day, seven days a week and needs facility support, which could include power, heating, and air-conditioning. If a critical system requires support personnel for operations, items such as food and potable water should be included as critical resources.

Identifying critical personnel is also important. Any system has several key personnel integral to its success, such as executives, managers, supervisors, administrators, or key customers or vendors.

In the example presented earlier of the online web server with the back-end database, the following systems would be included:

• Web server
• Database server
• Internal firewall
• External firewall

Interviewing the experts is important to identify critical systems that support any CBF. For example, in an email service within a Microsoft domain, the obvious systems are any of the email servers. However, within a Microsoft domain, several additional servers are critical, which include a domain controller (DC), a DC that’s also a global catalog server, and a Domain Name System (DNS) server used to locate servers within the domain. If any of these servers are unavailable, the email service will not work.

Once the critical resources have been identified, the MAO for each of them can be identified. Each of these resources supports a CBF. If the MAO of a resource isn’t clear, the MAO of the CBF it supports must be identified, which is also the MAO of the resource.

In addition to identifying an MAO, an impact statement, which identifies the effect of the loss, should be included. The impact can be directly stated by identifying what cannot be done in case of a loss, or it can be stated in monetary terms.

For example, email services may be critical. However, the organization may be able to continue to operate for as long as eight hours before suffering a serious impact. On the other hand, a web server generating $60,000 in revenue an hour loses as much as $1,000 in direct sales a minute. The organization can identify the MAO for this web server as five minutes.

TABLE 12-3 shows a sample output for this step.

This part of the BIA identifies the most and the least important critical systems. The highest priorities are assigned based on the shortest MAOs. For example, in comparing a system that impacts operations after five minutes of downtime with another system that can be down for eight hours before an impact occurs, clearly, the system with a five-minute MAO should be recovered first.

The output of the BIA at this stage can be as simple as a list of the critical systems with designated priorities, such as 1, 2, and 3. The priorities could also be categorized. For example, the most important systems could be categorized as high, and the other categories could be listed as medium or low.

TABLE 12-4 shows how recovery priorities could be listed for an organization’s systems. This table uses a scale of 1 to 5 with 1 as the highest priority. Desktop PCs are added as the lowest priority.

The BIA report compiles the data that has been collected. No specific format is required, but it usually includes the following sections:

• Preliminary system information—The preliminary system information includes generic information, such as the organization, system name, and system documentation.
• System points of contact (POCs)—POCs are the system experts and stakeholders who provided the input into the BIA. They can also be queried with any follow-up questions. Both internal and external POCs may be included, depending on the scope of the BIA.
• System resources—The specific resources are listed in this section, which include the hardware and software and any personnel or other resources.
• Critical roles—Some POCs may have critical roles related to a system. If so, they can be identified in this section, which will make following up with them easier.
• Table linking critical roles to critical resources—This table matches the personnel to the systems. For example, if email services are considered critical, the email POC would be matched with this system.
• Table identifying resources, outage impact, and MAO—This table lists each critical resource that was identified in the BIA. For each resource, the impact of an outage and the MAO are included. This table is one of the most important elements of the BIA.
• Table identifying recovery priority of key resources—This table lists the internally developed recovery priority, designated by numbers, such as 1, 2, and 3, or words, such as high, medium, or low.