Auditing Business Continuity

By S. Anantha Sayana
Volume 1, 2005

The confidentiality, integrity and availability of information systems must be ensured to

protect the business from the risks relating to information technology. An IS audit helps
to identify areas where these are vulnerable or inadequately protected through systematic
examination and evaluation.

The dependence of todays enterprises on IT is significant. For an organization that uses

IT extensively for its operations, not just recording of transactions, the nonavailability of
its information systems could mean the end of its existence. Even for other organizations,
there would surely be varied negative impacts.

Hence, availability is one of the major criteria for IS audit. Availability is ensured
through various means, technologies and processesall broadly covered under the
umbrella of business continuity and disaster recovery.

Business Continuity Plan (BCP)

Every organization should have a business continuity plan that seeks to ensure that its
information systems are available and running at all times to support and enable the
business to function and grow. In spite of all precautions and preventive controls,
disasters can occur. Some disasters cannot be controlled and/or prevented. In such cases,
the business continuity plan should also enable recovery of information systems within an
acceptable time frame to avoid any serious damage to the business.

An IS audit of business continuity is essentially an audit of this plan with reference to the
adequacy, completeness and appropriateness of the plan; availability of the processes and
people to implement the plan; its testing; and the verification of the various day-to-day
functions that need to be performed to make the plan effective and ready at all times.

Approach to Auditing Business Continuity

The audit of business continuity can be broken into three major components:

1. Validating the business continuity plan

2. Scrutinizing and verifying preventive and facilitating measures for ensuring
continuity
3. Examining evidence about the performance of activities that can assure continuity
and recovery
Validating the Business Continuity Plan

The IS auditor knows (or should know) the business, the information systems in use and
the extent of the business dependence on IT. The auditors focus should be on validating
the plan against this knowledge. The following points are written with this objective and
are not meant to be a comprehensive description of everything that should be in the
business continuity plan:

The IS auditor should check whether the plan covers all mission-critical systems
or is only for the ERP or other, selected systems. If the plan does not cover all systems,
the auditor should evaluate the impact of its inability to recover some systems and
notify management. For example, if one of the not-covered systems is the mail system,
the impact could be devastating for the company.
The IS auditor should ascertain whether the plan is based on a systematic business
impact analysis that clearly understands the impact of nonavailability of the systems on
the business (in various dimensions such as loss of revenue, loss of profits, inability to
comply with statutory norms, damage to reputation and image, etc.).
The auditor should examine the plan to determine whether the plan has a good
combination of preventive controls and recovery controls. Preventive controls should
exist for all failures and disasters that can be managed. Preventive controls are often in
the form of redundancies, for example, diesel generators for power failures, redundant
air conditioning units, fault-tolerant redundant hard disks and other components in
servers, and mesh networks that allow routing through alternate paths. Recovery
controls are those that will enable the recovery of the systems when disaster does
strike. First, the IS auditor needs to validate the definitions of recovery time objective
(RTO) and recovery point objective (RPO) for the various systems covered by the plan,
as the entire recovery facilities and processes would be built to achieve these
objectives. The RTO and RPO should be in tune with the requirements of the business.
RTO is the maximum number of hours or days within which the system should be up
and running (available for business) after a disaster. For example, if a company
determines that a sales order processing system should be up after an interruption
within 12 hours, the RTO is 12 hours. If a bank determines that the retail banking
system cannot be down for more than 30 minutes after a disaster, the RTO for that
system is 30 minutes. Another way to look at the RTO is as the maximum time the
business can afford to be without that system.
The RTO will decide when the system must come up after a disaster, but what about
the data? Will the system come up with the data exactly as they were at the moment of
the disaster or come up with data that were present at some point of time before the
disaster (could be minutes, hours or days back)? The RPO describes the age of the data
that the plan should be capable of restoring in the event of a disaster. For example, if
the RPO of an ERP system is eight hours, then when the system is restored after a
disaster, its data willat bestbe in the state they were eight hours before the disaster
struck, as that is when the data would have been last backed up. Another way to look at
RPO is as the maximum period of time of transactions data that the business can afford
to lose during a successful recovery.
 The IS auditor should also verify whether the BCP is updated periodically and
reflects the current business and IT environment accurately.
Another important aspect to be evaluated in the BCP is the requirement of testing
the plans or disaster recovery drills. These should be prescribed to be done periodically
for various types of disasters and results documented.
The BCPs other elements, like notifications, call trees, the response teams,
updating the contact information, and the step-by-step procedures for recovery, should
be evaluated for appropriateness from the IS auditors knowledge of the business.
The auditor should verify whether the plan addresses not just recovery after a
disaster but also restoration back to the primary site when normalcy returns.

Scrutinizing and Verifying Preventive and Facilitating Measures for Ensuring

Continuity

The verification of the physical facilities and the equipment and environment that ensure
availability and recovery after a disaster include the following:

The IS auditor should verify the existence and correct functioning of all the
preventive controls. Many of these are general controls, but the evaluation of these
from a BCP viewpoint is necessary even though they may have been reviewed as a part
of the general controls. The focus of the BCP audit should be on comprehensiveness
to see if every activity, component or software that is required for successful recovery
has been addressed.

The scrutiny of the disaster recovery site as to its location (i.e., distance from
primary site, accessibility, vulnerability to similar threats) and the general controls and
security relating to it should be an essential part of the audit. The disaster recovery
(DR) site may be a cold/warm/hot site depending on the RTO and RPO requirements.
The DR site and the tape storage site could be different locations, in which case
the auditor should also verify the offsite storage facility with respect to the preventive
controls, such as physical security, fire and flood controls, etc.
In some cases, the entire DR activity could be outsourced to a vendor. Therefore,
the IS auditor should verify the contracts entered into by the SLAs and whether the
periodic testing and drills are being performed as agreed.
The IS auditor should verify that supporting equipment and supplies, such as fuel
for the power generators, are maintained to enable usage of the redundant equipment
when required. Likewise, if standby servers and other systems are present, they should
be in a state of use and readiness.
The network is one of the major components of any system these days, with users
from various parts of the world accessing the applications. The auditor should verify
whether there are facilities for alternate routes to overcome network failures. The
auditor also needs to check the availability of the network at the DR site and the
facilities for switchover from the primary site during recovery to enable all users to
access the systems from the DR site.
Examining Evidence About the Performance of Activities That Can Assure
Continuity and Recovery

Effective recovery is not completed by merely acting on the day of the disaster, but by
sustained activities that are completed in due course with the objective of remaining in a
state of preparedness for a disaster. A number of activities need to be performed on a
day-to-day basis to ensure availability of systems at all times, as required, and recovery
following a disaster.

The IS auditor should verify the backup tapes with respect to the backup logs and
the labeling of the tapes and other records to check whether the backups are being
taken as prescribed in the plan at the required intervals. The auditor should also verify
whether all the components of the system, including the operating system, database,
other utilities and application software, besides the data, are backed up and available at
the DR site. The auditor may examine a few tapes at random for readability and
accuracy of labeling by requesting restoration on a test area.
The IS auditor should become familiar with the replication mechanism and verify
the logs to ensure that replications are being completed successfully at frequencies in
line with the RPO requirements. The IS auditor should also verify whether the receipt
and update of the data at the DR site are being completed at intervals that will enable
achievement of the RTO.
Verification of maintenance and testing logs of all equipment, such as power
generators, air conditioners, UPS systems and fire control equipment, can give the IS
auditor clues as to the effectiveness of these controls.

The most important part of the verification is to see whether the plan has been
tested and, if so, how thoroughly tested. Simply restoring a backup tape to verify if the
data can be read is one form of testing, but it is not recovery. Table-top testing, where
all procedures and responses of people are tested without actually performing the
actions, is also a useful preparation to the actual drill. A complete drill should effect
recovery from the DR site in every way, simulating all conditions that would exist
when a disaster strikes the primary site. The auditor should carefully verify the results
of the drills, including sign-offs from users and lessons learned, if not actually
participating in the drill as an observer.
The IS auditor should not ignore the people part of the BCP. The auditor should,
through inquiry and verification, ascertain the state of awareness of the users about the
business continuity plans as well as the awareness and capability of the IS staff and
BCP team members about the recovery procedures. Training programs and awareness
campaigns are essential, especially in large organizations, to ensure that the plans
actually work on the day when disaster strikes.
Conclusion

The nature, complexity and cost of the business continuity program are related to the
nature of the business dependence on information technology. Business continuity,
which in the earlier days meant just taking backups of data on tape and putting it away
somewhere, has come a long waybecoming a complex program both in terms of
technology and processes.

For most businesses today that have extensive networks, where users from different parts
of the world access the applications and a lot of business is done with vendors and
customers on the Internet, the line between business and information systems is blurred.
In such cases, continued availability of systems is a sine qua non for business. Such
businesses cannot afford to be without systems for long and do not have any other
alternate means of recording transactions and other data. This translates into stringent
RTOs and RPOs. Achievement of these is possible only through remote business-ready
hot DR sites with data replication periodically, if not almost entirely, online. Such a setup
cannot be managed through manual processes to be effective either on a day-to-day basis
or on the day of the disaster. Therefore, today all backup, replication, recovery and
restoration processes are managed through software that combines with the devices. The
IS auditor needs to be familiar with such systems, their capabilities and limitations, to
effectively audit them.

While the testing of business continuity plans with various testing techniques and drills is
the best possible way to ensure that the plans and the expensive systems deployed really
work on the day of disaster, such tests have some limitations as they often need to be
planned in advance. An effective audit review by a capable IS auditor can help uncover
many deficiencies and operational lapses that may not come up in testing and points that
have been overlooked in the design of the plan. Hence, an IS audit of the business
continuity plan should be carried out at least at yearly intervals in addition to the periodic
testing by the operating staff.
S. Anantha Sayana is general manager with Larsen & Toubro Infotech Limited,
Mumbai, India. In charge of corporate IT, his responsibilities include increasing the
realization of benefits to the business from IT, devising IT strategy and IT security
strategies for the parent company, Larsen & Toubro Limited, and other clients. With
more than 15 years of experience in information systems, security and audit, he is also a
past president of ISACA Mumbai Chapter and can be contacted at anantha.sayana@
lntinfotech.com.

Information Systems Control Journal, formerly the IS Audit & Control Journal, is
published by ISACA, Inc.. Membership in the association, a voluntary organization of
persons interested in information systems (IS) auditing, control and security, entitles one
to receive an annual subscription to the Information Systems Control Journal.

Opinions expressed in the Information Systems Control Journal represent the views of the
authors and advertisers. They may differ from policies and official statements of ISACA
and/or the IT Governance Institute and their committees, and from opinions endorsed
by authors' employers, or the editors of this Journal. Information Systems Control
Journal does not attest to the originality of authors' content.

Copyright 2005 by ISACA Inc., formerly the EDP Auditors Association. All rights res
erved. ISCATM Information Systems Control AssociationTM