The document discusses the 7 steps of business continuity management and contingency planning: 1) develop a policy statement, 2) conduct a business impact analysis, 3) identify preventive controls, 4) develop recovery strategies, 5) define recovery roles and responsibilities, 6) plan testing and training exercises, and 7) plan maintenance. It provides details on each step, emphasizing the importance of identifying critical resources, outage impacts, and recovery priorities in the business impact analysis in order to effectively develop recovery strategies, roles, and test procedures. Regular reviews and updates of the contingency plan are also highlighted.

1. SAHANA
CONFERENCE 2009
BUSINESS CONTINUITY
MANAGEMENT
SAHANA CONFERENCE
MARCH 24-25, 2009
COLOMBO, SRI LANKA
Brent H. Woodworth 1

2. Brent H. Woodworth 2

3. Business Continuity Management:
Steps to Preparedness
1. GAP analysis
2. COOP (Continuity of Operations Planning)
3. BIA (Business Impact Analysis)
4. Emergency Response Plan
5. Education
6. Testing
7. Update
3

4. Brent H. Woodworth 4

5. Contingency Planning Process
The seven steps of contingency planning
Develop the contingency planning policy statement
1.
Conduct the business impact analysis (BIA)
2.
Identify preventive controls
3.
Develop recovery strategies
4.
Define recovery roles and responsibilities
5.
Plan testing, training, & exercises
6.
Plan maintenance
7.
Develop
Conduct Identify Develop Develop Plan Testing,
Contingency Plan
Business Impact Preventive Recovery Contingency Training, and
Planning Maintenance
Analysis Controls Strategies Plan* Exercises
Policy
• Identify statutory or • Identify critical IT • Identify methods • Document recovery • Develop test objectives • Review and update plan
• Implement controls
regulatory resources • Integrate into system strategy • Develop success criteria • Coordinate with
• Maintain controls
requirements for • Identify outage impacts architecture • Document lessons internal/external
contingency plans and allowable outage learned organizations
• Develop IT times • Incorporate into the plan • Control distribution
contingency planning • Develop recovery • Train personnel • Document changes
policy statement priorities
• Obtain approval of
policy
• Publish policy
*Discussed in Section 4
5

6. Brent H. Woodworth 6

7. Step 1: Develop the Contingency
Planning Policy Statement
Policy must be supported by senior management
Key policy elements include :
Roles and responsibilities
Scope
Resource requirements
Training requirements
Exercise and testing schedules
Plan maintenance schedule
Backup frequency and storage method (applies to IT)
7

8. Brent H. Woodworth 8

9. Step 2: Conduct a Business Impact
Analysis
The business impact analysis (BIA) characterizes system contingency
requirements and priorities in the event of a disruption
Step 1: Identify critical IT resources
Step 2: Identify disruption impacts and allowable outage times
Step 3: Develop recovery priorities
Develop Recovery
Identify Disruption Impacts and
Identify Critical IT Resources
Priorities
Allowable Outage Times
Input from users,
PROCESS: 2. Time and Attendance Reporting Resource Recovery
business process Critical Business Process Critical Resources Priority
Max Allowable
owners, application
Critical Resource Impact
Outage
owners, and other
1. Payroll Processing
associated groups • LAN Server High
• LAN Server • LAN Server 8 hours • Delay in time
2. Time and Attendance
Medium
• WAN Access
• WAN Access sheet processing
Reporting • WAN Access
Low
• E-mail
• Inability to
• E-mail
3. Time and Attendance • Mainframe
perform routine
Verification High
Access • Mainframe
• Mainframe Access
payroll Access
4. Time and Attendance • E-mail Server operations
• E-mail Server
Approval High
. • E-mail Server
.
. . .
• Delay in payroll
.
. . .
. . . .
. processing .
.
X .
.
Results are key to development of recovery strategy and should also be
used for COOP, BCP, and BRP development
9

10. Step 3: Identify Preventive Controls
Preventive controls should be selected and implemented to mitigate
some of the impacts identified
Controls include, but are not limited to –
Uninterruptible Power Supplies (UPS) and power generators
Fire suppression systems and detectors
Offsite storage and system documentation
Technical security controls
10

11. Brent H. Woodworth 11

12. Step 4: Develop Recovery Strategies
Recovery strategies are a means to restore IT operations quickly and
effectively following a disruption
The strategies should:
Address residual risks and impacts identified by the BIA
Use a combination of methods to cover full spectrum of identified
risks
Integrate with the design and implementation phases of the system
development life cycle
Strategy should consider:
Backup methods
Alternate sites, Cost considerations
Equipment replacement
Roles and responsibilities
12

13. Brent H. Woodworth 13

14. Step 5: Recovery Roles & Responsibilities
Specific teams should be staffed based on their skills,
knowledge, and normal operating responsibilities
Team members should be trained to be ready to deploy and
implement the plan when necessary
Inter-team training will facilitate coordination and ease
staff shortages during a response
Role-based teams should be developed; do not use actual
names and titles
14

15. Step 5 (continued):
Recovery Roles & Responsibjilities
Senior management (e.g., CIO, CFO, CEO) should have
authority over plan activation and execution; may be
supported by a management team
Line of succession should define delegation of authority
All teams are lead by a team leader; team leaders should
have alternatives designated
15

16. Brent H. Woodworth 16

17. Step 6: Plan Testing, Training, &
Exercises
Objectives, success criteria, schedule, scope, scenario, and
logistics should be defined in the test plan
Recovery staff should be trained on team procedures and
responsibilities
Plan deficiencies and ability to implement the plan should
be evaluated through testing
2 basic types of tests
Classroom (tabletop)
Functional (simulation)
17

18. Step 7: Plan Maintenance
Plan effectiveness relies on up-to-date system, organization,
and procedural information
Reviews, followed by updates, should be conducted:
At least annually for technical, operational, and system requirements
At least annually for alternative site/offsite requirements and vital records
information
All changes made to the plan should be communicated to the
owners of associated plans and procedures
All changes should be recorded in the Record of Changes
(included in the plan)
18

19. Brent H. Woodworth 19