IT Continuity Planning Audit/Assurance Program
ISACA®
With more than 86,000 constituents in more than 160 countries, ISACA (www.isaca.org) is a recognized worldwide
leader in IT governance, control, security and assurance. Founded in 1969, ISACA sponsors international
conferences, publishes the ISACA Journal®, and develops international information systems auditing and control
standards. It also administers the globally respected Certified Information Systems Auditor™ (CISA®) designation,
earned by more than 60,000 professionals since 1978; the Certified Information Security Manager ® (CISM®)
designation, earned by more than 10,000 professionals since 2002; and the new Certified in the Governance of
Enterprise IT™ (CGEIT™) designation.
Disclaimer
ISACA has designed and created IT Continuity Planning Audit/Assurance Program (the “Work”), primarily as an
informational resource for audit and assurance professionals. ISACA makes no claim that use of any of the Work
will assure a successful outcome. The Work should not be considered inclusive of all proper information, procedures
and tests or exclusive of other information, procedures and tests that are reasonably directed to obtaining the same
results. In determining the propriety of any specific information, procedure or test, audit/assurance professionals
should apply their own professional judgment to the specific circumstances presented by the particular systems or IT
environment.
Reservation of Rights
© 2009 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced, modified,
distributed, displayed, stored in a retrieval system or transmitted in any form by any means (electronic, mechanical,
photocopying, recording or otherwise) without the prior written authorization of ISACA. Reproduction and use of
all or portions of this publication are permitted solely for academic, internal and noncommercial use, and
consulting/advisory engagements, and must include full attribution of the material’s source. No other right or
permission is granted with respect to this work.
ISACA
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
E-mail: info@isaca.org
Web site: www.isaca.org
ISBN 978-1-60420-079-9
IT Continuity Planning Audit/Assurance Program
Printed in the United States of America
© 2009 ISACA. All rights reserved. Page 2
IT Continuity Planning Audit/Assurance Program
ISACA wishes to recognize:
Author
Norm Kelson, CISA, CGEIT, CPA, The Kelson Group, USA
Expert Reviewers
José Manuel Ballester Fernández, Ph.D., CISA, CISM, CGEIT, IEEE, IT Deusto, Spain
Dinesh O. Bareja, CISA, India
Robert B. Brenis, CISA, CGEIT, MCP, PMP, Skoda Minotti, USA
Rafael Eduardo Fabius, CISA, Republica AFAP SA, Uruguay
Anuj Goel, Ph.D., CISA, CISSP, Citigroup Inc., USA
Samuel Chiedozie Isichei, CISA, CISM, CISSP, Protiviti, USA
Kathy A. Rogers, CISA, USA
ISACA Board of Directors
Lynn Lawton, CISA, FBCS, FCA, FIIA, KPMG LLP, UK, International President
George Ataya, CISA, CISM, CGEIT, CISSP, ICT Control SA, Belgium, Vice President
Howard Nicholson, CISA, CGEIT, City of Salisbury, Australia, Vice President
Jose Angel Pena Ibarra, CGEIT, Consultoria en Comunicaciones e Info. SA & CV, Mexico, Vice President
Robert E. Stroud, CA Inc., USA, Vice President
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Vice President
Frank Yam, CISA, CIA, CCP, CFE, CFSA, FFA, FHKCS, FHKIoD, Focus Strategic Group Inc., Hong Kong, Vice
President
Marios Damianides, CISA, CISM, CA, CPA, Ernst & Young, USA, Past International President
Everett C. Johnson Jr., CPA, Deloitte & Touche LLP (retired), USA, Past International President
Gregory T. Grocholski, CISA, The Dow Chemical Company, USA, Director
Tony Hayes, Queensland Government, Australia, Director
Jo Stewart-Rattray, CISA, CISM, CSEPS, RSM Bird Cameron, Australia, Director
Assurance Committee
Gregory T. Grocholski, CISA, The Dow Chemical Company, USA, Chair
Pippa G. Andrews, CISA, ACA, CIA, Amcor, Australia
Richard Brisebois, CISA, CGA, Office of the Auditor General of Canada, Canada
Sergio Fleginsky, CISA, ICI, Uruguay
Robert Johnson, CISA, CISM, CISSP, Executive Consultant, USA
Anthony P. Noble, CISA, CCP, Viacom Inc., USA
Robert G. Parker, CISA, CA, CMC, FCA, Deloittte & Touche LLP (retired), Canada
Erik Pols, CISA, CISM, Shell International - ITCI, Netherlands
Vatsaraman Venkatakrishnan, CISA, CISM, CGEIT, ACA, Emirates Airlines, UAE
© 2009 ISACA. All rights reserved. Page 3
IT Continuity Planning Audit/Assurance Program
Table of Contents
I.
II.
III.
IV.
V.
VI.
Introduction ......................................................................................................................................... 4
Using This Document ......................................................................................................................... 5
Controls Maturity Analysis ................................................................................................................. 8
Assurance and Control Framework ..................................................................................................... 9
Executive Summary of Audit/Assurance Focus ............................................................................... 11
Audit/Assurance Program ................................................................................................................. 13
1. Planning and Scoping the Audit.................................................................................................... 13
2. Continuity Framework and Policy ................................................................................................ 17
3. Business Assessment of Contingency Planning Requirements .................................................... 18
4. Integration of Business Continuity and IT Continuity Plans ........................................................ 20
5. IT Continuity Plan......................................................................................................................... 20
VII. Maturity Assessment ......................................................................................................................... 31
VIII. Assessment Maturity vs. Target Maturity ......................................................................................... 36
I. Introduction
Overview
ISACA has developed the IT Assurance Framework (ITAFTM) as a comprehensive and good-practicesetting model. ITAF provides standards that are designed to be mandatory, and are the guiding principles
under which the IT audit and assurance profession operates. The guidelines provide information and
direction for the practice of IT audit and assurance. The tools and techniques provide methodologies,
tools and templates to provide direction in the application of IT audit and assurance processes.
Purpose
The audit/assurance program is a tool and template to be used as a road map for the completion of a
specific assurance process. ISACA’s Assurance Committee has commissioned audit/assurance programs
to be developed for use by IT audit and assurance practitioners. This audit/assurance program is intended
to be utilized by IT audit and assurance professionals with the requisite knowledge of the subject matter
under review, as described in ITAF, in section 2200—General Standards. The audit/assurance programs
are part of ITAF, section 4000—IT Assurance Tools and Techniques.
Control Framework
The audit/assurance programs have been developed in alignment with the IT Governance Institute®
(ITGI™) framework Control Objectives for Information and related Technology (COBIT ®)—specifically
COBIT 4.1—using generally applicable and accepted good practices. They reflect ITAF sections 3400—
IT Management Processes, 3600—IT Audit and Assurance Processes, and 3800—IT Audit and Assurance
Management.
Many organizations have embraced several frameworks at an enterprise level, including the Committee of
Sponsoring Organizations of the Treadway Commission (COSO) Internal Control Framework. The
importance of the control framework has been enhanced due to regulatory requirements by the US
Securities and Exchange Commission (SEC) as directed by the US Sarbanes-Oxley Act of 2002 and
similar legislation in other countries. They seek to integrate control framework elements used by the
general audit/assurance team into the IT audit and assurance framework. Since COSO is widely used, it
has been selected for inclusion in this audit/assurance program. The reviewer may delete or rename these
columns to align with the enterprise’s control framework.
© 2009 ISACA. All rights reserved. Page 4
IT Continuity Planning Audit/Assurance Program
IT Governance, Risk and Control
IT governance, risk and control are critical in the performance of any assurance management process.
Governance of the process under review will be evaluated as part of the policies and management
oversight controls. Risk plays an important role in evaluating what to audit and how management
approaches and manages risk. Both issues will be evaluated as steps in the audit/assurance program.
Controls are the primary evaluation point in the process. The audit/assurance program will identify the
control objectives and the steps to determine control design and effectiveness.
Responsibilities of IT Audit and Assurance Professionals
IT audit and assurance professionals are expected to customize this document to the environment in
which they are performing an assurance process. This document is to be used as a review tool and starting
point. It may be modified by the IT audit and assurance professional; it is not intended to be a checklist or
questionnaire. It is assumed that the IT audit and assurance professional holds the Certified Information
Systems Auditor (CISA) designation, or has the necessary subject matter expertise required to conduct the
work and is supervised by a professional with the CISA designation and/or necessary subject matter
expertise to adequately review the work performed.
II. Using This Document
This audit/assurance program was developed to assist the audit and assurance professional in designing
and executing a review. Details regarding the format and use of the document follow.
Work Program Steps
The first column of the program describes the steps to be performed. The numbering scheme used
provides built-in work paper numbering for ease of cross-reference to the specific work paper for that
section. The physical document was designed in Microsoft® Word. The IT audit and assurance
professional is encouraged to make modifications to this document to reflect the specific environment
under review.
Step 1 is part of the fact gathering and pre-fieldwork preparation. Because the pre-fieldwork is essential to
a successful and professional review, the steps have been itemized in this plan. The first level steps, e.g,,
1.1, are in bold type and provide the reviewer with a scope or high-level explanation of the purpose for
the substeps.
Beginning in step 2, the steps associated with the work program are itemized. To simplify the use of the
program, the audit/assurance program describes the audit/assurance objective—the reason for performing
the steps in the topic area. The specific controls follow and are shown in blue type. Each review step is
listed below the control. These steps may include assessing the control design by walking through a
process, interviewing, observing or otherwise verifying the process and the controls that address that
process. In many cases, once the control design has been verified, specific tests need to be performed to
provide assurance that the process associated with the control is being followed.
The maturity assessment, which is described in more detail later in this document, makes up the last
section of the program.
The audit/assurance plan wrap-up—those processes associated with the completion and review of work
papers, preparation of issues and recommendations, report writing and report clearing—has been
excluded from this document, since it is standard for the audit/assurance function and should be identified
elsewhere in the enterprise’s standards.
© 2009 ISACA. All rights reserved. Page 5
IT Continuity Planning Audit/Assurance Program
COBIT Cross-reference
The COBIT cross-reference provides the audit and assurance professional with the ability to refer to the
specific COBIT control objective that supports the audit/assurance step. The COBIT control objective
should be identified for each audit/assurance step in the section. Multiple cross-references are not
uncommon. Processes at lower levels in the work program are too granular to be cross-referenced to
COBIT. The audit/assurance program is organized in a manner to facilitate an evaluation through a
structure parallel to the development process. COBIT provides in-depth control objectives and suggested
control practices at each level. As the professional reviews each control, he/she should refer to COBIT 4.1
or the IT Assurance Guide: Using COBIT for good-practice control guidance.
COSO Components
As noted in the introduction, COSO and similar frameworks have become increasingly popular among
audit/assurance professionals. This ties the assurance work to the enterprise’s control framework. While
the IT audit/assurance function uses COBIT as a framework, operational audit and assurance professionals
use the framework established by the enterprise. Since COSO is the most prevalent internal control
framework, it has been included in this document and is a bridge to align IT audit/assurance with the rest
of the audit/assurance function. Many audit/assurance organizations include the COSO control
components within their report, and summarize assurance activities to the audit committee of the board of
directors.
For each control, the audit and assurance professional should indicate the COSO component(s) addressed.
It is possible, but generally not necessary, to extend this analysis to the specific audit step level.
The original COSO internal control framework contained five components. In 2004, COSO was revised
as the Enterprise Risk Management (ERM) Integrated Framework and extended to eight components. The
primary difference between the two frameworks is the additional focus on ERM and integration into the
business decision model. ERM is in the process of being adopted by large enterprises. The two
frameworks are compared in figure 1.
Figure 1—Comparison of COSO Internal Control and ERM Integrated Frameworks
Internal Control Framework
ERM Integrated Framework
Control Environment: The control environment sets the tone of an
organization, influencing the control consciousness of its people. It is
the foundation for all other components of internal control, providing
discipline and structure. Control environment factors include the
integrity, ethical values, management’s operating style, delegation of
authority systems, as well as the processes for managing and
developing people in the organization.
Risk Assessment: Every entity faces a variety of risks from external
and internal sources that must be assessed. A precondition to risk
assessment is establishment of objectives, and, thus, risk assessment is
the identification and analysis of relevant risks to achievement of
assigned objectives. Risk assessment is a prerequisite for determining
how the risks should be managed.
Internal Environment: The internal environment encompasses the
tone of an organization, and sets the basis for how risk is viewed and
addressed by an entity’s people, including risk management
philosophy and risk appetite, integrity and ethical values, and the
environment in which they operate.
Objective Setting: Objectives must exist before management can
identify potential events affecting their achievement. Enterprise risk
management ensures that management has in place a process to set
objectives and that the chosen objectives support and align with the
entity’s mission and are consistent with its risk appetite.
Event Identification: Internal and external events affecting
achievement of an entity’s objectives must be identified,
distinguishing between risks and opportunities. Opportunities are
channeled back to management’s strategy or objective-setting
processes.
Risk Assessment: Risks are analyzed, considering the likelihood and
impact, as a basis for determining how they could be managed. Risk
areas are assessed on an inherent and residual basis.
Risk Response: Management selects risk responses—avoiding,
accepting, reducing or sharing risk—developing a set of actions to
align risks with the entity’s risk tolerances and risk appetite.
© 2009 ISACA. All rights reserved. Page 6
IT Continuity Planning Audit/Assurance Program
Figure 1—Comparison of COSO Internal Control and ERM Integrated Frameworks
Internal Control Framework
ERM Integrated Framework
Control Activities: Control activities are the policies and procedures
that help ensure management directives are carried out. They help
ensure that necessary actions are taken to address risks to achievement
of the entity's objectives. Control activities occur throughout the
organization, at all levels and in all functions. They include a range of
activities as diverse as approvals, authorizations, verifications,
reconciliations, reviews of operating performance, security of assets
and segregation of duties.
Information and Communication: Information systems play a key
role in internal control systems as they produce reports, including
operational, financial and compliance-related information that make it
possible to run and control the business. In a broader sense, effective
communication must ensure information flows down, across and up
the organization. Effective communication should also be ensured with
external parties, such as customers, suppliers, regulators and
shareholders.
Monitoring: Internal control systems need to be monitored—a
process that assesses the quality of the system’s performance over
time. This is accomplished through ongoing monitoring activities or
separate evaluations. Internal control deficiencies detected through
these monitoring activities should be reported upstream and corrective
actions should be taken to ensure continuous improvement of the
system.
Control Activities: Policies and procedures are established and
implemented to help ensure the risk responses are effectively carried
out.
Information and Communication: Relevant information is
identified, captured and communicated in a form and time frame that
enable people to carry out their responsibilities. Effective
communication also occurs in a broader sense, flowing down, across
and up the entity.
Monitoring: The entirety of enterprise risk management is monitored
and modifications are made as necessary. Monitoring is accomplished
through ongoing management activities, separate evaluations or both.
Information for figure 1 was obtained from the COSO web site www.coso.org/aboutus.htm.
The original COSO internal control framework addresses the needs of the IT audit and assurance
professional: control environment, risk assessment, control activities, information and communication,
and monitoring. As such, ISACA has elected to utilize the five-component model for these audit/
assurance programs. As more enterprises implement the ERM model, the additional three columns can be
added, if relevant. When completing the COSO component columns, consider the definitions of the
components as described in figure 1.
Reference/Hyperlink
Good practices require the audit and assurance professional to create a work paper for each line item,
which describes the work performed, issues identified and conclusions. The reference/hyperlink is to be
used to cross-reference the audit/assurance step to the work paper that supports it. The numbering system
of this document provides a ready numbering scheme for the work papers. If desired, a link to the work
paper can be pasted into this column.
Issue Cross-reference
This column can be used to flag a finding/issue that the IT audit and assurance professional wants to
further investigate or establish as a potential finding. The potential findings should be documented in a
work paper that indicates the disposition of the findings (formally reported, reported as a memo or verbal
finding, or waived).
Comments
The comments column can be used to indicate the waiving of a step or other notations. It is not to be used
in place of a work paper describing the work performed.
© 2009 ISACA. All rights reserved. Page 7
IT Continuity Planning Audit/Assurance Program
III. Controls Maturity Analysis
One of the consistent requests of stakeholders who have undergone IT audit/assurance reviews is a desire
to understand how their performance compares to good practices. Audit and assurance professionals must
provide an objective basis for the review conclusions. Maturity modeling for management and control
over IT processes is based on a method of evaluating the enterprise, so it can be rated from a maturity
level of nonexistent (0) to optimized (5). This approach is derived from the maturity model that the
Software Engineering Institute (SEI) of Carnegie Mellon University defined for the maturity of software
development.
The IT Assurance Guide Using COBIT, Appendix VII—Maturity Model for Internal Control, in figure 2,
provides a generic maturity model showing the status of the internal control environment and the
establishment of internal controls in an enterprise. It shows how the management of internal control, and
an awareness of the need to establish better internal controls, typically develops from an ad hoc to an
optimized level. The model provides a high-level guide to help COBIT users appreciate what is required
for effective internal controls in IT and to help position their enterprise on the maturity scale.
Maturity Level
0 Non-existent
1 Initial/ad hoc
2 Repeatable but
Intuitive
3 Defined
4 Managed and
Measurable
5 Optimized
Figure 2—Maturity Model for Internal Control
Status of the Internal Control Environment
Establishment of Internal Controls
There is no recognition of the need for internal control.
Control is not part of the organization’s culture or mission.
There is a high risk of control deficiencies and incidents.
There is some recognition of the need for internal control.
The approach to risk and control requirements is ad hoc and
disorganized, without communication or monitoring.
Deficiencies are not identified. Employees are not aware of
their responsibilities.
Controls are in place but are not documented. Their operation
is dependent on the knowledge and motivation of individuals.
Effectiveness is not adequately evaluated. Many control
weaknesses exist and are not adequately addressed; the
impact can be severe. Management actions to resolve control
issues are not prioritized or consistent. Employees may not be
aware of their responsibilities.
Controls are in place and adequately documented. Operating
effectiveness is evaluated on a periodic basis and there is an
average number of issues. However, the evaluation process is
not documented. While management is able to deal
predictably with most control issues, some control
weaknesses persist and impacts could still be severe.
Employees are aware of their responsibilities for control.
There is an effective internal control and risk management
environment. A formal, documented evaluation of controls
occurs frequently. Many controls are automated and regularly
reviewed. Management is likely to detect most control issues,
but not all issues are routinely identified. There is consistent
follow-up to address identified control weaknesses. A
limited, tactical use of technology is applied to automate
controls.
An enterprisewide risk and control program provides
continuous and effective control and risk issues resolution.
Internal control and risk management are integrated with
enterprise practices, supported with automated real-time
monitoring with full accountability for control monitoring,
risk management and compliance enforcement. Control
evaluation is continuous, based on self-assessments and gap
and root cause analyses. Employees are proactively involved
in control improvements.
There is no intent to assess the need for internal control.
Incidents are dealt with as they arise.
There is no awareness of the need for assessment of what is
needed in terms of IT controls. When performed, it is only on
an ad hoc basis, at a high level and in reaction to significant
incidents. Assessment addresses only the actual incident.
Assessment of control needs occurs only when needed for
selected IT processes to determine the current level of control
maturity, the target level that should be reached and the gaps
that exist. An informal workshop approach, involving IT
managers and the team involved in the process, is used to
define an adequate approach to controls for the process and to
motivate an agreed-upon action plan.
Critical IT processes are identified based on value and risk
drivers. A detailed analysis is performed to identify control
requirements and the root cause of gaps and to develop
improvement opportunities. In addition to facilitated
workshops, tools are used and interviews are performed to
support the analysis and ensure that an IT process owner
owns and drives the assessment and improvement process.
IT process criticality is regularly defined with full support
and agreement from the relevant business process owners.
Assessment of control requirements is based on policy and
the actual maturity of these processes, following a thorough
and measured analysis involving key stakeholders.
Accountability for these assessments is clear and enforced.
Improvement strategies are supported by business cases.
Performance in achieving the desired outcomes is
consistently monitored. External control reviews are
organized occasionally.
Business changes consider the criticality of IT processes and
cover any need to reassess process control capability. IT
process owners regularly perform self-assessments to confirm
that controls are at the right level of maturity to meet
business needs and they consider maturity attributes to find
ways to make controls more efficient and effective. The
organization benchmarks to external best practices and seeks
external advice on internal control effectiveness. For critical
processes, independent reviews take place to provide
assurance that the controls are at the desired level of maturity
and working as planned.
© 2009 ISACA. All rights reserved. Page 8
IT Continuity Planning Audit/Assurance Program
The maturity model evaluation is one of the final steps in the evaluation process. The IT audit and
assurance professional can address the key controls within the scope of the work program and formulate
an objective assessment of the maturity levels of the control practices. The maturity assessment can be a
part of the audit/assurance report and can be used as a metric from year to year to document progression
in the enhancement of controls. However, it must be noted that the perception as to the maturity level may
vary between the process/IT asset owner and the auditor. Therefore, an auditor should obtain the
concerned stakeholder’s concurrence before submitting the final report to management.
At the conclusion of the review, once all findings and recommendations are completed, the professional
assesses the current state of the COBIT control framework, and assigns it a maturity level using the sixlevel scale. Some practitioners utilize decimals (x.25, x.5, x.75) to indicate gradations in the maturity
model. As a further reference, COBIT provides a definition of the maturity designations by control
objective. While this approach is not mandatory, the process is provided as a separate section at the end of
the audit/assurance program for those enterprises that wish to implement it. It is suggested that a maturity
assessment be made at the COBIT control level. To provide further value to the client/customer, the
professional can also obtain maturity targets from the client/customer. Using the assessed and target
maturity levels, the professional can create an effective graphic presentation that describes the
achievement or gaps between the actual and targeted maturity goals. A graphic is provided as the last
page of the document (section VIII), based on sample assessments.
IV. Assurance and Control Framework
ISACA IT Assurance Framework and Standards
The following ITAF sections are relevant to IT continuity planning:
 3630.2—Information Resource Planning
 3630.3—IT Service Delivery
 3630.4—Information Systems Operations
 3630.6—Outsourced and Third-party IT Activities
 3630.8—Systems Development Life Cycle
 3630.9—Business Continuity Plan and Disaster Recovery Plan
ISACA has long recognized the specialized nature of IT assurance and strives to advance globally
applicable standards. Guidelines and procedures provide detailed guidance on how to follow those
standards. IS Auditing Guideline G32 Business Continuity Plan Review From IT Perspective is relevant
to this audit/assurance program.
ISACA Controls Framework
COBIT is an IT governance framework and supporting tool set that allows managers to bridge the gap
among control requirements, technical issues and business risks. COBIT enables clear policy development
and good practice for IT control throughout enterprises.
Utilizing COBIT as the control framework from which IT audit/assurance activities are based aligns IT
audit/assurance with good practices as developed by the enterprise.
The COBIT IT process, DS4 Ensure continuous service, from the Deliver and Support (DS) domain,
addresses good practices for ensuring continuous service. The COBIT areas for this evaluation include:
 DS4 Ensure continuous service—The need for providing continuous IT services requires developing,
maintaining and testing IT continuity plans, utilizing offsite backup storage and providing periodic
© 2009 ISACA. All rights reserved. Page 9
IT Continuity Planning Audit/Assurance Program









continuity plan training. An effective continuous service process minimizes the probability and impact
of a major IT service interruption on key business functions and processes.
DS4.1 IT continuity framework—Develop a framework for IT continuity to support enterprisewide
business continuity management using a consistent process. The objective of the framework should be
to assist in determining the required resilience of the infrastructure and to drive the development of
disaster recovery and IT contingency plans. The framework should address the organizational
structure for continuity management, covering the roles, tasks and responsibilities of internal and
external service providers, their management and their customers, and the planning processes that
create the rules and structures to document, test and execute the disaster recovery and IT contingency
plans. The plan should also address items such as the identification of critical resources, noting key
dependencies, the monitoring and reporting of the availability of critical resources, alternative
processing, and the principles of backup and recovery.
DS4.2 IT continuity plans—Develop IT continuity plans based on the framework and designed to
reduce the impact of a major disruption on key business functions and processes. The plans should be
based on risk understanding of potential business impacts and address requirements for resilience,
alternative processing and recovery capability of all critical IT services. They should also cover usage
guidelines, roles and responsibilities, procedures, communication processes, and the testing approach.
DS4.3 Critical IT resources—Focus attention on items specified as most critical in the IT continuity
plan to build in resilience and establish priorities in recovery situations. Avoid the distraction of
recovering less-critical items and ensure response and recovery in line with prioritized business needs,
while ensuring that costs are kept at an acceptable level and complying with regulatory and
contractual requirements. Consider resilience, response and recovery requirements for different tiers,
e.g., one to four hours, four to 24 hours, more than 24 hours and critical business operational periods.
DS4.4 Maintenance of the IT continuity plan—Encourage IT management to define and execute
change control procedures to ensure that the IT continuity plan is kept up to date and continually
reflects actual business requirements. Communicate changes in procedures and responsibilities clearly
and in a timely manner.
DS4.5 Testing of the IT continuity plan—Test the IT continuity plan on a regular basis to ensure that
IT systems can be effectively recovered, shortcomings are addressed and the plan remains relevant.
This requires careful preparation, documentation, reporting of test results and, according to the results,
implementation of an action plan. Consider the extent of testing recovery of single applications to
integrated testing scenarios to end-to-end testing and integrated vendor testing.
DS4.6 IT continuity plan training—Provide all concerned parties with regular training sessions
regarding the procedures and their roles and responsibilities in case of an incident or disaster. Verify
and enhance training according to the results of the contingency tests.
DS4.7 Distribution of the IT continuity plan—Determine that a defined and managed distribution
strategy exists to ensure that plans are properly and securely distributed and available to appropriately
authorized interested parties, when and where needed. Attention should be paid to making the plans
accessible under all disaster scenarios.
DS4.8 IT services recovery and resumption—Plan the actions to be taken for the period when IT is
recovering and resuming services. This may include activation of backup sites, initiation of alternative
processing, customer and stakeholder communication, and resumption procedures. Ensure that the
business understands IT recovery times and the necessary technology investments to support business
recovery and resumption needs.
DS4.9. Offsite backup storage—Store offsite all critical backup media, documentation and other IT
resources necessary for IT recovery and business continuity plans. Determine the content of backup
storage in collaboration with business process owners and IT personnel. Management of the offsite
storage facility should respond to the data classification policy and the enterprise’s media storage
practices. IT management should ensure that offsite arrangements are periodically assessed, at least
annually, for content, environmental protection and security. Ensure compatibility of hardware and
software to restore archived data, and periodically test and refresh archived data.
© 2009 ISACA. All rights reserved. Page 10
IT Continuity Planning Audit/Assurance Program

DS4.10 Post-resumption review—Determine whether IT management has established procedures for
assessing the adequacy of the plan in regard to the successful resumption of the IT function after a
disaster, and update the plan accordingly.
Refer to the IT Governance Institute’s COBIT Control Practices: Guidance to Achieve Control Objectives
for Successful IT Governance, 2nd Edition, published in 2007, for the related control practice value and
risk drivers.
V. Executive Summary of Audit/Assurance Focus
IT Continuity Planning
IT continuity planning is the process that ensures continuous operations of business applications and
supporting IT systems (i.e., desktops, printers, network devices). IT continuity planning is a subset of
enterprise business continuity planning. A business continuity plan is an enterprisewide group of
processes and instructions to ensure the continuation of business processes in the event of an interruption.
It provides the plans for the enterprise to recover from minor incidents (e.g., localized disruptions of
business components) to major disruptions (e.g., fire, natural disasters, extended power failures,
equipment and/or telecommunications failure). The plan is usually owned and managed by the business
units and a disaster management or risk prevention function in the enterprise.
The IT continuity plan addresses the IT exposures and solutions based on the priorities and framework of
the business continuity plan. The role of the IT audit/assurance function is to address IT continuity risks.
The business continuity plan should be evaluated for any guidance addressing its framework, priorities,
responsibilities and objectives.
The IT continuity plan must be aligned with the business continuity plan to ensure that:
 Risks are appropriately identified and evaluated by focusing on impact on business processes for
known and potential risks
 The costs of implementing and managing continuity assurance are less than the expected losses and
within management’s risk tolerance
 The business priorities are addressed (critical applications, interim processes, restoration activities and
mandated deadlines)
 Manual interfaces to automated processes are identified, personnel are trained, and practice drills are
conducted
 Expectations are managed with realistic goals
Business Impact and Risk
Business reliance on automated solutions is tightly woven within the DNA of the enterprise. Applications,
whether developed or acquired, are the operational backbone of a business. The risks and potential
impacts to the enterprise for failure to establish a good-practice IT continuity plan and align it with the
business continuity plan include enterprise inability to conduct normal business functions after a
disruption due to:
 Failure of plans to reflect changes to business needs, applications portfolio or technology
 Inadequate planning and consideration of significant enterprise risk
 Failure to plan for or inability to assess the situation and implement alternate processes to fit
unforeseen situation
 Inappropriate or incomplete recovery plans and processes, resulting in delayed restoration of
processing
 Incomplete or untested interim processing and logistics plans
© 2009 ISACA. All rights reserved. Page 11
IT Continuity Planning Audit/Assurance Program









Inadequate training and/or staff not prepared to execute the plan effectively and quickly
Inadequate or unavailable staffing resources to restore processes on a timely basis 
Lack of plan change control, resulting in out-of-date restoration processes
Unavailability of backup data and media due to missing documentation in offsite storage, accidental
destruction of backup data, inability to locate media when needed, or inability to transport data within
the prescribed time frame
Regulatory violations resulting in fines or censure
Reputational risk resulting in loss of customer confidence
Increased costs for continuity management due to ineffective focus on risks and costs or failure to
prioritize services recovery based on business need
Lack of development of realistic threat scenarios that may potentially disrupt business processes
Lack of consideration of all possible threat scenarios based upon potential circumstances and events
Objective and Scope
Objective—The IT continuity planning audit/assurance review will:
 Provide management with an evaluation of the IT function’s preparedness in the event of a process
disruption
 Identify issues that may limit interim business processing and restoration of same
 Provide management with an independent assessment relating to the effectiveness of the IT continuity
plan and its alignment with the business continuity plan and IT security policy
Scope—The review will focus on the IT continuity plan and its alignment with the enterprise business
continuity plan, policies, standards, guidelines, procedures, laws and regulations that addresses
maintaining continuous IT services. This will address:
 Development, maintenance and testing of the IT continuity plan
 Ability to provide interim IT services and the restoration of same
 Risk management and costs related to the IT continuity plan
The review relies on the existence of a business continuity plan. Policy, standards and guidelines related
to and implementation of the business continuity plan are outside the scope of this review.
Minimum Audit Skills
The IT audit and assurance professional should have an understanding of the good-practice systems
development business continuity and disaster recovery processes and requirements. Professionals holding
CISA certification should have these skills.
© 2009 ISACA. All rights reserved. Page 12
IT Continuity Planning Audit/Assurance Program
VI. Audit/Assurance Program
1. PLANNING AND SCOPING THE AUDIT
1.1 Define audit/assurance objectives.
The audit/assurance objectives are high level and describe the overall audit goals.
1.1.1 Review the audit/assurance objectives in the introduction to this
audit/assurance program.
1.1.2 Modify the audit/assurance objectives to align with the audit/assurance
universe, annual plan and charter.
1.2 Define boundaries of review.
The review must have a defined scope. The reviewer should understand the operating
environment and prepare a proposed scope, subject to a later risk assessment.
1.2.1 Obtain and review the business continuity and IT continuity policies.
1.2.2 Obtain and review the BCP and the ITCP.
1.2.3 Determine the entities, processes and systems addressed in the BCP and
ITCP.
1.2.4 Establish initial boundaries of the audit/assurance review.
1.2.5 Obtain and review any previous audit reports with remediation plans.
Identify open issues and assess updates of documents with respect to these
issues.
1.2.6 Identify limitations and/or constraints affecting the audit of specific
systems.
© 2009 ISACA. All rights reserved. Page 13
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
1.3 Define assurance.
The review requires two sources of standards. The corporate standards defined in the
policy and procedure documentation establish the corporate expectations. At minimum,
corporate standards should be implemented. The second source, a good-practice
reference, establishes industry standards. Enhancements should be proposed to address
gaps between the two.
1.3.1 Review the business continuity policy and standards.
1.3.2 Determine if COBIT and the appropriate business continuity framework will
be used as a good-practice reference.
1.3.3 Determine if there are gaps in the policy.
1.4 Identify and document risks.
The risk assessment is necessary to evaluate where audit resources should be focused.
In most enterprises, audit resources are not available for all processes. The risk-based
approach assures utilization of audit resources in the most effective manner.
1.4.1 Identify the business risk associated with the BCP and ITCP.
1.4.2 Obtain and review the business impact analysis (BIA) document.
1.4.3 Review previous audits of BCP and ITCP and other assessments.
1.4.4 Determine if issues identified previously have been remediated.
1.4.5 Evaluate the overall risk factor for performing the review.
1.4.6 Based on the risk assessment, identify changes to the scope.
1.4.7 Discuss the risks with IT, business and operational audit management, and
adjust the risk assessment.
1.4.8 Based on the risk assessment, revise the scope.
© 2009 ISACA. All rights reserved. Page 14
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
1.5 Define the change process.
The initial audit approach is based on the reviewer’s understanding of the operating
environment and associated risks. As further research and analysis are performed,
changes to the scope and approach will result.
1.5.1 Identify the senior IT assurance resource responsible for the review.
1.5.2 Establish the process for suggesting and implementing changes to the
audit/assurance program, and the authorizations required.
1.6 Define assignment success.
The success factors need to be identified. Communication among the IT
audit/assurance team, other assurance teams and the enterprise is essential.
1.6.1 Identify the drivers for a successful review (this should exist in the
assurance function’s standards and procedures).
1.6.2 Communicate success attributes to the process owner or stakeholder and
obtain agreement.
1.7 Define audit/assurance resources required.
The resources required are defined in the introduction to this audit/assurance program.
1.7.1 Determine the audit/assurance skills necessary for the review.
1.7.2 Estimate the total resources (hours) and time frame (start and end dates)
required for the review.
1.8 Define deliverables.
The deliverable is not limited to the final report. Communication between the
audit/assurance teams and the process owner is essential to assignment success.
1.8.1 Determine the interim deliverables, including initial findings, status reports,
draft reports, due dates for responses or meetings, and the final report.
© 2009 ISACA. All rights reserved. Page 15
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
1.9 Communications
The audit/assurance process must be clearly communicated to the customer/client.
1.9.1 Conduct an opening conference to discuss the review objectives with the
BCP committee, IT management and key user management directly
responsible for the business recovery planning effort. The scope of this
program should include the following areas:
 Business assessment
 Recovery strategy
 Plan development
 Communications recovery (voice and data)
 Hardware/software
 Facilities recovery
 Staff recovery
 Plan maintenance
 Plan testing
© 2009 ISACA. All rights reserved. Page 16
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
X
X
X
X
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
2. CONTINUITY FRAMEWORK AND POLICY
2.1 IT continuity framework
Audit/assurance objective: A framework for IT continuity to support enterprisewide
business continuity management using a consistent process should be developed. The
business continuity effort should be sponsored by the management of the business units
or a business continuity task force. The framework should address the organizational
structure for continuity management, covering the roles, tasks and responsibilities of
internal and external service providers, their management and their customers, and the
planning processes that create the rules and structures to document, test and execute the
disaster recovery and IT contingency plans. The plan should also address items such as
the identification of critical resources, noting key dependencies; the monitoring and
reporting of the availability of critical resources; alternative processing; and the
principles of backup and recovery.
2.1.1 Organization and governance
Control: The business has established a business continuity task force/
committee/organization to establish and maintain a business continuity
process.
DS4.1
DS4.2
X
2.1.1.1 Determine if the enterprise has a BCP project plan or program,
and indicate the date of acceptance and/or review.
2.1.1.2 Determine if a budget for BCP and its components are included in
the enterprise’s budget.
2.1.1.3 Determine if the BCP team member roles and responsibilities have
been assigned at an appropriate level of authority to carry out
responsibilities, and the team has appropriate executive sponsors.
2.1.2 Participation
Control: The business continuity function includes representatives from
affected business areas and IT, and the responsibility for the business
continuity function is assigned to business operations and not IT.
DS4.3
2.1.2.1 Determine if the members of the BCP team are representatives
from the affected organizations.
© 2009 ISACA. All rights reserved. Page 17
X
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
2.1.2.2 Determine if the leadership and sponsorship of the BCP is assigned
to the business, and is not driven by IT.
2.1.2.3 Determine if the responsibility for the BCP process reports is
assigned to an executive at a senior level in the enterprise to
receive adequate support and resources.
2.1.3 Mission statement
Control: The mission statement and goals of the BCP team are in alignment
with the enterprise’s policies addressing business continuity.
DS4.1
X
X
DS4.1
X
X
X
PO4.8
DS4.1
DS4.2
X
X
X
2.1.3.1 Review the BCP policy and mission statements to ensure that they
are in alignment.
2.1.4 Risk-focused BCP
Control: The BCP utilizes risk analysis to determine the strategy and
recovery plans.
2.1.4.1 Determine if the framework requires reliance on risk assessments
and BIA to determine critical resource requirements, alternative
processing strategies and recovery.
3. BUSINESS ASSESSMENT OF CONTINGENCY PLANNING REQUIREMENTS
3.1 Business assessment
Audit/assurance objective: The business recovery needs and the drivers for the
development of an ITCP plan should be identified.
3.1.1 Risk assessment
Control: Risk assessment and BIA methods are utilized to establish business
interruption exposures, their probability and impact, and remediation
alternatives.
3.1.1.1 Determine if a risk assessment has been performed that identifies
business and operational exposures, including both physical
(floods, hurricanes, power failures) and operational (failures
caused by error or facilities interruptions) exposures.
© 2009 ISACA. All rights reserved. Page 18
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
3.1.1.2 Determine if the BIA has identified all of the critical and
necessary business functions and their resource dependencies.
3.1.1.3 Determine if a BIA to assess potential business losses from any
event that interrupts a major business process has been conducted
and documented. The BIA should document an enterprises’s
business processes, their criticality and recovery time objectives,
and the resources needed to recover them.
3.1.1.4 Determine if the risk assessment is extended to include physical
(loss of processing facilities—owned, leased or outsourced) and
logical (communications failure, denial-of-service attacks,
viruses, systems development and vendor failure, etc.) IT risks.
3.1.1.5 Review the BIA and determine if it includes an estimate of the
financial, operational and regulatory/compliance exposures and
impact of a disruption.
3.1.1.6 Review the risk assessment and determine if it documents the
mitigating steps that are in place to address these threats.
3.1.2 Recovery point objectives
Control: Recovery point objectives (RPOs) have been established to provide
guidelines for the time required to restore or provide interim services.
DS4.2
3.1.2.1 Determine if recovery time objectives (RTOs) have been assigned
to all critical business process components. The RTO is the
amount of time allowed for the recovery of a business function.
3.1.2.2 Review and determine if RPOs that address the amount of data
that is allowed to be lost during recovery have been established
for the major applications and whether the RPOs appear to be
reasonable.
© 2009 ISACA. All rights reserved. Page 19
X
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
Information and
Communication
Monitoring
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
X
X
4. INTEGRATION OF BUSINESS CONTINUITY AND IT CONTINUITY PLANS
4.1 BCP development
Audit/assurance objective: An ITCP should be established to reflect the BCP.
4.1.1 Alignment of BCP and ITCP
Control: The ITCP is aligned with and supports the business continuity
plan.
DS4.1
DS4.2
X
X
4.1.1.1 Determine if the establishment of an ITCP is a subset of BCP and
supports the BCP.
4.1.1.2 Determine the enterprise’s BCP environmental components
addressed (facility, power, staff, etc.) that allow the business to
function.
5. IT CONTINUITY PLAN
5.1 ITCP development
Audit /assurance objective: The ITCP should be complete and should address the
business continuity requirements defined in the BCP.
5.1.1 Communications
Control: The communications components necessary to provide network
access to the computing facilities are included in the ITCP.
DS4.2
DS4.3
DS4.8
5.1.1.1 Confirm the existence of a network diagram by obtaining the most
recent copy, noting the date.
5.1.1.2 Confirm with the communications department the accuracy and
completeness of the network diagram.
5.1.1.3 Confirm the existence of a network circuit inventory by obtaining
a copy, noting the date.
5.1.1.4 Confirm that the circuit inventory contains information regarding:
 Voice and data lines
 Configuration
© 2009 ISACA. All rights reserved. Page 20
X
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program











Circuit number
Origination and termination
Line speed
Line type (leased, copper T1, fiber T3, dial-up, etc.)
Primary use (data or voice)
Carrier
Vendor identification and information
Switching equipment (onsite and offsite)
Fail-over arrangements
Critical applications supported
If the primary use is for both data and voice, determining the
estimated percentage of each by interviewing the
communications department personnel
5.1.1.5 In reviewing the communications section of the plan, note the
existence of a list of primary and alternate members of the
communications recovery team. Verify the accuracy of the list
by:
 Confirming that team members are actively employed by the
company
 Obtaining an organization chart for the communications
department or IT department and confirming that each team
member is listed on the chart
 Confirming with team members:
–
Awareness of their responsibilities
–
Information such as phone numbers and work location as
referenced in the notification procedures
5.1.1.6 Determine what arrangements have been made to recover the
communications environment and ascertain that they have been
reviewed and approved by an appropriate level of senior
management. To do so:
 Review the facilities strategy (hot site, cold site, etc.) and
determine if there are provisions in the strategy for
© 2009 ISACA. All rights reserved. Page 21
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program




communications equipment.
If a contract exists for an offsite location, determine if it
includes commitments for network support.
Review contracts with communications vendors and determine
their commitment to restoring network switching capabilities.
If an onsite telephone system is installed, confirm the existence
of alternate outside phone lines for backup.
If no onsite telephone system exists, determine what
arrangements have been made to move key employees whose
primary duties require the use of a telephone to an alternate
site.
5.1.1.7 Confirm that an inventory list exists for telecommunications
equipment required by the critical applications by obtaining a copy
for the documentation.
5.1.1.8 Obtain an organization chart of the network administration
department, and verify that the employees listed in the employee
and vendor contact list are on the chart and the information on the
list is accurate. Note: This information may already be included in
the hardware requirements inventory of this audit program. If it is,
then indicate so by referencing that section.
5.1.1.9 Review the communications recovery action steps contained in the
business recovery plan. Note any discrepancies.
5.1.2 Hardware
Control: The hardware configuration and procurement plans provide for
the ability to acquire and configure hardware within the interim period
established in the BCP.
DS4.2
DS4.3
DS4.8
5.1.2.1 Confirm that an inventory of current hardware exists by obtaining
a copy, noting the date.
5.1.2.2 For each device, the inventory should include:
 Vendor
© 2009 ISACA. All rights reserved. Page 22
X
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program







Model number
Serial number
Location
Brief description of equipment (e.g., central processing unit,
modem, firewall, tape drive)
Original purchase cost
Monthly lease amount
Purchase date
5.1.2.3 Confirm the existence of an adequate hardware requirements
inventory list for critical applications by obtaining a copy and
reviewing it for the types of items listed previously.
5.1.2.4 If a contract exists for an offsite location, obtain a copy of the
scheduled equipment and compare it with the current inventory.
Confirm with IT management that the hardware is adequate and
compatible to meet the recovery requirements.
5.1.2.5 Determine what arrangements have been made to obtain hardware
not previously subscribed to or leased ahead of time.
5.1.2.6 Confirm that there is a current hardware configuration layout by
obtaining a copy and noting the date. The layout should show the
physical location of each hardware device.
5.1.3 Software critical systems and applications
Control: The critical applications and supporting platforms have been
identified, and the required software and data are available for interim
processing and restoration, and are in alignment with the BCP.
PO4.2
DS4.2
DS4.3
DS4.4
5.1.3.1 Confirm that a list of all critical applications exists by obtaining a
copy. This list should identify:
 The prioritization of applications to be recovered
 The system (server, mainframe, etc.) on which each
application is loaded and running, and the physical location of
that system
© 2009 ISACA. All rights reserved. Page 23
X
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
5.1.3.2 Compare the list of all critical applications to the recovery plan to
determine if a recovery strategy exists for each critical application.
5.1.3.3 Compare the list of all critical applications to the hardware
inventory in the recovery plans to ensure that each critical
application will have the necessary hardware resources available.
5.1.3.4 Confirm that a recovery job schedule exists that shows the
recovery sequence of the critical applications. Obtain copies for
the documentation.
5.1.3.5 Determine how often the critical applications list is reviewed and
updated. If the list has not been updated within the last three
months, verify its accuracy with the operations manager and key
users of the applications listed.
5.1.3.6 Confirm that a list exists of all users for each application identified
on the critical applications list. This list should also indicate which
skills the users would need in a recovery effort.
5.1.3.7 Confirm the existence of a list that identifies the systems software
with the following descriptions:
 Operating system
 Release, version level, service pack level, etc.
 Serial number (if any)
 Platform (server or mainframe)
 Software controls
Verify the accuracy of this list with IT management.
5.1.3.8 Confirm the existence of an employee and vendor contact list for
each systems software version/release identified in the previous
step. This contact list should include:
 Primary contact name
 Work location (address and room number)
 Office phone number
© 2009 ISACA. All rights reserved. Page 24
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program






Home phone number
Pager number
Alternate contact name
Work location (address and room number)
Office phone number
Home phone number
Verify this information with IT management.
5.1.3.9 Obtain an organization chart of the systems programming
department, and verify that the employees listed in the employee
and vendor contact list are on the chart and the information on the
list is accurate.
5.1.4 Data recovery
Control: Data recovery procedures have been established and tested to
ensure availability of data.
DS4.2
DS4.8
5.1.4.1 Determine if adequate generations of key data and operating
systems are maintained at the offsite location.
5.1.4.2 Determine if data and operating system restore procedures are
routinely tested.
5.1.4.3 Determine if the backup process includes the workstations that are
the user interface to the applications.
5.1.4.4 Determine if the restoration media can physically restore the data
within the prescribed time frame (consider interdependencies of
interfacing software).
5.1.4.5 Determine if alternate plans exist in the event that air service is
suspended or unavailable.
5.1.4.6 Determine if data backup is available and can be transported to the
interim processing site within the time frame established in the
BCP.
© 2009 ISACA. All rights reserved. Page 25
X
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
5.1.4.7 Determine if procedures to address the recovery of data lost
between the last backup and the time of disaster have been
developed and documented.
5.1.5 Facilities recovery
Control: Appropriate facilities have been identified and plans are in place to
support the interim processing and restoration of computer operations
according to the priorities established in the BCP.
DS4.2
DS4.3
DS4.8
DS4.9
X
PO7.2
PO7.3
DS4.2
DS4.3
DS4.8
X
5.1.5.1 Ensure that the amount of square footage needed for operations
has been analyzed and documented.
5.1.5.2 Determine if all of the possible in-house and outside solutions for
recovery space have been considered in the development of the
plan.
5.1.5.3 Verify that the plan addresses redundant electrical power
requirements for recovery (uninterruptible power sources [UPSs],
backup generators).
5.1.6 Staff recovery
Control: Staff responsibilities, notification, substitution, and access
procedures are in place to permit the timely assembly of staff and the
commencement of interim and/or restoration procedures.
5.1.6.1 Verify that the plan clearly documents the organizational structure
of the recovery teams and effectively communicates the
responsibilities of the team members (response and recovery).
5.1.6.2 Determine if the plan has a procedure for contacting and
accounting for all staff members after a disaster.
5.1.6.3 Determine if the plan contains procedures for recruiting temporary
staff from other locations or organizations if primary staff
members are not available.
© 2009 ISACA. All rights reserved. Page 26
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
5.1.6.4 Verify that the plan has provisions for offsite personnel to gain
access to critical passwords, deal with vendors and release
backup media in the event that onsite personnel are unavailable.
5.1.6.5 Determine if temporary housing and transportation have been
included in the staff recovery plan.
5.1.7 Plan details
Control: The recovery plan contains adequate details to permit
noncorporate IT professionals to implement the recovery plan if staff
members are not available. The plan also provides for damage assessment,
thresholds and formal decision points for plan activation.
DS4.1
DS4.2
DS4.3
DS4.7
5.1.7.1 Determine if recovery procedures are sufficiently detailed so that
noncorporate personnel can carry out recovery tasks. Procedures
should include details of the following:
 IT environment overview (interfaces and functionality)
 Recovery overview
 Recovery prerequisites (minimum hardware requirements,
systems, manuals, firewall configurations, passwords)
 Damage assessment
 Recovery steps (physical, network, operating system,
application, database)
 Postrecovery verification processes
 Procedures for maintaining service in recovery mode
 Procedures for transition to a primary recovery site
 Procedures for restoration to a permanent site
 Means for notifying relevant personnel of telecommunications,
power and platform outages
 Arrangements for the immediate deployment of technical
personnel in the event that primary personnel are not available
5.1.7.2 Determine if there are damage assessment steps with formal
decision points and thresholds to activate the plan, and ascertain
that the response is commensurate with the impact of the incident.
© 2009 ISACA. All rights reserved. Page 27
X
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
Control Activities
Information and
Communication
Monitoring
DS4.2
X
X
X
DS4.7
X
COBIT
Audit/Assurance Program Step
Crossreference
5.1.8 Third-party vendors
Control: Third-party vendors who execute business processes are included
in the ITCP or a separate vendor-specific ITCP, and both approaches
subscribe to the same policies, standards, guidelines and procedures as
internally executed processes.
Control
Environment
Risk Assessment
COSO
5.1.8.1 Determine if vendor contracts include IT continuity/business
recovery requirements.
5.1.8.2 Determine if vendor processors are included in the enterprise’s
ITCP or in a vendor-specific ITCP document or agreement.
5.1.8.3 Determine if the third-party recovery plan subscribes to the same
policies, standards and guidelines for risk assessment, hardware
and software recovery, staffing recovery, data recovery, and
facilities recovery.
5.1.8.4 Determine if third-party agreements include service level
agreements (SLAs) for interim and restoration of services.
5.1.8.5 Determine if the vendor-specific ITCP is regularly tested.
5.1.8.6 Based on the test results, evaluate the effectiveness of the vendor
ITCP.
5.1.9 Plan distribution
Control: The plan is distributed on a need-to-know basis, is securely stored
in soft and hard copy, and can be obtained from multiple locations in the
event that the primary storage location has been affected by the incident.
5.1.9.1 Determine who is on the distribution list and if the distribution list
is appropriate and accurate.
5.1.9.2 Determine where the plan is stored and if it is accessible under
various damage scenarios.
5.1.9.3 Determine if the backup sites are an appropriate balance between
availability and redundancy.
© 2009 ISACA. All rights reserved. Page 28
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
5.2 ITCP maintenance
Audit/assurance objective: The ITCP should be maintained to reflect systems and
applications changes as well as modifications to the BCP, which impacts the ITCP.
5.2.1 Plan maintenance
Control: The plan is maintained through inclusion in the systems
development methodology, routine review of plan components and linkage to
BCP reviews and enhancements.
DS4.1
DS4.2
DS4.3
DS4.4
X
DS4.1
DS4.2
DS4.3
DS4.4
X
DS4.5
X
5.2.1.1 Determine who is responsible for maintaining the plan, and review
the maintenance and revision procedures.
5.2.2 Plan review
Control: The ITCP is reviewed as part of all applications and systems
enhancements.
5.2.2.1 Determine if the plan is routinely reviewed and approved by an
appropriate level of senior management.
5.2.2.2 Identify what triggers the maintenance of the plan, and determine
if these instances are adequate to keep the plan up to date.
5.3 Plan testing
Audit/assurance objective: The plan should be tested regularly and the tests should
include a comprehensive verification of continuity processes and situational drills to
test the assumptions and alternate procedures within the plan.
5.3.1 Plan stress testing
Control: The ITCP tests utilize situational drills where resources are not
available for the test, or the circumstances of the test are modified
unannounced to verify the recovery team’s ability to adapt to unplanned
situations.
5.3.1.1 Verify that the tests include unannounced situations to stress test
the recovery plan's assumptions and the staff’s ability to react to
unplanned events.
© 2009 ISACA. All rights reserved. Page 29
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
5.3.2 Analysis of test results
Control: The results from the plan tests are analyzed to identify issues that
require BCP revision, additional training or additional resources.
DS4.5
X
DS4.5
X
DS4.5
X
5.3.2.1 Verify that changes to recovery plans have been made as a result
of testing and lessons learned.
5.3.2.2 Determine if the results have been communicated to management.
5.3.3 Testing of recovery service levels
Control: Plan testing includes verification that the tests were completed
within the intervals established in the BCP.
5.3.3.1 Determine if test results are compared against test criteria (RTOs,
RPOs, etc.).
5.3.4 Test frequency
Control: The ITCP is tested routinely, according to the policy, and the tests
address the requirements within the BCP.
5.3.4.1 Verify that the recovery plans are tested periodically.
5.3.4.2 Review the test criteria to determine if they will appropriately test
the plan against the requirements identified in the BIA.
© 2009 ISACA. All rights reserved. Page 30
Monitoring
Information and
Communication
Crossreference
Control Activities
COBIT
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Hyperlink
Issue
Crossreference
Comments
IT Continuity Planning Audit/Assurance Program
VII. Maturity Assessment
The maturity assessment is an opportunity for the reviewer to assess the maturity of the processes reviewed. Based on the results of audit/assurance review,
and the reviewer’s observations, assign a maturity level to each of the following COBIT control practices.
Assessed
Target
Maturity Maturity
COBIT Control Practice
DS4.1 IT Continuity Framework
1. Assign responsibility for and establish an enterprisewide business continuity management
process. This process should include an IT continuity framework to ensure that a business
impact analysis (BIA) is completed and IT continuity plans support business strategy, a
prioritized recovery strategy, necessary operational support based on these strategies and any
compliance requirements.
2. Ensure that the continuity framework includes:
• The conditions and responsibilities for activating and/or escalating the plan
• Prioritized recovery strategy, including the necessary sequence of activities
• Minimum recovery requirements to maintain adequate business operations and service
levels with diminished resources
• Emergency procedures
• Fallback procedures
• Temporary operational procedures
• IT processing resumption procedures
• Maintenance and test schedule
• Awareness, education and training activities
• Responsibilities of individuals
• Regulatory requirements
• Critical assets and resources and up-to-date personnel contact information needed to
perform emergency, fallback and resumption procedures
• Alternative processing facilities as determined within the plan
• Alternative suppliers for critical resources
• Chain of communications plan
• Key resources identified
3. Ensure that the IT continuity framework addresses:
• Organizational structure for IT continuity management as a liaison to organizational
continuity management
• Roles, tasks and responsibilities defined by SLAs and/or contracts for internal and external
service providers
• Documentation standards and change management procedures for all IT continuity-related
© 2009 ISACA. All rights reserved. Page 31
Reference
Hyperlink
Comments
IT Continuity Planning Audit/Assurance Program
Assessed
Target
Maturity Maturity
COBIT Control Practice
procedures and tests
• Policies for conducting regular tests
• The frequency and conditions (triggers) for updating the IT continuity plans
• The results of the risk assessment process (PO9)
DS4.2 IT Continuity Plans
1. Create an IT continuity plan, including:
• The conditions and responsibilities for activating and/or escalating the plan
• Prioritized recovery strategy, including the necessary sequence of activities
• Minimum recovery requirements to maintain adequate business operations and service
levels with diminished resources
• Emergency procedures
• Fallback procedures
• Temporary operational procedures
• IT processing resumption procedures
• Maintenance and test schedule
• Awareness, education and training activities
• Responsibilities of individuals
• Regulatory requirements
• Critical assets and resources and up-to-date personnel contact information needed to
perform emergency, fallback and resumption procedures
• Alternative processing facilities as determined within the plan
• Alternative suppliers for critical resources
2. Define underlying assumptions (e.g., level of outage covered by the plan) in the IT continuity
plan and which systems (i.e., computer systems, network components and other IT
infrastructure) and sites are to be included. Note alternative processing options for each site.
3. Ensure that the IT continuity plan includes a defined checklist of recovery events as well as a
form for event logging.
4. Establish and maintain detailed information for every recovery site, including assigned staff
and logistics (e.g., transport of media to the recovery site). This information should include:
• Processing requirements for each site
• Location
• Resources (e.g., systems, staff, support) available at each location
• Utility companies on which the site depends
5. Define response and recovery team structures, including reporting requirements roles and
responsibilities as well as knowledge, skills and experience requirements for all team
members. Include contact details of all team members, and ensure that that they are
maintained and readily available (e.g., offsite team, backup managing team).
© 2009 ISACA. All rights reserved. Page 32
Reference
Hyperlink
Comments
IT Continuity Planning Audit/Assurance Program
Assessed
Target
Maturity Maturity
COBIT Control Practice
6. Define and prioritize communication processes and define responsibility for communication
(e.g., public, press, government). Maintain contact details of relevant stakeholders (e.g., crisis
management team, IT recovery staff, business stakeholders, staff), service providers (e.g.,
vendors, telecommunications provider) and external parties (e.g., business partners, media,
government bodies, public).
7. Maintain procedures to protect and restore the affected part of the organization, including,
where necessary, reconstruction of the affected site or its replacement. This also includes
procedures to respond to further disasters while in the backup site.
8. Create emergency procedures to ensure the safety of all affected parties, including coverage
of occupational health and safety requirements (e.g., counseling services) and coordination
with public authorities.
DS4.3 Critical IT Resources
1. Define priorities for all applications, systems and sites that are in line with business
objectives. Include these priorities in the continuity plan. When defining priorities, consider:
• Business risk and IT operational risk
• Interdependencies
• The data classification framework
• SLAs and operating level agreements (OLAs)
• Costs
2. Consider resilience, response and recovery requirements for different tiers, e.g., one to four
hours, four to 24 hours, more than 24 hours and critical business operational periods.
DS4.4 Maintenance of the IT Continuity Plan
1. Maintain a change history of the IT continuity plan. Ensure proper version management of
the plan, e.g., through the use of document management systems. Ensure that all distributed
copies are the same version.
2. Involve the business continuity and IT continuity manager(s) in the change management
processes to ensure awareness of important changes that would require updates to the IT
continuity plans.
3. Update the IT continuity plan as described by the IT continuity framework. Triggering events
for the update of the plan include:
• Important architecture changes
• Important business changes
• Key staff changes or organization changes
• Incidents/disasters and the lessons learned
• Results from continuity plan tests
© 2009 ISACA. All rights reserved. Page 33
Reference
Hyperlink
Comments
IT Continuity Planning Audit/Assurance Program
Assessed
Target
Maturity Maturity
COBIT Control Practice
DS4.5 Testing of the IT Continuity Plan
1. Schedule IT continuity tests on a regular basis or after major changes in the IT infrastructure
or to the business and related applications. Ensure that all new components (e.g., hardware,
software updates, new business processes) are included in the schedule.
2. Create a detailed test schedule based on established recovery priorities. Ensure that test
scenarios are realistic. Tests should include recovery of critical business application
processing and should not be limited to recovery of infrastructure. Make sure that testing time
is adequate and will not impact the ongoing business.
3. Establish an independent test task force that keeps track of all events and records all results to
be discussed in the debriefing. The members of the task force should not be key personnel
defined in the plan. This task force should independently report to senior management and/or
the board of directors.
4. Perform a debriefing event wherein all failures are analyzed and solutions are developed or
handed over to task forces. Ensure that all outstanding issues related to continuity planning
are analyzed and resolved in an appropriate time frame. Schedule a retesting of the changes
using similar or stronger parameters to ensure a positive impact on the recovery procedures.
5. If testing is not feasible, evaluate alternative means for ensuring resources for business
continuity (e.g., dry run).
6. Measure and report the success or failure of the test and, therefore, the continuity and
contingency ability for services to the risk management process (PO9).
DS4.6 IT Continuity Plan Training
1. On a regular basis (at least annually) or upon plan changes, provide training to the required
staff members with respect to their roles and responsibilities.
2. Assess all needs for training periodically and update all schedules appropriately. While
planning the training, take into account the timing and the extent of plan updates and changes,
turnover of recovery staff, and recent test results.
3. Perform regular IT continuity awareness programs for all level of employees as well as IT
stakeholders to increase awareness of the need for an IT continuity strategy and their key role
within it.
4. Measure and document training attendance, training results and coverage.
© 2009 ISACA. All rights reserved. Page 34
Reference
Hyperlink
Comments
IT Continuity Planning Audit/Assurance Program
Assessed
Target
Maturity Maturity
COBIT Control Practice
DS4.7 Distribution of the IT Continuity Plan
1. Define a proper distribution list for the IT continuity plan and keep this list up to date.
Include people and locations in the list on a need-to-know basis. Ensure that procedures exist
with instructions for storage of confidential information.
2. Define a distribution process that:
• Distributes the IT continuity plan in a timely manner to all recipients and locations on the
distribution list
• Collects and destroys obsolete copies of the plan in line with the organization’s policy for
discarding confidential information
3. Ensure that all digital and physical copies of the plan are protected in an appropriate manner
(e.g., encryption, password protection) and the document is accessible only by authorized
personnel (recovery staff).
DS4.8 IT Services Recovery and Resumption
1. Activate the IT continuity plan when conditions require it.
2. Maintain an activity and problem log during recovery activities to be used during postresumption review.
DS4.9 Offsite Backup Storage
1. Provide protection for data commensurate with the value and security classification, from the
time they are taken offsite, while in transport to/from the organization and at the storage
location.
2. Ensure that the backup facilities are not subject to the same risks (e.g., geography, weather,
key service provider) as the primary site.
3. Perform regular testing of:
• The quality of the backups and media
• The ability to meet the committed recovery time frame
4. Ensure that the backups contain all data, programs and associated resources needed for
recovery according to plan.
5. Provide sufficient recovery instructions and adequate labeling of backup media.
6. Maintain an inventory of all backups and backup media. Ensure inclusion of all departmental
processing, if applicable.
DS4.10 Post-resumption Review
1. Using the problem and activity log of recovery activities, identify the shortcomings of the
plan after re-establishing normal processing, and agree on opportunities for improvement to
include in the next update of the IT continuity plan.
© 2009 ISACA. All rights reserved. Page 35
Reference
Hyperlink
Comments
IT Continuity Planning Audit/Assurance Program
VIII. Assessment Maturity vs. Target Maturity
DS4.1 IT Continuity Framework
5
DS4.10 Post-resumption Review
4
DS4.2 IT Continuity Plans
3
2
DS4.9 Offsite Backup Storage
DS4.3 Critical IT Resources
1
0
DS4.8 IT Serv. Recover/Resume
DS4.4 Maintenance-IT Cont. Pan
DS4.7 Distribution of the IT Continuity Plan
DS4.5 Testing of the IT Continuity Plan
Assessment
DS4.6 IT Continuity Plan Training
© 2009 ISACA. All rights reserved. Page 36
Target