IT Continuity Planning Audit/Assurance Program (Jan · PDF fileIT Continuity Planning Audit/Assurance Program ISACA® With more than 86,000 constituents in more than 160 countries,

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.

DisclaimerISACA 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.

ISACA3701 Algonquin Road, Suite 1010Rolling Meadows, IL 60008 USAPhone: +1.847.253.1545Fax: +1.847.253.1443E-mail: [email protected] site: www.isaca.org

© 2009 ISACA. All rights reserved. Page 2

http://www.isaca.org/


ISBN 978-1-60420-079-9IT Continuity Planning Audit/Assurance ProgramPrinted in the United States of America

ISACA wishes to recognize: AuthorNorm Kelson, CISA, CGEIT, CPA, The Kelson Group, USA

Expert ReviewersJosé Manuel Ballester Fernández, Ph.D., CISA, CISM, CGEIT, IEEE, IT Deusto, SpainDinesh O. Bareja, CISA, IndiaRobert B. Brenis, CISA, CGEIT, MCP, PMP, Skoda Minotti, USARafael Eduardo Fabius, CISA, Republica AFAP SA, UruguayAnuj Goel, Ph.D., CISA, CISSP, Citigroup Inc., USASamuel Chiedozie Isichei, CISA, CISM, CISSP, Protiviti, USAKathy A. Rogers, CISA, USA

ISACA Board of DirectorsLynn Lawton, CISA, FBCS, FCA, FIIA, KPMG LLP, UK, International PresidentGeorge Ataya, CISA, CISM, CGEIT, CISSP, ICT Control SA, Belgium, Vice PresidentHoward Nicholson, CISA, CGEIT, City of Salisbury, Australia, Vice PresidentJose Angel Pena Ibarra, CGEIT, Consultoria en Comunicaciones e Info. SA & CV, Mexico, Vice PresidentRobert E. Stroud, CA Inc., USA, Vice PresidentKenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Vice PresidentFrank Yam, CISA, CIA, CCP, CFE, CFSA, FFA, FHKCS, FHKIoD, Focus Strategic Group Inc., Hong

Kong, Vice PresidentMarios Damianides, CISA, CISM, CA, CPA, Ernst & Young, USA, Past International PresidentEverett C. Johnson Jr., CPA, Deloitte & Touche LLP (retired), USA, Past International President Gregory T. Grocholski, CISA, The Dow Chemical Company, USA, DirectorTony Hayes, Queensland Government, Australia, DirectorJo Stewart-Rattray, CISA, CISM, CSEPS, RSM Bird Cameron, Australia, Director

Assurance CommitteeGregory T. Grocholski, CISA, The Dow Chemical Company, USA, ChairPippa G. Andrews, CISA, ACA, CIA, Amcor, AustraliaRichard Brisebois, CISA, CGA, Office of the Auditor General of Canada, CanadaSergio Fleginsky, CISA, ICI, UruguayRobert Johnson, CISA, CISM, CISSP, Executive Consultant, USAAnthony P. Noble, CISA, CCP, Viacom Inc., USARobert G. Parker, CISA, CA, CMC, FCA, Deloittte & Touche LLP (retired), CanadaErik Pols, CISA, CISM, Shell International - ITCI, NetherlandsVatsaraman Venkatakrishnan, CISA, CISM, CGEIT, ACA, Emirates Airlines, UAE



Table of Contents

I. Introduction.......................................................................................................................................4II. Using This Document........................................................................................................................5III. Controls Maturity Analysis................................................................................................................8IV. Assurance and Control Framework....................................................................................................9V. Executive Summary of Audit/Assurance Focus...............................................................................11VI. Audit/Assurance Program................................................................................................................13

1. Planning and Scoping the Audit...................................................................................................132. Continuity Framework and Policy...............................................................................................173. Business Assessment of Contingency Planning Requirements....................................................184. Integration of Business Continuity and IT Continuity Plans........................................................205. IT Continuity Plan.......................................................................................................................20

VII. Maturity Assessment........................................................................................................................31VIII. Assessment Maturity vs. Target Maturity........................................................................................36

I. Introduction

OverviewISACA has developed the IT Assurance Framework (ITAFTM) as a comprehensive and good-practice-setting 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, toolsand templates to provide direction in the application of IT audit and assurance processes.

PurposeThe 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 FrameworkThe 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—ITManagement 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 ofSponsoring 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.



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 ProfessionalsIT 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 startingpoint. It may be modified by the IT audit and assurance professional; it is not intended to be a checklist orquestionnaire. 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 thework 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 StepsThe 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 toa 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 identifiedelsewhere in the enterprise’s standards.



COBIT Cross-referenceThe 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 ComponentsAs 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 professionalsuse 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 ofdirectors.

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. Theprimary 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 FrameworksInternal 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.

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, distinguishingbetween risks and opportunities. Opportunities are channeled back to management’s strategy or objective-setting processes.

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.

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.



Figure 1—Comparison of COSO Internal Control and ERM Integrated FrameworksInternal 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.

Control Activities: Policies and procedures are established and implemented to help ensure the risk responses are effectively carried out.

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 withexternal parties, such as customers, suppliers, regulators and shareholders.

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: 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.

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/HyperlinkGood 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-referenceThis 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).

CommentsThe 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.


http://www.coso.org/aboutus.htm


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.

Figure 2—Maturity Model for Internal ControlMaturity Level Status of the Internal Control Environment Establishment of Internal Controls0 Non-existent 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 no intent to assess the need for internal control. Incidents are dealt with as they arise.

1 Initial/ad hoc 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.

There is no awareness of the need for assessment of what is needed in terms of IT controls. When performed, it is only onan ad hoc basis, at a high level and in reaction to significant incidents. Assessment addresses only the actual incident.

2 Repeatable but Intuitive

Controls are in place but are not documented. Their operationis 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.

Assessment of control needs occurs only when needed for selected IT processes to determine the current level of controlmaturity, 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 tomotivate an agreed-upon action plan.

3 Defined 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 isnot 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.

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.

4 Managed and Measurable

There is an effective internal control and risk management environment. A formal, documented evaluation of controls occurs frequently. Many controls are automated and regularlyreviewed. 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.

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.

5 Optimized 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.

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 confirmthat controls are at the right level of maturity to meet businessneeds 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.



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 mayvary 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 six-level 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 ofthe 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 pageof the document (section VIII), based on sample assessments.

IV. Assurance and Control Framework

ISACA IT Assurance Framework and StandardsThe 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 FrameworkCOBIT 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



continuity plan training. An effective continuous service process minimizes the probability and impactof 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 beto 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 clearlyand 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 alternativeprocessing, 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.

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 Objectivesfor 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 PlanningIT 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 RiskBusiness 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 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 ScopeObjective—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 SkillsThe 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.



VI. Audit/Assurance Program

Audit/Assurance Program StepCOBITCross-

reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

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 theseissues.

1.2.6 Identify limitations and/or constraints affecting the audit of specific systems.




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

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 willbe 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.




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

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.




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

1.9 CommunicationsThe 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




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

2. CONTINUITY FRAMEWORK AND POLICY

2.1 IT continuity frameworkAudit/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.

3. Organization and governanceControl: The business has established a business continuity task force/ committee/organization to establish and maintain a business continuity process.

DS4.1DS4.2

X X X

3.1.1.1 Determine if the enterprise has a BCP project plan or program, and indicate the date of acceptance and/or review.

3.1.1.2 Determine if a budget for BCP and its components are included in the enterprise’s budget.

3.1.1.3 Determine if the BCP team member roles and responsibilities havebeen assigned at an appropriate level of authority to carry out responsibilities, and the team has appropriate executive sponsors.




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

4. ParticipationControl: 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 X X X

4.1.1.1 Determine if the members of the BCP team are representatives from the affected organizations.

4.1.1.2 Determine if the leadership and sponsorship of the BCP is assigned to the business, and is not driven by IT.

4.1.1.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.

5. Mission statementControl: The mission statement and goals of the BCP team are in alignment with the enterprise’s policies addressing business continuity.

DS4.1 X X

5.1.1.1 Review the BCP policy and mission statements to ensure that they are in alignment.

6. Risk-focused BCPControl: The BCP utilizes risk analysis to determine the strategy and recoveryplans.

DS4.1 X X X

6.1.1.1 Determine if the framework requires reliance on risk assessments and BIA to determine critical resource requirements, alternative processing strategies and recovery.




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

7. BUSINESS ASSESSMENT OF CONTINGENCY PLANNING REQUIREMENTS

7.1 Business assessmentAudit/assurance objective: The business recovery needs and the drivers for the development of an ITCP plan should be identified.

8. Risk assessmentControl: Risk assessment and BIA methods are utilized to establish business interruption exposures, their probability and impact, and remediation alternatives.

PO4.8DS4.1DS4.2

X X X

8.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.

8.1.1.2 Determine if the BIA has identified all of the critical and necessary business functions and their resource dependencies.

8.1.1.3 Determine if a BIA to assess potential business losses from any event that interrupts a major business process has been conductedand documented. The BIA should document an enterprises’s business processes, their criticality and recovery time objectives, and the resources needed to recover them.

8.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.

8.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.

8.1.1.6 Review the risk assessment and determine if it documents the © 2009 ISACA. All rights reserved. Page 19



reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

mitigating steps that are in place to address these threats.

9. Recovery point objectivesControl: Recovery point objectives (RPOs) have been established to provide guidelines for the time required to restore or provide interim services.

DS4.2 X

9.1.1.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.

9.1.1.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.

10. INTEGRATION OF BUSINESS CONTINUITY AND IT CONTINUITY PLANS

10.1 BCP developmentAudit/assurance objective: An ITCP should be established to reflect the BCP.

11. Alignment of BCP and ITCP Control: The ITCP is aligned with and supports the business continuity plan.

DS4.1DS4.2

X X

11.1.1.1 Determine if the establishment of an ITCP is a subset of BCP andsupports the BCP.

11.1.1.2 Determine the enterprise’s BCP environmental components addressed (facility, power, staff, etc.) that allow the business to function.




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

12. IT CONTINUITY PLAN

12.1 ITCP developmentAudit /assurance objective: The ITCP should be complete and should address the business continuity requirements defined in the BCP.

13. CommunicationsControl: The communications components necessary to provide network access to the computing facilities are included in the ITCP.

DS4.2DS4.3DS4.8

X X X

13.1.1.1 Confirm the existence of a network diagram by obtaining the most recent copy, noting the date.

13.1.1.2 Confirm with the communications department the accuracy and completeness of the network diagram.

13.1.1.3 Confirm the existence of a network circuit inventory by obtaining a copy, noting the date.

13.1.1.4 Confirm that the circuit inventory contains information regarding: Voice and data lines Configuration 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




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

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

13.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

13.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 communications equipment.

If a contract exists for an offsite location, determine if it includes commitments for network support.

Review contracts with communications vendors and determinetheir commitment to restoring network switching capabilities.

If an onsite telephone system is installed, confirm the existenceof alternate outside phone lines for backup.




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

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.

13.1.1.7 Confirm that an inventory list exists for telecommunications equipment required by the critical applications by obtaining a copyfor the documentation.

13.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 inthe hardware requirements inventory of this audit program. If it is, then indicate so by referencing that section.

13.1.1.9 Review the communications recovery action steps contained in the business recovery plan. Note any discrepancies.

14. HardwareControl: The hardware configuration and procurement plans provide for the ability to acquire and configure hardware within the interim period established in the BCP.

DS4.2DS4.3DS4.8

X

14.1.1.1 Confirm that an inventory of current hardware exists by obtaining a copy, noting the date.

14.1.1.2 For each device, the inventory should include: Vendor Model number Serial number Location

Brief description of equipment (e.g., central processing unit,




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

modem, firewall, tape drive) Original purchase cost Monthly lease amount Purchase date

14.1.1.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.

14.1.1.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.

14.1.1.5 Determine what arrangements have been made to obtain hardware not previously subscribed to or leased ahead of time.

14.1.1.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.

15. Software critical systems and applicationsControl: 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.2DS4.2DS4.3DS4.4

X

15.1.1.1 Confirm that a list of all critical applications exists by obtaining acopy. 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

15.1.1.2 Compare the list of all critical applications to the recovery plan




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

to determine if a recovery strategy exists for each critical application.

15.1.1.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.

15.1.1.4 Confirm that a recovery job schedule exists that shows the recovery sequence of the critical applications. Obtain copies for the documentation.

15.1.1.5 Determine how often the critical applications list is reviewed andupdated. 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.

15.1.1.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.

15.1.1.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.

15.1.1.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:




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

Primary contact name Work location (address and room number) Office phone number 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.

15.1.1.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 thelist is accurate.

16. Data recoveryControl: Data recovery procedures have been established and tested to ensure availability of data.

DS4.2DS4.8

X

16.1.1.1 Determine if adequate generations of key data and operating systems are maintained at the offsite location.

16.1.1.2 Determine if data and operating system restore procedures are routinely tested.

16.1.1.3 Determine if the backup process includes the workstations that are the user interface to the applications.

16.1.1.4 Determine if the restoration media can physically restore the datawithin the prescribed time frame (consider interdependencies of interfacing software).




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

16.1.1.5 Determine if alternate plans exist in the event that air service is suspended or unavailable.

16.1.1.6 Determine if data backup is available and can be transported to the interim processing site within the time frame established in the BCP.

16.1.1.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.

17. Facilities recoveryControl: 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.2DS4.3DS4.8DS4.9

X

17.1.1.1 Ensure that the amount of square footage needed for operations has been analyzed and documented.

17.1.1.2 Determine if all of the possible in-house and outside solutions forrecovery space have been considered in the development of the plan.

17.1.1.3 Verify that the plan addresses redundant electrical power requirements for recovery (uninterruptible power sources [UPSs],backup generators).

18. Staff recoveryControl: 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.

PO7.2PO7.3DS4.2DS4.3DS4.8

X

18.1.1.1 Verify that the plan clearly documents the organizational structure of the recovery teams and effectively communicates the




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

responsibilities of the team members (response and recovery).

18.1.1.2 Determine if the plan has a procedure for contacting and accounting for all staff members after a disaster.

18.1.1.3 Determine if the plan contains procedures for recruiting temporary staff from other locations or organizations if primary staff members are not available.

18.1.1.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.

18.1.1.5 Determine if temporary housing and transportation have been included in the staff recovery plan.

19. Plan detailsControl: 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.


X

19.1.1.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) © 2009 ISACA. All rights reserved. Page 28



reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

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

19.1.1.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.

20. Third-party vendorsControl: 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.

DS4.2 X X X

20.1.1.1 Determine if vendor contracts include IT continuity/business recovery requirements.

20.1.1.2 Determine if vendor processors are included in the enterprise’s ITCP or in a vendor-specific ITCP document or agreement.

20.1.1.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.

20.1.1.4 Determine if third-party agreements include service level agreements (SLAs) for interim and restoration of services.

20.1.1.5 Determine if the vendor-specific ITCP is regularly tested.




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

20.1.1.6 Based on the test results, evaluate the effectiveness of the vendor ITCP.

21. Plan distributionControl: 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.

DS4.7 X

21.1.1.1 Determine who is on the distribution list and if the distribution list is appropriate and accurate.

21.1.1.2 Determine where the plan is stored and if it is accessible under various damage scenarios.

21.1.1.3 Determine if the backup sites are an appropriate balance betweenavailability and redundancy.

21.2 ITCP maintenanceAudit/assurance objective: The ITCP should be maintained to reflect systems and applications changes as well as modifications to the BCP, which impacts the ITCP.

22. Plan maintenanceControl: The plan is maintained through inclusion in the systems developmentmethodology, routine review of plan components and linkage to BCP reviews and enhancements.


X

22.1.1.1 Determine who is responsible for maintaining the plan, and review the maintenance and revision procedures.

23. Plan reviewControl: The ITCP is reviewed as part of all applications and systems enhancements.


X

23.1.1.1 Determine if the plan is routinely reviewed and approved by an appropriate level of senior management.




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

23.1.1.2 Identify what triggers the maintenance of the plan, and determineif these instances are adequate to keep the plan up to date.

23.2 Plan testingAudit/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.

24. Plan stress testingControl: 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.

DS4.5 X

24.1.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.

25. Analysis of test resultsControl: The results from the plan tests are analyzed to identify issues that require BCP revision, additional training or additional resources.

DS4.5 X

25.1.1.1 Verify that changes to recovery plans have been made as a result of testing and lessons learned.

25.1.1.2 Determine if the results have been communicated to management.

26. Testing of recovery service levels Control: Plan testing includes verification that the tests were completed within the intervals established in the BCP.

DS4.5 X

26.1.1.1 Determine if test results are compared against test criteria (RTOs,RPOs, etc.).




reference

COSO

ReferenceHyper-

link

IssueCross-

referenceComments

Co

ntr

ol E

nvi

ron

me

nt

Ris

k A

sse

ssm

ent

Con

tro

l Act

iviti

es

Info

rma

tion

an

dC

omm

un

ica

tion

Mon

itorin

g

27. Test frequencyControl: The ITCP is tested routinely, according to the policy, and the tests address the requirements within the BCP.

DS4.5 X

27.1.1.1 Verify that the recovery plans are tested periodically.

27.1.1.2 Review the test criteria to determine if they will appropriately test the plan against the requirements identified in the BIA.



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.

COBIT Control PracticeAssessedMaturity

TargetMaturity

ReferenceHyper-

linkComments

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

procedures and tests




TargetMaturity

ReferenceHyper-

linkComments

• 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 Plans1. 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 continuityplan 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).

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




TargetMaturity

ReferenceHyper-

linkComments

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 Resources1. 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 Plan1. 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 eventsfor 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




TargetMaturity

ReferenceHyper-

linkComments

DS4.5 Testing of the IT Continuity Plan1. 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 timeis 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 tobe 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 Training1. 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.




TargetMaturity

ReferenceHyper-

linkComments

DS4.7 Distribution of the IT Continuity Plan1. 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 information3. 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 Resumption1. Activate the IT continuity plan when conditions require it.2. Maintain an activity and problem log during recovery activities to be used during post-

resumption review.

DS4.9 Offsite Backup Storage1. 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 Review1. 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.



VIII. Assessment Maturity vs. Target Maturity


Documents

IT Continuity Planning Audit/Assurance Program (Jan · PDF fileIT Continuity Planning Audit/Assurance Program ISACA® With more than 86,000 constituents in more than 160 countries,