Example of Disaster Recovery Process

Section 1: Disaster Preparedness

A. Preparedness

Disasters—natural and man-made—and weather patterns all have the potential to damage or destroy records. Basic precautions and the formation of a disaster plan will help prevent the unnecessary loss of valuable records in the instance of a disaster. Following these guidelines will minimize potential risks and reduce the loss of records.

B. Disaster Prevention

Disaster Prevention refers to steps to protect your building and collections before a disaster occurs.

  • Establish security routines, including an annual building inspection and seasonal maintenance.
  • Inspect wiring regularly.
  • Inspect roofs and drains regularly.
  • Follow local and state fire codes. The presence of fire alarms, smoke detectors, fire extinguishers, and a sprinkler system are strongly recommended for personal safety and collection preservation. Map their locations.
  • Select a storage space least vulnerable to fire, flood, and harsh weather patterns.
  • Establish and practice fire evacuation and tornado response procedures. Map evacuation routes and designated tornado shelters.
  • Install water detectors and alarms. Map their locations.
  • Locate water pipes and water shut-off valves. Map their locations.
  • Install alarms to prevent intrusion, deliberate, or random violence.
  • Install emergency lighting.
  • Store records at least 6 inches off the ground.
  • Prohibit smoking in storage areas.
  • Limit small appliances in the collection storage area.
  • Limit unauthorized access to the storage area.
  • Limit the number of records a patron may view at one time.
  • Consider microfilming records that receive high use, and limit access to the originals that may be stored off-site.
  • Check your insurance coverage regularly.
  • Determine how you will have access to emergency funds: a supply of purchase orders to be used only during an emergency, or a disaster emergency fund.
  • Purchase emergency supplies to keep on hand, inventory them regularly, and map their locations.
  • Train staff in salvage techniques.
  • Label vital and historical records, and create an inventory or locator map that will allow you quick access to these records when needed. Regularly update your finding aids and keep copies off-site
  • Buildings and collections are particularly vulnerable during periods of construction, so increase security during these times.
  • Improving collection storage areas, when possible, will help prevent disasters and security problems.
  • Keep duplicates of your disaster plan, policies, lists, and record inventories off-site.

C. Disaster Plan

A Disaster Plan guides your organization through the proper responses to various types of disasters. This section highlights some of the elements of a disaster plan.

  • Create a written disaster preparedness plan or policy, which includes disaster recovery, damage assessment, and post disaster evaluation procedures.
  • Identify and prioritize the most important records. This includes records needed to resume business, historical records, and collections. Determine which record media and collections are more vulnerable or valuable than others.
  • Analyze your building, site, and collection storage areas. Include building and site maps in your disaster plan.
  • Establish responses to all potential geographic and climatic hazards, and other risks which could jeopardize your employees, building, and collections: tornadoes; floods; fires, which will include water damage from fire-hoses; pest infestation; mold; vandalism; and accidents.
  • Contact local civil defense offices to understand their disaster response procedures.
  • Identify sources of assistance, and develop contacts with appropriate consultants, suppliers, and vendors beforehand. Check your local Yellow Pages for contacts in your area, and make a list including names and telephone numbers. Update the list annually.
  • Establish contact with a freezer service; verify contact annually.
  • Special conservation efforts may be necessary with water or fire-damaged records, have phone numbers and addresses available of people or agencies to contact.
  • Include a copy of your collection inventory and vital records locator map in your disaster plan.
  • Include a supply list and locations in your disaster plan.
  • Create a telephone tree of staff and volunteers to help in the event of a disaster.
  • Establish a chain of command among staff members. All staff should know who they report to, and who they notify in case of disaster.
  • Know what your insurance carrier will require as evidence of damage: photographs, written documentation.
  • Establish salvage procedures for all collections, records, paper, and record media.
  • The following section outlines the roles and responsibilities for a two-pronged approach to disaster response: damage assessment and damage recovery. When establishing assessment and recovery teams for your disaster plan, it is important to detail specific responsibilities, outline clear lines of authority, and remember that a person may have more than one role.
  • Facilities Manager: responsible for seeing that the building is safe, damage to the building is evaluated, and measures formulated and implemented to remedy or correct problems. Upon notification of a problem establishes that no threat exists to personnel safety, secures the affected area and/or building, and alerts Assessment Director. Establishes priorities for facility repairs, and follows the progress of repairs once begun.
  • Assessment Manager: organizes and manages the process by which damage is evaluated. Responsible for notifying and instructing Assessment Team Leaders, and enlisting the assistance of in-house or outside experts/resource people as required. Evaluates findings and recommendations, and contacts the Recovery Director with recovery recommendations.
  • Assessment Team Leader: selects and assembles the teams members, and directs their operations. Instructs the team on what to do and how to do it, including methods of inspection and sampling, assessing damaged material, and documenting the process. Monitors the damage investigation, reporting recommendations to the Assessment Director.
  • Assessment Team: consists of people most knowledgeable about the collection or material involved. Responsibilities include recording observations and decisions made by the team; photographing damage; investigating where damage exists, the type of damage, and the importance and significance of the affected material; estimating the extent of damage to the collection; and establishing initial priorities for recovery of damaged items.
  • Recovery Manager: organizes and manages the recovery process. Sets priorities based on information received from the Assessment Director, assigns recovery teams, reports on progress, actions taken, problems encountered, and future risks. In many cases, the Assessment Director and Recovery Director may be the same person.
  • Recovery Team Leader: appoints team members, instructs the team on what they will be doing and how they will do it. Monitors the recovery process, and updates the Recovery Director.
  • Recovery Team: may include all staff members. Responsible for separating collections and other material to be salvaged, moving material to be recovered from affected areas to work or other storage spaces, drying materials, and packing materials that will require shipment to another facility. Other responsibilities include maintaining records and photographs of the recovery effort, including inventories and dates when items are sent out of the building to off-site storage or other facilities; what items have been frozen, treated or dried; where items have been relocated; and items in need of additional attention. The Recovery Team may also label items that have lost inventory numbers, label or re-label boxes with locator information, and label boxes ready for shipment.

D. Disaster Recovery

Disaster Recovery refers to the response and actions your organization takes after a disaster occurs.

  • Always place human safety first.
  • In the event of an emergency, prevent staff and volunteers from entering the building until city officials (fire or police department), or a building inspector determines the building is safe to enter.
  • Allow only authorized staff and volunteers into the damaged area, use check-in/out sheets to monitor access.
  • Contact your insurance carrier.
  • Stabilize temperature and relative humidity.
  • In the instance of a disaster, a recovery plan may include the following steps:
    1. locate and establish a recovery site.
    2. establish a designated storage area for removed material.
    3. retrieve vital records.
    4. maintain building security.
    5. set up systems necessary to continue operations, such as workspace for employees, telephones, financial services, clerical support, office supplies, equipment, food, drink, and restrooms.
    6. plan for building repair, and the replacement of equipment and furnishings.
    7. determine what has been lost and what records and collections are salvageable.
  • The goal is to stabilize the collection until further conservation measures can be taken. This includes, when possible, removing collections from the damaged area, prioritizing the recovery effort, and beginning initial stabilization measures.
  • Prioritize which records to conserve first, taking into consideration media type, duplication, and value to the organization.
  • Conservation of record media may require special processes; please contact preservation personnel before acting.
  • Quick reaction is a must. Mold can grow on records within 48 hours of damage. Immediately air dry or freeze wet records to prevent further damage and growth.
  • Minimize damage to collection materials and records on the floor by re-routing traffic, or by creating a bridge over the items with boards and chairs.
  • Assess the disaster response. Ask such questions as:
    1. Could I limit or avoid the damage if a similar disaster struck again?
    2. Do I need better insurance coverage?
    3. Do I need to revise my records management program to minimize future losses?
    4. Do I have the information and supplies I need to deal with future emergencies?
    5. What aspects of the Disaster Plan need to be modified?
    6. What additional training do I or my staff need?

Section 2: Disaster Recovery Process

A. Abbreviations / ACRONYMS / GLOSSARY

Acronym

Explanation

Acronym

Explanation

DRP

Disaster Recovery Plan

ERT

Emergency Response Team

Infosec

Information Security

BCP

Business Continuity Planning

UOM

Unit of Measure

NA

Not Applicable

B. Roles & Responsibilities

Role

Responsibilities

Head – BCP

Assess disaster situation and execute necessary action

Head-InfoSec

Coordinate with other stakeholders

ERT

Ensure safety of people

C.  Entry Criteria

Any Disaster

D. Inputs

#

Description / Work Product Name

#

Description / Work Product Name

1.      

Information about any disaster

2.      

 

E.      Activities performed

1 Assess Disaster Situation

Activities

Resp.

Related Documents / Processes / Notes

Assess Disaster Situation

Head – BCP

Disaster Assessment Guidelines

Evaluate whether to invoke Disaster Recovery Process

Head – BCP

 

Invoke Disaster Recovery Process, if needed

Head – BCP

 

Communicate invocation of Disaster Recovery Process to Emergency Response Team

Head – BCP

 

2 Ensure Employee Safety

Activities

Resp.

Related Documents / Processes / Notes

Evacuate Buildings

ERT

 

Ensure Employee Safety

ERT

 

Provide First-Aid

ERT

First Aid Guidelines

Inform nearby hospital

ERT

 

Inform Ambulance Service

ERT

Emergency Contact List

Send injured personnel to Hospital

ERT

Emergency Contact List

Inform nearby Police Station

ERT

 

Inform nearby Fire station

ERT

 

3 Communicate to Stakeholders

Activities

Resp.

Related Documents / Processes / Notes

Inform employee relatives about Disaster

ERT

Employee Details

Inform Clients about Disaster

ERT

Client Details

Set-up Help Desk

ERT

 

4 Switch to alternative modes of operations

Activities

Resp.

Related Documents / Processes / Notes

Make essential services operational in the alternative premises/modes of operations

Head – BCP

Business Continuity Plan

Communicate to employees to switch to alternative premises / modes of operations

Head – BCP

Services List

Employee Details

5 Recover essential Facilities services

Activities

Resp.

Related Documents / Processes / Notes

Recover essential Facilities

Facilities

 

Recover essential Facilities services

Facilities

Services List

6  Recover essential IT services

Activities

Resp.

Related Documents / Processes / Notes

Inform Vendors for Support, if required

IT

Services List

Restore Essential Servers

IT

Services List

Restore Essential Networks

IT

Services List

7 Recover facilities services

Activities

Resp.

Related Documents / Processes / Notes

Recover  Facilities

Facilities

Services List

Recover  Facilities services

Facilities

Services List

8  Recover IT services

Activities

Resp.

Related Documents / Processes / Notes

Inform Vendors for Support, if required

IT

Services List

Restore  Servers

IT

Services List

Restore  Networks

IT

Services List

9   Return to normal operations

Activities

Resp.

Related Documents / Processes / Notes

Asses if the operations have returned to normalcy

Head – BCP

 

Inform employees about Normal Operations

ERT

Employee Details

Inform Clients about Normal Operations

ERT

Client Details

10  Analyze Disaster Recovery Effectiveness

Activities

Resp.

Related Documents / Processes / Notes

Analyze Disaster Recovery Effectiveness

Head – BCP

 

Identify improvements in Disaster Recovery Process

ERT

Process Change Tracker Template

F. Outputs

#

Description / Work Product Name

#

Description / Work Product Name

1.

Facilities Recovered

2.

Systems Recovered

3.

Process Change Tracker

4.

Executed DRP

G.      Measurement and Analysis

#

Metric

Definition/ Formulae

Data to be captured

Source

Owner

Frequency

1.      

Recovery time

Time taken to recover

Time of Disaster and Recovery

Head – Infosec

Head – Infosec

 

NA

H.      Related PROCESSES / ARTIFACTS

#

Description / Work Product Name

#

Description / Work Product Name

1.   

Emergency Contact List

2.

Client Details

3.

Employee Details

4.

Services List

5.

Approved Vendor Contact List

6.

Disaster Assessment Guidelines

7.

First Aid Guidelines

8.

Disaster Communication Guidelines

 

7.      standards compliance

Standard / Model

Clause No & Name

Control description

ISO 27001

A.14

Business Continuity Management

Section 3: Disaster Assessment Guidelines

A. Assessment Goals

  • To provide timely and comprehensive information on the scope and impacts of a disaster
  • To support effective emergency decision making
  • To keep the staff and other stake holders accurately informed
  • To develop and support requests for disaster resources and recovery assistance

B. The Basics

  • First and always, assessment must focus on immediate emergency needs for life, safety, protection of property and essential services.
  • Assessment resources and activity must be assigned to address human needs as well as property
  • Forms and structure are important to good assessment, but the keys to success are leadership, organization and management.

C. The Essentials

1 Leadership

  • Assign an assessment leader or coordinator
  • Activate leader early as the response begins
  • The leader’s only task is to manage the assessment
  • The leader supports, but cannot be the emergency manager

2 Organization

  • The leader needs help – a partner or team
  • People must be reassigned from routine work, regular jobs and other departments to support the assessment effort
  • Divide the tasks  – establish a human needs group and a public services group
  • Organization and work early in the response will ease the demands of recovery assessment later

I3. Immediate and Continuous

  • Activate assessment staff immediately as the response unfolds, or even when a threat is imminent
  • Early information is crucial and the reporting process is continuous
  • Capturing an early overview and quickly targeting life/safety issues is vital – details and dollars come later
  • Resist the urge to hold and wait for better, more complete information – parts of a report at intervals are often more helpful than waiting for a complete report
  • Reporting at regular, frequent intervals is good, but pass along important information immediately

 D. Assessment – Steps and Stages

  • Early impact assessment
  • Assessment of needs and resource priorities
  • Preparing for the preliminary damage assessment

E. Informed Estimates

  • Decision-making in a crisis cannot always wait for complete data and detailed reports – good estimating is the key.
  • Estimating is not guesswork – informed estimates means contacting knowledgeable officials about their evaluation and judgment of local conditions and impacts.
  • Informed estimates by knowledgeable local leaders – supervisors, highway/public works, engineers, fire officers, and the Red Cross – typically provide reliable assessments useful to emergency operations.
  • Informed estimates are a credible tool that helps meet the pace and urgent demands of providing emergency services.

F. Flexible and Adaptable

  • Assessment demands and priorities can differ from disaster to disaster.
  • Timing cannot be predicted – the process usually moves more quickly than expected.
  • Information needed is not always reflected in the forms  – special requests are common.
  • In some instances, data requested on a form may be crucial, at other times the same data may not be needed.
  • Requests for more detail are common, but sometimes a step may be skipped.

 G. The Local Government Coordination

The local government is generally responsible for consolidating and coordinating the collection of assessment data provided by government departments, municipalities, community organizations, other agencies and services.

Back to Trace International

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Business Continuity Plan

Section I: Introduction

A. How to Use This Plan

In the event of a disaster which interferes with <ORGANIZATION NAME>’s ability to conduct business from one of its offices, this plan is to be used by the responsible individuals to coordinate the business recovery of their respective areas and/or departments.  The plan is designed to contain, or provide reference to, all of the information that might be needed at the time of a business recovery.
This plan is not intended to cover the operations of <ORGANIZATION NAME>’s separately structured Emergency Response Team.
Index of Acronyms: (EOC) Emergency Operations Center – (EMT) Emergency Management Team – (ERT) Emergency Response Team – (BCP) Business Continuity Plan – (IT) Information Technology
Section I, Introduction, contains general statements about the organization of the plan.  It also establishes responsibilities for the testing (exercising), training, and maintenance activities that are necessary to guarantee the ongoing viability of the plan.
 Section II, Business Continuity Strategy, describes the strategy that the <Department Name> Department will control/implement to maintain business continuity in the event of a facility disruption.  These decisions determine the content of the action plans, and if they change at any time, the plans should be changed accordingly.
Section III, Recovery Teams, lists the Recovery Team functions, those individuals who are assigned specific responsibilities, and procedures on how each of the team members is to be notified.
Section IV, Team Procedures, determines what activities and tasks are to be taken, in what order, and by whom in order to affect the recovery.
Section V, Appendices, contains all of the other information needed to carry out the plan.  Other sections refer the reader to one or more Appendices to locate the information needed to carry out the Team Procedures steps.

B. Objectives

The objective of the Business Continuity Plan is to coordinate recovery of critical business functions in managing and supporting the business recovery in the event of a facilities (office building) disruption or disaster.  This can include short or long-term disasters or other disruptions, such as fires, floods, earthquakes, explosions, terrorism, tornadoes, extended power interruptions, hazardous chemical spills, and other natural or man-made disasters.
A disaster is defined as any event that renders a business facility inoperable or unusable so that it interferes with the organization’s ability to deliver essential business services.
The priorities in a disaster situation are to:

  1. Ensure the safety of employees and visitors in the office buildings. (Responsibility of the ERT)
  2. Mitigate threats or limit the damage that threats can cause. (Responsibility of the ERT)
  3. Have advanced preparations to ensure that critical business functions can continue.
  4. Have documented plans and procedures to ensure the quick, effective execution of recovery strategies for critical business functions.

The <Department Name> Business Continuity Plan includes procedures for all phases of recovery as defined in the Business Continuity Strategy section of this document.

C. Scope

  • The Business Continuity Plan is limited in scope to recovery and business continuance from a serious disruption in activities due to non-availability of <ORGANIZATION NAME>’s facilities.  The Business Continuity Plan includes procedures for all phases of recovery as defined in the Business Continuity Strategy of this document.  This plan is separate from <ORGANIZATION NAME>’s Disaster Recovery Plan, which focuses on the recovery of technology facilities and platforms, such as critical applications, databases, servers or other required technology infrastructure (see Assumption #1 below).  Unless otherwise modified, this plan does not address temporary interruptions of duration less than the time frames determined to be critical to business operations. The scope of this plan is focused on localized disasters such as fires, floods, and other localized natural or man-made disasters. This plan is not intended to cover major regional or national disasters such as regional earthquakes, war, or nuclear holocaust.  However, it can provide some guidance in the event of such a large scale disaster.

D. Assumptions

The viability of this Business Continuity Plan is based on the following assumptions:

  1. That a viable and tested IT Disaster Recovery Plan exists and will be put into operation to restore data center service at a backup site within five to seven days.
  2. That the Organization’s facilities management department has identified available space for relocation of departments which can be occupied and used normally within two to five days of a facilities emergency.
  3. That this plan has been properly maintained and updated as required.
  4. That each department has their own Business Continuity Plan.
  5. The functions and roles referenced in this plan do not have to previously exist within an organization; they can be assigned to one or more individuals as new responsibilities, or delegated to an external third party if funding for such services can be arranged and allocated.

E.    Changes to the Plan/Maintenance Responsibilities

Maintenance of the <Department Name> Business Continuity Plan is the joint responsibility of the <Department Name> management, the Facilities Management Department, and the Business Continuity Coordinator.
Department Name management is responsible for:

  1. Periodically reviewing the adequacy and appropriateness of its Business Continuity strategy.
  2. Assessing the impact on the <Department Name> Business Continuity Plan of additions or changes to existing business functions, <Department Name> procedures, equipment, and facilities requirements.
  3. Keeping recovery team personnel assignments current, taking into account promotions, transfers, and terminations.
  4. Communicating all plan changes to the Business Continuity Coordinator so that the organization’s IT master Disaster Recovery Plan can be updated.

Facilities Management Department management is responsible for:

  1. Maintaining and/or monitoring offsite office space sufficient for critical <Department Name> functions and to meet the <Department Name> facility recovery time frames.
  2. Communicating changes in the “Organization IT Disaster Recovery Plan” plan that would affect groups/departments to those groups/departments in a timely manner so they can make any necessary changes in their plan.
  3. Communicating all plan changes to the Business Continuity Coordinator so that the master plan can be updated.

The Business Continuity Coordinator is responsible for:

  1. Keeping the organization’s IT Recovery Plan updated with changes made to <Department Name> facilities plans.
  2. Coordinating changes among plans and communicating to <Department Name> management when other changes require them to update their plans.

F. Plan Testing Procedures and Responsibilities

<Department Name> management is responsible for ensuring the workability of their Business Continuity Plan.  This should be periodically verified by active or passive testing.

G. Plan Training Procedures and Responsibilities

<Department Name> management is responsible for ensuring that the personnel who would carry out the Business Continuity Plan are sufficiently aware of the plan’s details. This may be accomplished in a number of ways including. practice exercises, participation in tests, and awareness programs conducted by the Business Continuity Coordinator.

H. Plan Distribution List

The <Department Name> Business Continuity Plan will be distributed to the following departments and/or individuals, and will be numbered in the following manner:

Plan ID No Location Person Responsible

Section II: Business Continuity Strategy

A.   Introduction

This section of the <Department Name> Business Continuity Plan describes the strategy devised to maintain business continuity in the event of a facilities disruption. This strategy would be invoked should the <ORGANIZATION NAME> <Department Name> primary facility somehow be damaged or inaccessible. It is assumed that each critical business function at your location also has their own group/department Business Continuity Plan, which is similar to this plan except the recovery procedures and appendices have been customized for each respective group/department based on size, and complexity.

B. Business Function Recovery Priorities

The strategy is to recover critical <Department Name> business functions at the alternate site location.  This can be possible if an offsite strategy has been put into effect by Office Services and Disaster Recovery/IT Teams to provide the recovery service. Information Systems will recover IT functions based on the critical departmental business functions and defined strategies. Business Functions by Location are listed in Appendix B (Recovery Priorities for Critical Business Functions).  “Time Critical Business Functions,” i.e., those of which are of the most critical for immediate recovery at the secondary location are:
Reference: Appendix B – Recovery Priorities for Critical Business Functions

C. Relocation Strategy and Alternate Business Site

In the event of a disaster or disruption to the office facilities, the strategy is to recover operations by relocating to an alternate business site.  The short-term strategies (for disruptions lasting two weeks or less), which have been selected, include:

Primary Location Alternate Business Site
<Office Address> TBD

For all locations, if a long-term disruption occurs (i.e. major building destruction, etc.); the above strategies will be used in the short-term (less than two weeks).  The long-term strategies will be to acquire/lease and equip new office space in another building in the same metropolitan area.

D.   Recovery Plan Phases

The activities necessary to recover from a <ORGANIZATION NAME> facilities disaster or disruption will be divided into four phases.  These phases will follow each other sequentially in time.

1.    Disaster Occurrence

This phase begins with the occurrence of the disaster event and continues until a decision is made to activate the recovery plans.  The major activities that take place in this phase includes: emergency response measures, notification of management, damage assessment activities, and declaration of the disaster.

2.    Plan Activation

In this phase, the Business Continuity Plans are put into effect. This phase continues until the alternate facility is occupied, critical business functions reestablished, and computer system service restored to <ORGANIZATION NAME>’s Departments. The major activities in this phase include: notification and assembly of the recovery teams, implementation of interim procedures, and relocation to the secondary facility/backup site, and re-establishment of data communications.

3. Alternate Site Operations

This phase begins after secondary facility operations are established and continues until the primary facility is restored.  The primary recovery activities during this phase are backlog reduction and alternate facility processing procedures.

4. Transition to Primary Site

This phase consists of any and all activities necessary to make the transition back to a primary facility location.

E. Vital Records Backup

All vital records for <Department Name> that would be affected by a facilities disruption are maintained and controlled by either <Department Name> or Disaster Recovery/IT. Some of these files are periodically backed up and stored at an offsite location as part of normal <Department Name> operations.  When <Department Name> requires on-site file rooms, scanning, and organization offsite storage locations, best practices advise using one near-by Records Warehouse and another secure site for vital records and data back-up.  All vital documents are typically located in files within the office complex and the most current back-up copies are in a secure off-site storage facility.

F.    Restoration of Hardcopy Files, Forms, and Supplies

In the event of a facilities disruption, critical records located in the <Department Name> Department may be destroyed or inaccessible.  In this case, the last backup of critical records in the secure warehouse would be transported to the secondary facility.  The amount of critical records, which would have to be reconstructed, will depend on when the last shipment of critical records to the offsite storage location occurred.<Department Name> management will arrange the frequency of rotation of critical records to the offsite storage site. The following categories of information can be exposed to loss:

  1. Any files stored on-site in file cabinets and control file rooms.
  2. Information stored on local PC hard drives.
  3. Any work in progress.
  4. Received and un-opened mail.
  5. Documents in offices, work cubes and files.
  6. Off-site records stored in the Records Warehouse (if this is not a secure, hardened facility).

G.   On-line Access to <ORGANIZATION NAME> Computer Systems

In the event of a facilities disruption, the IT Disaster Recovery Plan strategy should be to assist in re-establishing connectivity to the <ORGANIZATION NAME> departments and to establish remote communications to any alternate business site location.  If the data center is affected by a disaster or disruption, the IT Disaster Recovery Plan should include recovering processing at a pre-determined alternate site. Services covered would include; phones, cellular phones, pagers, communications, and all other services required for restoring limited emergency service to the organization. In this case, data communications will be rerouted from the data processing hot or cold site to the respective alternate business site locations.

BCP Representatives – It will be necessary to contact your respective Information Technology department in order to complete this section. You should understand, and enter here, what the recovery timeframe is for systems recovery (i.e. will have critical systems restored within hours or days) and what the strategy is for acquisition, installation, and connection of PC’s/terminals.  Acquisition and recovery of critical standalone personal computer capabilities should also be considered here.  You should also understand the Information Technology strategy for recovery of applications, either AS/400 based and/or those on desktop systems, which <Department Name> relies on.

H. Mail and Report Distribution

During the time that <ORGANIZATION NAME> department operations are run from the secondary facilities, output reports and forms will have to be delivered to that location.  The data center may or may not have the same print capability if the disruption affected the data center as well, so it may be necessary to prioritize printing of output. The EOC Administration Team in conjunction with designated delivery/courier services will distribute mail to all <ORGANIZATION NAME> alternate business sites.  Due to the possibility of multiple alternate business sites and the additional travel time required for mail service activities, the number of mail pickups and deliveries could possibly be decreased from the normal daily routine to once daily.  Mail pickup and delivery schedules, including overnight mail, will be established and communicated to each alternate business site.  Overnight mail/package delivery carriers should be contacted directly by a business function for items requiring pickup after the last scheduled pickup by the EOC Administration Team.  All overnight mail service vendors will be notified by the EOC Administration Team of appropriate alternate office addresses to redirect deliverables to <ORGANIZATION NAME> personnel or provide for pick up at the post office by a Team member.

Section III: Recovery Teams

A. Purpose and Objective

This section of the plan identifies who will participate in the recovery process for the <Department Name> Business Continuity Plan. The participants are organized into one or more teams.  Each team has a designated team leader and an alternate for that person.  Other team members are assigned either to specific responsibilities or as team members to carry out tasks as needed.

The information in this section is organized into several subsections.

B. Recovery Team Descriptions

This section lists the team definitions for the <Department Name> Team and gives a short explanation of the function of each team or function.

<Department Name> Recovery Team:

Responsible for oversight of the <Department Name> recovery functions.

 C.   Recovery Team Assignments

This section identifies the team roles and the specific responsibilities that have been assigned to the team.

Team leader-Overall coordination of <Department Name> Recovery Team

Backup Team Leader – Duties to be assigned based on Recovery Team areas of responsibility.

Team Member – Duties to be assigned based on Recovery Team areas of responsibility

D.  Personnel Notification

This section specifies how the team members are to be notified if the plan is to be put into effect by identifying who calls whom, and in what order.  Notification can also be made by using tools such reverse 911 or other notification systems.

References:   Appendix A – Employee Telephone Lists

E. Team Contacts

This section identifies other people or organizations outside of the <Department Name> Team who might need to be contacted during the recovery process.  Their names and telephone numbers are provided.

 Reference: Appendix A – Employee Telephone Lists

 F. Team Responsibilities

Departmental Recovery Teams

Name Department/Position Floor Comments

Business Continuity Coordinator – <Insert Name>

In the event of a disaster, the Business Continuity Coordinator is responsible for ensuring that the following activities are successfully completed:

  • Works with the <ORGANIZATION NAME> Emergency Management Team to officially declare a disaster, and start the Disaster Recovery/Business Continuation process to recover <ORGANIZATION NAME>’s business functions at an alternate site.
  • Alert <ORGANIZATION NAME>’s Senior Management that a disaster has been declared.
  • Assist in the development of an official public statement concerning the disaster. The <ORGANIZATION NAME>’s EOC Communications Team Leader is the only individual authorized to make public statements about organization affairs.
  • Monitor the progress of all Business Continuity and Disaster Recovery teams daily.
  • Present Business Continuity Plan recovery status reports to Senior Management on a daily basis.
  • Interface with appropriate work management personnel throughout the recovery process.
  • Communicate directions received from <ORGANIZATION NAME>’s Senior Management to the EOC and Departmental Business Continuity Team Leaders.
  • Provide on-going support and guidance to the Business Continuity teams and personnel.
  • Review staff availability and recommend alternate assignments, if necessary.
  • Work with <ORGANIZATION NAME>’s Senior Management to authorize the use of the alternate recovery site selected for re-deploying critical <ORGANIZATION NAME> resources.
  • Review and report critical processing schedules and backlog work progress, daily.
  • Ensure that a record of all Business Continuity and Disaster Recovery activity and expenses incurred by <ORGANIZATION NAME> is being maintained.

EOC Communications Team –

This team is responsible for providing information regarding the disaster and recovery efforts to:

  • <ORGANIZATION NAME> and organization offices Senior Management
  • Customers
  • Vendors/Contracts
  • Media
  • Regulatory Agencies
  • Other Stakeholders
  • Coordinating, submitting, and tracking any and all claims for insurance.

EOC Human Resources Team –

This team is responsible for:

  • Providing information regarding the disaster and recovery efforts to employees and families.
  • Assisting in arranging cash advances if out of area travel is required.
  • Notifying employee’s emergency contact of employee injury or fatality.
  • Ensuring the processing of all life, health, and accident insurance claims as required.
  • Coordinates temporary organization employee requests.

EOC Administration Team –

This team is responsible for:

  • Ensuring the recovery/restoration personnel has assistance with clerical tasks, errands, and other administrative activities.
  • Arranging for the availability of necessary office support services and equipment.
  • Providing a channel for authorization of expenditures for all recovery personnel.
  • Arranging travel for employees.
  • Tracking all costs related to the recovery and restoration effort.
  • Identifying and documenting when repairs can begin and obtaining cost estimates.
  • Determining where forms and supplies should be delivered, based on damage to the normal storage areas for the materials.
  • Contacting vendors to schedule specific start dates for the repairs.
  • Taking appropriate actions to safeguard equipment from further damage or deterioration.
  • Coordinating the removal, shipment, and safe storage of all furniture, documentation, supplies, and other materials as necessary.
  • Supervise all salvage and cleanup activities.
  • Coordinating required departmental relocations to the recovery sites.
  • Coordinating relocation to the permanent site after repairs are made
  • Assuring that arrangements are made for meals and temporary housing facilities, when required, for all recovery personnel.
  • Assuring order placement for consumable materials (forms, supplies, etc.) for processing based upon input from the other teams.
  • Notifying the United States Postal Service of delivery disruption.
  • Establishing internal mail delivery procedures and process.
  • Assuring that mail, and reports are redirected to the proper location as required.

Emergency Response Team –

This team is responsible for:

  • The safety of all employees.
  • Inspecting the physical structure and identifying areas that may have sustained damage.
  • Expanding on and/or revising the findings of the Preliminary Damage Assessment.
  • Providing management with damage assessment reports and recommendations.

Information Technology Recovery Team (See also Disaster Recovery Plan) –

This team is responsible for:

  • Activating the IT Technology Recovery Plan (See also Disaster Recovery Plan).
  • Managing the IT disaster response and recovery procedures.
  • Mobilizing and managing IT resources.
  • Coordinating all communications related activities, as required, with telephone & data communications, PC, LAN support personnel, and other IT related vendors.
  • Assisting, as required, in the acquisition and installation of equipment at the recovery site.
  • Ensuring that cellular telephones, and other special order equipment and supplies are delivered to teams as requested.
  • Participating in testing equipment and facilities.
  • Participating in the transfer of operations from the alternate site as required.
  • Coordinating telephone setup at the EOC and recovery site.
  • Coordinating and performing restoration or replacement of all desktop PCs, LANs, telephones, and telecommunications access at the damaged site.
  • Coordinating Disaster Recovery/IT efforts between different departments in the same or remote locations.
  • Training Disaster Recovery/IT Team Members.
  • Keeping Senior Management and the EOC Business Continuity Coordinator appraised of recovery status.

 Section IV: Recovery Procedures

A. Purpose and Objective

This section of the plan describes the specific activities and tasks that are to be carried out in the recovery process for <Department Name>. Given the Business Continuity Strategy outlined in Section II, this section transforms those strategies into a very specific set of action activities and tasks according to recovery phase.

The Recovery Procedures are organized in the following order: recovery phase, activity within the phase, and task within the activity.

The recovery phases are described in Section II.D of the Plan.  In the Recovery Procedures document, the phases are listed in the order in which they will occur.  The description for each recovery phase begins on a new page.

Each activity is assigned to one of the recovery teams.  Each activity has a designated team member who has the primary assignment to complete the activity.  Most activities also have an alternate team member assigned.  The activities will only generally be performed in this sequence.

The finest level of detail in the Recovery Procedures is the task.  All plan activities are completed by performing one or more tasks. The tasks are numbered sequentially within each activity, and this is generally the order in which they would be performed.

B. Recovery Activities and Tasks

PHASE I:  Disaster Occurrence 

ACTIVITY:  Emergency Response and Emergency Operations Center Designation

ACTIVITY IS PERFORMED AT LOCATION:  Main Office or Emergency Operations Center

ACTIVITY IS THE RESPONSIBILITY OF THIS TEAM:  All Employees

 TASKS:

  1. After a disaster occurs, quickly assess the situation to determine whether to immediately evacuate the building or not, depending upon the nature of the disaster, the extent of damage, and the potential for additional danger.

Note: If the main office is total loss, not accessible or suitable for occupancy, the remaining activities can be performed from the Emergency Operations Center (EOC), after ensuring that all remaining tasks in each activity have been addressed.  This applies to all activities where the Main Office is the location impacted by the disaster.  The location(s) of the EOC are designated in Appendix D – Emergency Operations Center (EOC) Locations.  The EOC may be temporarily setup at any one of several optional locations, depending on the situation and accessibility of each one.  Once the Alternate site is ready for occupancy the EOC can be moved to that location.

  1. Quickly assess whether any personnel in your surrounding area are injured and need medical attention. If you are able to assist them without causing further injury to them or without putting yourself in further danger, then provide what assistance you can and also call for help.  If further danger is imminent, then immediately evacuate the building.
  2. If appropriate, evacuate the building in accordance with your building’s emergency evacuation procedures. Use the nearest stairwells.  Do not use elevators.
  3. Outside of the building meet at (XXXXXXXX XXXXXXXXXX)Do not wander around or leave the area until instructed to do so.
  4. Check in with your department manager for roll call. This is important to ensure that all employees are accounted for.

ACTIVITY:  Notification of Management

ACTIVITY IS PERFORMED AT LOCATION:  At Any Available Phone

ACTIVITY IS THE RESPONSIBILITY OF: <Department Name> Management Team
PRIMARY:  <INSERT NAME>
ALTERNATE:  <INSERT NAME>
 TASKS:

  1. Team leader informs the members of the <Department Name> management team and notifies the <Department Name> senior management if they have not been informed.
  2. <Department Name> personnel are notified of the disaster by following procedures as included in Section III. D. – Recovery Personnel Notification.
  3. Depending upon the time of the disaster, personnel are instructed what to do (i.e. stay at home and wait to be notified again, etc.) 

ACTIVITY:  Preliminary Damage Assessment

ACTIVITY IS PERFORMED AT LOCATIONMain Office Location

ACTIVITY IS THE RESPONSIBILITY OF:  <Department Name> Management Team 

TASKS:

  1. Contact the Organization Emergency Response Team Leader to determine responsibilities and tasks to be performed by the <Department Name> Management Team or employees.
  2. If the Organization Emergency Response Team requests assistance in performing the Preliminary Damage Assessment, caution all personnel to avoid safety risks as follows:
  • Enter only those areas the authorities give permission to enter.
  • Ensure that all electrical power supplies are cut to any area or equipment that could posses a threat to personal safety.
  • Ensure that under no circumstances is power to be restored to computer equipment until the comprehensive damage assessment has been conducted, reviewed, and authority to restore power has been expressly given by the Emergency Management Team.
  1. Inform all team members that no alteration of facilities or equipment can take place until the Risk Management representatives (this is a function provided through the Department of Central Services as a statewide service) have made a thorough assessment of the damage and given their written agreement that repairs may begin.
  2. Instruct the Organization Emergency Response Team Leader to deliver the preliminary damage assessment status report immediately upon completion.
  3. Facilitate retrieval of items (contents of file cabinets — petty cash box, security codes, network backup tapes, control books, etc.) needed to conduct the preliminary damage assessment.
  4. Ensure that administrative support is available, as required.
  5. Arrange a meeting with the Emergency Management Team and Management Teams from other GROUPS/DEPARTMENTS in your facility (location) to review the disaster declaration recommendation that results from the preliminary damage assessment and to determine the course of action to be taken. With this group, determine the strategy to recommend to Senior Management (the Emergency Management Team Leader will be responsible for communicating this to Senior Management).

ACTIVITY: Declaration of a Disaster

ACTIVITY IS PERFORMED AT LOCATION: Main Office Location or Alternate Site/Emergency Operations Center

ACTIVITY IS THE RESPONSIBILITY OF:  <Department Name> Management Team 

TASKS:

  1. Actual declaration of a disaster is to be made by the Emergency Management Team, after consulting with senior management. The <Department Name> Management Team should wait for notification from the Emergency Management Team that a disaster has been declared and that groups/departments are to start executing their Business Continuity Plans and relocate to their Alternate Business Site Location.
  2. The person contacted verifies that the caller is someone who is authorized to do the notification.
  3. The person contacted notifies the <Department Name> Senior Management, if they have not yet been contacted.
  4. In the event the Emergency Management Team cannot be assembled or reached, the Team Leaders from each <Department Name> Management Team at the location should assemble, gather appropriate information, consult with senior management, and make the decision whether to declare the disaster.
  5. Because of the significance, disruption, and cost of declaring a disaster, appropriate facts should be gathered and considered before making the decision to declare a disaster. Individual groups/department personnel or the respective <Department Name> Management Teams should not unilaterally make a decision to declare a disaster.  This is responsibility of the Emergency Management Team.

PHASE II: Plan Activation

ACTIVITY:  Notification and Assembly of Recovery Teams and Employees

ACTIVITY IS PERFORMED AT LOCATION:  Alternate Site/Emergency Operations Center

ACTIVITY IS THE RESPONSIBILITY OF<Department Name> Management Team

 TASKS:

  1. The team leader calls each member of the management team, instructs them of what time frame to assemble at the <Department Name> Emergency Operations Center (to be decided at the time), and to bring their copies of the Plan. The location(s) of the EOC are designated in Appendix D – Emergency Operations Center (EOC) Locations.  The EOC may be temporarily setup at any one of several optional locations, depending on the situation and accessibility of each one.  Once the Alternate site is ready for occupancy the EOC can move to that location, if preferred.
  2. Review the recovery strategy and action plan with the assembled team.
  3. If necessary, adjust the management team assignments based on which members are available.
  4. The Management Team contacts critical employees and tells them to assemble at the alternate site. If the alternate site is a long distance from the primary site (i.e. out-of-state), then individuals should make their own travel arrangements to the alternate site.  Non-critical employees should be instructed to stay at home, doing what work is possible from home, until notified otherwise.
  5. In the event of a disaster that affects telecommunications service regionally, the Management Team should instruct critical employees to proceed to the alternate site even if they have not been contacted directly. Delays in waiting for direct communications can have a negative impact on <ORGANIZATION NAME>’s ability to recover vital services.

ACTIVITY:  Relocation to Alternate Site

ACTIVITY IS PERFORMED AT LOCATION:  Alternate Site

ACTIVITY IS THE RESPONSIBILITY OF:  All Critical Personnel

 TASKS:

  1. When instructed by the <Department Name> Management Team, make arrangements to commute or travel to the alternate site. Reference item #5 under Notification and Assembly Procedures for exception to this step.
  2. The <Department Name> Management Team needs to consult with the Emergency Management Team and the Organization Emergency Response Team to determine if access can be gained to the primary (damaged) site to retrieve vital records and other materials. The Organization Emergency Response Team will only allow access to the primary site if the authorities grant access.  This will be dependent upon the nature of the disaster and the extent of damage.
  3. If allowed access to the primary site to retrieve vital records and other materials, perform some pre-planning to determine what is most important to retrieve. This may be necessary since the time you may be allowed access to the primary site may be minimal.
  4. Depending on the amount of vital records and other materials you are able to retrieve from the primary site, make arrangements to transport this material to the alternate site. If the material is not too great, this could be accomplished by giving to employees to carry along with them.  If the material is a large amount, then make arrangements for transport services and/or overnight courier services.
  5. Management and critical employees travel to alternate site.

ACTIVITY:  Implementation of Interim Procedures

ACTIVITY IS PERFORMED AT LOCATION:  Alternate Site

ACTIVITY IS THE RESPONSIBILITY OF:  <Department Name> Management Team

 TASKS:

  1. After arrival at the alternate site, map out locations that can be used for workspace. This should include unused offices and cubicles, conference rooms, training rooms, lunch/break areas, and open space in hallways or in other areas.
  2. Obtain additional tables and chairs, either from the office or from outside rental agencies to provide additional workspace. Place in any available open areas, but be cautious of not blocking exits for fire evacuation purposes.
  3. Determine flexible working schedules for staff to ensure that client and business needs are met, but also to enable effective use of space. This may require that some employee’s work staggered shifts or may need to work evening or nightshifts.
  4. Gather vital records and other materials that were retrieved from the primary site and determine appropriate storage locations, keeping in mind effectiveness of workgroups.
  5. Determine which vital records, forms, and supplies are missing. Obtain from off-site storage location or from other sources, as needed, per Appendices E & F.
  6. Developed prioritized work activities, especially if all staff members are not available.

ACTIVITY:  Establishment of Telephone Communications

ACTIVITY IS PERFORMED AT LOCATION:  Alternate Site

ACTIVITY IS THE RESPONSIBILITY OF:  IT Liaison

 TASKS:

  1. Contact the Organization Disaster Recovery/IT Team to determine what activities they are taking to reroute telephone communications to the alternate site. Do not directly contact the telephone company – this will be handled by the Organization Disaster Recovery/IT Team.
  2. If your alternate site is at another <ORGANIZATION NAME> office, prepare a list of phone extensions which your staff will be temporarily using and provide this list to the alternate site switchboard attendant.
  3. If your primary office phones will not be switched to the alternate site, let the Organization Disaster Recovery/IT Team know that the phones need to be transferred to the phone numbers you will be using at the alternate site.
  4. Coordinate with the Organization Communications Team regarding contacting customers to notify them of the disaster situation, how <ORGANIZATION NAME> is responding, and how you can be reached. Do not contact customers until the Organization Communications Team has given you directions.

Organization Communications will provide you with scripts and guidance on how to discuss the disaster with customers to provide assurance that their confidence in <ORGANIZATION NAME> will be maintained.

ACTIVITY:  Restoring Data Processing and Data Communications with Primary or Secondary Backup Data Center
ACTIVITY IS PERFORMED AT LOCATION:  Alternate Site

ACTIVITY IS THE RESPONSIBILITY OF THIS TEAM:  IT Liaison 

TASKS:

  1. Contact the Organization Disaster Recovery/IT Team to determine when the data center is to be recovered, if affected by the disaster. Also, discuss when data communications will be established between the primary or secondary backup data center and your alternate site.
  2. If your alternate site is another <ORGANIZATION NAME> office, determine if that site has access to the computer systems that <Department Name> uses. If so, work with local office management to determine how workstations can be shared between personnel from their groups/departments and <Department Name>.  This may involve using flexible hours or multiple shifts for your personnel.
  3. Discuss with the Organization Disaster Recovery/IT Team when and how replacement PC’s and/or terminals will be provided to you at the alternate site and when they will be connected.
  4. Discuss with the Organization Disaster Recovery/IT Team when the files from your normal PC/LAN servers and applications will be restored and how you can access those files. Also, work with other <ORGANIZATION NAME> management at your alternate site to discuss using their LAN servers.
  5. Discuss with the Organization Disaster Recovery/IT Team your normal application report distributions, such as when you can expect to receive standard computer reports and how they will be distributed to your alternate site.
  6. Communicate the IT recovery status to all <Department Name> personnel who regularly use the systems.

PHASE III: Alternate Site Operations 

ACTIVITY:  Alternate Site Processing Procedures

ACTIVITY IS PERFORMED AT LOCATION: Alternate Site

ACTIVITY IS THE RESPONSIBILITY OF: Alternate Site Operations Team 

TASKS:

  1. Communicate with customers regarding the disaster and re-solicit phone contacts (in conjunction with the Organization Communications Team)
  2. Acquire needed vital documents
  3. Access missing documents and files and reconstruct, if necessary
  4. Set up operation 

ACTIVITY:  Manage work backlog reduction.

ACTIVITY IS PERFORMED AT LOCATION:  Alternate Site

ACTIVITY IS THE RESPONSIBILITY OF:  Alternate Site Operations Team 

TASKS:

  1. Determine priorities for work backlogs to ensure the most important backlogged tasks are resolved first.
  2. Set an overtime schedule, if required, based on staff and system availability.
  3. Set backlog priorities, establish a backlog status reports if necessary, and communicate this to the <Department Name> supervisor.
  4. Report the backlog status to <Department Name> management on a regular basis.
  5. If backlogs appear to be very large or will take a significant time to recover, determine if temporaries could be used for certain tasks to help eliminate the backlogs. If justified, arrange for temporaries to come in.

PHASE IV: Transition to Primary Operations                  

ACTIVITY:  Changing Telephone and Data Communications Back to Primary Site

ACTIVITY IS PERFORMED AT LOCATION:  Alternate Site

ACTIVITY IS THE RESPONSIBILITY OF:  IT Liaison 

TASKS:

  1. Coordinate with the Organization Disaster Recovery/IT Team to determine when <Department Name> will be relocating back to the primary site. Verify that they have a schedule to ensure that telephone and data communications are rerouted accordingly.
  2. Discuss when and how PC’s, terminals, and printers, if brought into the alternate site, will be de-installed, moved back to the primary site and re-installed. 

ACTIVITY:  Terminating Alternate Site Procedures

ACTIVITY IS PERFORMED AT LOCATION:  Alternate Site and Primary Site

ACTIVITY IS THE RESPONSIBILITY OF:  <Department Name> Team 

TASKS:

  1. Determine which alternate site operating procedures will be suspended or discontinued and when.
  2. Communicate the changes in procedures to all affected staff.
  3. Determine if additional procedures are needed upon return to the primary site, such as to continue resolving work backlogs. 

ACTIVITY: Relocating Personnel, Records, and Equipment Back to Primary (Original) Site

ACTIVITY IS PERFORMED AT LOCATION:  Alternate Site and Primary Site

ACTIVITY IS THE RESPONSIBILITY OF:  <Department Name> Management Team 

TASKS:

  1. In conjunctions with the Emergency Management Team and the Organization Emergency Response Team, determine when <Department Name> will be scheduled for relocating back to the primary site.
  2. Communicate this schedule to all <Department Name> personnel.
  3. Inventory vital records, equipment, supplies, and other materials, which need to be transported from the alternate site to the primary site.
  4. Pack, box, and identify all materials to be transported back to the primary site.
  5. In conjunction with the Organization Administration Team, make arrangement for a moving company or courier service to transport the boxes back to the primary site.

Section V: Appendices 

Appendix A – Employee Telephone Lists 

Employee Title/Function Office Phone # Home Phone # Cellular/Pager # EMAIL Time Called Arrival Time Comment
*
**
**
 
 
 
 
 
 
Fire, Police, Emergency  

*     Indicates Team Leader
**    Indicates Alternate Team Leader

Appendix B – Recovery Priorities for Critical Business Functions

Department

 

Priorities Maximum Allowable Downtime

 

<Department Name>   1-2 Days 3-5 days 1-2 weeks > 2 weeks
 

Contracts

 

Critical

 

 

X

   
     
         
           
           
           
           
           
           
           
           
           
           

 Appendix C – Alternate Site Recovery Resource Requirements

General Requirements 

# Description Current

Number

BCP

Number

Comments
1. Number of people

 

2. Square footage needed

 

3. Power Outlets 110V

 

Can use power strips
4. Power Outlets 220V

 

5. Telephones

 

6. Telephone lines

 

7. Desks

 

8. Chairs

 

9. Tables

 

10. Typewriters

 

11. Photocopiers

 

12. Calculators

 

13. Microfiche Viewers

 

14. File Cabinets (specify type)

 

4 drawer lateral file cabinets
15. Other – Please attach list

 

Technical Requirements 

# Description Current

Number

BCP

Number

Comments
1. Telephone Lines (regular)

 

2. Telephone Lines (800 or special)

 

3. Single Line Telephone Sets

 

4. Other Type Telephone Sets

TWO LINE

5. Stand-alone FAX Machines

 

6. PC’s

 

7. LAN/WAN Connections

 

8. Printers  – LAN

 

9. Printers – Direct attach to PC

 

10. PC Connectivity outside <ORGANIZATION NAME>* (Internet)
11 Other Computers

 

12. Fax – Stand alone

 

13. Other – Please attach  list

 

Appendix D – Emergency Operations Center (EOC) Locations 

Disaster Affecting Which Area/Building                        EOC Location

<ORGANIZATION NAME> Home Community  City

Recovery Locations and Travel Directions

Alternate Sites

Critical Function Alternate Site
Desktop and Personnel
EOC Emergency Management Team

NOTE – Provide directions to all alternate sites. Include address and phone number of site.  Include Maps and Floor Plans.

Appendix E – Vital Records

Description Primary Location of Records Alternate (Backup) Location of Records Other Sources to Obtain Records
Settlement Agreements Department File Cabinets Vault Scanned images on Network drive/Other Parties
Litigation Files Department File Room Scanned Images of pleadings on Network drive Outside Counsel/Courts

 Appendix F – Forms and Supplies

Form/Supply Name/Description Primary Locations Where Stored Alternate Sources to Obtain Form/Supply Vendor’s Name/Phone
No special form or supplies other than standard office supplies.

Appendix G – Vendor Lists

Vendor Name Goods/Service Provided Contact Name Address Phone #
Master Service Agreements and other contractors  – lists available on network Master Service Agreement and Insurance databases

Appendix H – Desktop Computer Configurations

Description of Desktop:  Dell, etc                                                                                      

Used By: All <Department Name> Employees                                                                    

Business Activity Supported:                                                                                             

Connected to Which LAN’s:                                                                                               

Used for Host Access (Which Applications): network printing                                              

Special Features, Boards, Memory Size, Etc.: over 20 Gigs HD, over 128MB Memory _____

Over 850 MHz Processor(s)                                                                                               

Ethernet Net Cards, Fax/Modems                                                                                      

Proprietary Software required (indicate release number, version and/or level, as applicable:  

The IT Department maintains records on all desktop systems.                                         

                                                                                                                                        

                                                                                                                                        

 Appendix I – Computer System Reports

 

Report Name

 

Report Description

System Produced From Alternate Sources of Report or Information
No special computer reports required.

Appendix J – Critical Software Resources

Software Application Publisher or Vendor Platform Recovery Criticality

 Appendix K – Alternate Site Transportation Information

Employees will be notified (by team members), if a disaster is declared, as to the location and when to report.  Since recovery site is local, transportation to the work location is up to the employee unless directed otherwise.  Directions will be supplied at the time of notification, if necessary.

Appendix L – Alternate Site Accommodations Information

Should alternate site accommodations be required team members will be notified.  Employees will be contacted (by team members), if a disaster is declared, as to the location and where to go.  Since accommodations are local, transportation to the work location is up to the employee unless directed otherwise.  Directions will be supplied at the time of notification, if necessary.

Appendix M – Severity Impact Assessments

<Department Name> 

                  Severity of Impact
Least ——> to ——> Greatest Comments
Impact Area 1 2 3 4 5
1 Cash Flow Interruption          
2 Inoperative Billing Systems          
3 Inoperative Financial Controls          
4 Loss of Customers          
5 Financial Reporting (Banks, IRS, etc.)          
6 Increases in Liability          
7 Loss of Public Image          
8 <Department Name> and Regulatory Violations          
9 Contractual Violations          
10 Vendor Liabilities & Relations          
11 Customer Liability & Relations          
12 Effect on Employee Morale          
13 Staff Resignations          

Appendix N – <ORGANIZATION NAME> Business Impact Assessment

Department or Function: <ORGANIZATION NAME>
Number of Employees in HOME COMMUNITY :
Primary Business Function:
Executive:BCP Representative:
What’s at Stake:  $ Millions Plus
STRENGTHS
Example
Able to work from home if access to e-mail and system is available through dial-up access. Will need records and files as well.
WEAKNESSES
Example
Unable to work remotely if access to records and files is restricted.
Loss Impact
Example
Our department would not be able to perform >95% of its work without access to our computers or work areas. It would take time and effort to recreate the contracts and other information (to the extent they can be recreated) before we could work on them.
Maximum Allowable Downtime:> 24 – 48 Hours

Appendix O – Recovery Tasks List

Recovery Activation Date: ________

Task No. Task Description Estimated Time Actual Time Assigned To Assigned Time Completed Time Comments
10 Receive Communication on emergency Situation
20 Identify recovery site
30 Retrieve Business Continuity Plans
40 Notify department members identified in Appendix A
50 Retrieval of  department Vital Records
60 Oversee delivery and placement of office equipment.
70 Oversee delivery and placement of office supplies.
80

Back to Trace International

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Technical Vulnerability Management Policy

1 Policy Statement

To meet the enterprise business objectives and ensure continuity of its operations, XXX shall adopt and follow well-defined and time-tested plans and procedures, to ensure that all technical vulnerabilities that exist in the IT systems  are identified and managed. IT systems contain inherent weaknesses that are termed as vulnerabilities. Threats exploit vulnerabilities to cause harm to IT systems. Hence, it is imperative to regularly identify and plug those vulnerabilities and prevent occurrence of security incidents.

2 Purpose

The purpose of the Technical Vulnerability Management Policy is to establish rules and principles for identifying and managing vulnerabilities in IT systems.

3 Scope

3.1 IT Assets

This policy applies to all hardware, software, and network assets.

3.2 Documentation

The documentation shall consist of Technical Vulnerability Management Policy and related procedures & guidelines. The Technical Vulnerability Management Policy document and all other referenced documents shall be controlled. Version control shall be to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purpose.

3.3 Records

Records being generated as part of the Technical Vulnerability Management Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

3.4 Distribution and Maintenance

The Technical Vulnerability Management Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the document shall be with the CISO and website administrator.

4 Privacy

The Technical Vulnerability Management Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

5 Responsibility

The CISO / designated personnel and system administrator are responsible for proper implementation of the Technical Vulnerability Management Policy.

6 Policy

It is the stated goal of XXX to provide secure IT systems and services in order to protect organizational information assets, as well as the privacy of employees, contractors, and third party employees. The timely and consistent application of vendor-supplied security patches or mitigation of a reported vulnerability are critical components in protecting the network, systems, and data from damage or loss due to threats such as worms, viruses, data loss, or other types of external or internal attacks. XXX  shall conduct routine scans of its website, servers (including those hosted at ABC), and devices connected to its networks to identify operating system and application vulnerabilities on those devices. XXX requires its system administrators to routinely review the results of vulnerability scans and evaluate, test and mitigate operating system and application vulnerabilities appropriately. Should an administrator identify a reported vulnerability as a potential false positive, the CISO should be notified immediately.

7Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy.

Back to Trace International

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Website Security Policy

 

1 Policy Statement

To meet the enterprise business objectives and ensure continuity of its operations, XXX shall adopt and follow well-defined and time-tested plans and procedures, to ensure integrity, availability, and authenticity of its website and all information contained within. An organization’s website is its interface with the external world. Information contained within the website is deemed as authentic statements from the management of the organization. It is imperative to publish only authenticated content on the website and maintain its integrity and availability.

2 Purpose

The purpose of the Website Security Policy is to establish rules for preserving the integrity, availability, and authenticity of XXX’s website.

3 Scope

3. 1 Employees

This applies to all permanent employees, contractual employees, trainees, privileged customers and all other visitors.

3.2 Documentation

The Website Security Policy documentation shall consist of Website Security Policy and related procedures & guidelines.

3.3 Document Control

The Website Security Policy document and all other referenced documents shall be controlled. Version control shall be to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purpose.

3.4 Records

Records being generated as part of the Website Security Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

3.5 Distribution and Maintenance

The Website Security Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the Website Security Policy document shall be with the CISO and website administrator.

4. Privacy

The Website Security Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

5 Responsibility

The CISO / designated personnel and website administrator are responsible for proper implementation of the Website Security Policy.

6 Policy

Following are the policies defined for maintaining Security of the website:

  1. The website shall be developed and maintained as per relevant guidelines of Govt. of  Kuwait
  2. User registration for secured access to the website shall be required when i) a web application or internal link requires user identification before processing, or ii) accessed data has been classified as “sensitive” and requires further authorization.
  3. To facilitate site management, information shall be collected for statistical purposes. XXX shall employ software programs to compile summary usage statistics, which may be used for assessing what information is relevant to users. The data so accumulated may be used to help determine technical design specifications, identify system performance, or pinpoint problem areas.
  4. Except for authorized security investigations and data collection, no attempts shall be made to identify individual users or their usage habits. Accumulated data logs will be scheduled for regular deletion in accordance with schedules set by the web administrators.
  5. Unauthorized attempts to upload information or change website information are strictly prohibited, and may be punishable under relevant cyber laws.
  6. Access to sensitive or proprietary business information on the websites shall be limited to employees, customers, clients and vendors who have been determined to have an appropriate business reason for having access to such data. All registered website users, who are granted security access, will be identified by a user name (referred to as the User ID). All actions performed with a User ID will be the responsibility of the ID’s registered owner.
  7. Individuals who are granted password access to restricted information on the website are prohibited from sharing those passwords with, or divulging those passwords to, any third parties. User will notify XXX immediately in the event a User ID or password is lost or stolen or if user believes that a non-authorized individual has discovered the User ID or password.
  8. XXX’s records shall be final and conclusive in all questions concerning whether or not a specific User ID or password was used in connection with a particular action.
  9. Any data or document upload to social networking sites shall be duly authorized by the competent authority and shall be done by designated persons authorized to do so.

7 Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy.

Back to Trace International

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of System Monitoring Policy

1 Policy  Statement

To ensure that organizational IT systems are not open to abuse, XXX reserves the right to monitor individual staff usage but only where authorized by senior HR staff and where, in the circumstances, it is fair and appropriate to do so. A range of monitoring activities need to be established to ensure that the IT systems are operating efficiently and effectively. This includes the monitoring of information entering, leaving or stored on organizational IT systems. Such monitoring is not, in general, person specific, but employee’s personal data may be accessed as part of this policy.

2 Purpose

This policy offers guidance regarding monitoring of system use and related user activities. It is intended to guide and inform personnel and help them understand the importance of maintaining logs of all user activities on the system.

3 Scope

3.1 IT Assets

This policy applies to all organizational information systems and  Employees, Contractors, and Third Party Employees, who have access to IT assets and may be bound by contractual agreements.

3.2 Documentation

The System Monitoring Policy documentation shall consist of System Monitoring Policy, related procedures & guidelines.

3.3 Document Control

The System Monitoring Policy document and all other referenced documents shall be controlled. The version control shall be used to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purpose.

3.4 Records

Records being generated as part of the System Monitoring Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

3.5 Distribution and Maintenance

The System Monitoring Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the System Monitoring Policy document will be with the CISO and system administrators.

4 Privacy

The System Monitoring Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

5 Responsibility

The CISO / designated personnel is responsible for proper implementation of the System Monitoring Policy.

6 Policy

Systems shall be monitored to ensure all information security events are recorded. The organization shall comply with all relevant legal requirements applicable to the monitoring and logging activities. System monitoring shall be used as a means to check the effectiveness of controls adopted and also to verify the conformance to the organizational access control and acceptable use policies.
System monitoring shall consider the following aspects:
a. compliance with regulatory and statutory obligations;
b. effective maintenance of IT systems;
c. prevention or detection of unauthorized use of, or other threats to, organizational IT systems, or criminal activities;
d. compliance with organizational policies and procedures; and
e. review of usage and staff training.

7 Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy.

Back to Trace International

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Anti-Spam and Unsolicited Commercial Email (UCE) Policy

1.  Purpose

This policy describes the permitted and prohibited uses of corporate email systems for bulk emailing. Its purpose is to:
1. protect organizational reputation,
2. preserve the effectiveness of email as a business communication medium,
3. prevent potential breach of the US CAN-SPAM Act by employees, and
4. to generally encourage adherence to e-mailing best practices.

2. Overview

The practice of sending unsolicited, commercial mass e-mails represents a potential threat to organizational reputation and may be violation, which defines the quantity and characteristics of bulk commercial e-mails that may legally be sent. All communications with customers, prospects and other professionals reflect XXX. In light of increasing antipathy to unsolicited email promotions of any kind, it is generally in the best interest of XXX to limit electronic mailings to legitimate communications with individuals have indicated a willingness to receive them.

3. Scope

All individuals who use the e-mail systems and addresses to send bulk e-mails to customers, prospects, or other types of recipients.

3.1 Employees

This policy applies to all  Employees, Contractors, and Third Party Employees, who use, process, and manage information and business processes of XXX.

3.2 Documentation

The documentation shall consist of software installation Policy, and related procedures & guidelines. This Policy document and all other referenced documents shall be controlled. Version control shall be to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purpose.

3.3 Records

Records being generated as part of this Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

3.4 Distribution and Maintenance

This Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the document shall be with the CISO and system administrators.

4. Privacy

This Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

5. Responsibility

This Policy shall be implemented by the CISO  and designated personnel (if any).This policy has full support from the  executive steering committee and human resources. This policy is a living document and may be modified at any time by the IT manager, human resources, or the executive steering committee.

6 Policy

  • All mass emails must be approved by IT Manager.
  • Individuals may send mass emails for the purpose of marketing or sales of products, services, or programs only to:
    • Recipients who specifically consented to receive marketing or sales emails
    • Recipients who have not explicitly opted out of receiving marketing or sales emails
  • Mass emails sent from computers or email addresses may not:
    • o Contain false or misleading information in the subject line, headers, or email body
    • o In any way misrepresent or disguise the sender, point of origin, or transmission path
  • Individuals may not send any emails to addresses that have been illicitly harvested, mined, or skimmed from one or more third-party Web sites. Employees may not build e-mail addresses or lists by guessing or using software to generate character strings that are likely to be associated with live email accounts.

Anti-spam restrictions also apply to other forms of electronic messaging:

  • Individuals may not post promotions or advertisements for products, services, or programs in newsgroups, message boards, chat rooms, or other online services in violation of the terms of participation of those online services.
  • Individuals may not post promotions or advertisements for products, services, or programs in newsgroups, message boards, chat rooms, or other online services that do not explicitly permit advertisements.
  • Individuals may not use vendors, software, or service providers or to circumvent the intent of this policy.

7 Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy.Violation of this policy may result in disciplinary action which may include performance sanctions; termination for employees and temporaries; a termination of employment relations in the case of contractors or consultants; dismissal for interns and volunteers; or suspension or expulsion in the case of a student. Additionally, individuals are subject to restriction or suspension of email privileges, as well as civil and criminal prosecution.

Back to Trace International

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Risk Management Policy

1 Policy Statement

To meet the enterprise business objectives and ensure continuity of its operations, XXX shall adopt and follow well-defined and time-tested plans and procedures, to ensure timely management of organizational risks. Employees are expected to cooperate fully with any Risk Assessment being conducted on systems for which they are held accountable. Employees are further expected to work with the Risk Assessment Team in the development of a remediation plan. The policy, and respective procedures, guidelines & forms shall be available to the CISO and members of senior management.

2 Definitions

Entity Any business unit, department, group, or third party, internal or external to XXX, responsible for maintaining assets.

RiskThose factors that could affect confidentiality, availability, and integrity of XXX’s key information assets and systems. The Risk Assessment Team is responsible for ensuring the integrity, confidentiality, and availability of critical information and computing assets on networks, while minimizing the impact of security procedures and policies upon business missions.

3 Purpose

The purpose of this policy is to identify areas of risk on a timely manner and manage them to ensure continuity of business processes.The execution, development and implementation of remediation programs are the joint responsibility of the IT Infrastructure management team and the department responsible for the systems area being assessed. Employees are expected to cooperate fully with any RA being conducted on systems for which they are held accountable. Employees are further expected to work with the Risk Assessment Team in the development of a remediation plan.

4 Scope

4.1 IT Assets

This policy applies to the entire IT Infrastructure.

4.2 Documentation

The Policy documentation shall consist of Risk Management Policy, Risk Assessment and Treatment Procedure, and related guidelines.

4.3 Document Control

The Risk Management Policy document and all other referenced documents shall be controlled. The version control shall be to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purpose.

4.4 Records

Records being generated as part of the Risk Management Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

4.5 Distribution and Maintenance

The Risk Management Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the Risk Management Policy document will be with the CISO and system administrators.

5 Privacy

The Risk Management Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

6 Responsibility

The CISO / designated personnel is responsible for proper implementation of the policy.

7 Policy

Risk Management Plan shall be drawn by the management which shall identify the people within XXX who will perform risk assessment operations. For this purpose, the events (or series of events) which cause disruption to business processes shall be identified. The risk assessment shall consider probability and impact of such disruptions in terms of time, scale of damage and recovery period. The risk assessment shall identify, quantify and prioritize risks against criteria and objectives relevant to the organization, including critical resources, impacts of disruptions, allowable outage times and recovery priorities. Based on the results of the assessment, business continuity strategy shall be outlined for XXX to determine overall approach to business continuity.The execution, development and implementation of remediation programs are the joint responsibility of the IT Infrastructure management team and the department responsible for the systems area being assessed. Employees are expected to cooperate fully with any RA being conducted on systems for which they are held accountable. Employees are further expected to work with the Risk Assessment Team in the development of a remediation plan.

8 Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy.

Back to Trace International

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Third Party Access Policy

1.  Purpose

This document describes the policy under which third party persons or organizations connect to or access network resources on XXX networks for the purpose of transacting business related to KDCC or other approved business transactions.

3. Scope

All connections and network resources access between third parties that require access to non-public resources fall under this policy, regardless of what technology is used for the connection. Connectivity to third parties such as the Internet Service Providers (ISPs) that provide Internet access for XXX or to the Public Switched Telephone Network does NOT fall under this policy.

3.1 Employees

This policy applies to all  Employees, Contractors, and Third Party Employees, who use, process, and manage information and business processes of XXX.

3.2 Documentation

The documentation shall consist of software installation Policy, and related procedures & guidelines. The Compliance Policy document and all other referenced documents shall be controlled. Version control shall be to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purpose.

3.3 Records

Records being generated as part of this Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

3.4 Distribution and Maintenance

This Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the document shall be with the CISO and system administrators.

4. Privacy

This Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

5. Responsibility

This Policy shall be implemented by the CISO  and designated personnel (if any).This policy has full support from the  executive steering committee and human resources. This policy is a living document and may be modified at any time by the IT manager, human resources, or the executive steering committee.

6 Policy

6.1 Pre-Requisites Security Review

All new extranet connectivity will go through a security review with the Office of IT Manager. The reviews are to ensure that all access matches the business requirements in a best possible way, and that the principle of least access is followed.

6.2 Third Party Connection Agreement

All new connection requests between third parties and XXX require that the third party and  representatives agree to and sign the Third Party Agreement. This agreement must be signed by the IT Manager as well as a representative from the third party who is legally empowered to sign on behalf of the third party.  By signing this agreement the third party agrees to abide by all referenced policies. The signed document is to be kept on file with the relevant extranet group.  All non-publicly accessible information is the sole property of XXX.

 6.3 Business Case

All extranet connections or network resource access must be accompanied by a valid business justification, in writing, that is approved by both the third party and the corresponding KDCC contracting authority or rightful designee. Typically this function is handled as part of the Third Party Agreement.

6.4 Point Of Contact

The KDCC contracting authority must designate a person to be the Point of Contact (POC) for the third party connection. The POC acts on behalf of the KDCC contracting authority, and is responsible for those portions of this policy and the “Third Party Agreement” that pertain to it. In the event that the POC changes, the relevant third party person or organization, must be informed promptly.

6.5 Establishing Connectivity

All contracting authorities within that wish to establish connectivity or network resource access to a third party are to file an Extranet connectivity request with IT Manager accompanied by a “Third Party Agreement” signed by the third party person, organization, or rightful designee.  IT Manager will then engage the third party to address security issues inherent in the project. The sponsoring contract authority must provide full and complete information as to the nature of the proposed access to IT Manager, as requested. All connectivity established must be based on the least-access principle, in accordance with the approved business requirements and the security review. All connectivity requests will have a specific beginning and ending date.  In no case will rely upon the third party to protect network or resources.  IT Manager will grant access to all approved resources and reserves the right to refuse access on the basis of legitimate security concern as decided by the CISO.

6.6 Modifying or Changing Connectivity and Access

All changes in access must be accompanied by a valid business justification, and are subject to security review.  The sponsoring contracting authority is responsible for notifying the third party person or organization and IT Manager when there is a material change in their originally provided information so that security and connectivity evolve accordingly.  Extensions will be granted on a case by case basis and must be requested in writing by the sponsoring contracting authority.

6.7 Terminating Access

When access is no longer required, the sponsoring contracting authority within XXX must notify the IT Manager, who will then terminate the access. This may mean a modification of existing permissions up to terminating the circuit, as appropriate. IT security teams must conduct an audit of their respective connections on an annual basis to ensure that all existing connections are still needed, and that the access provided meets the needs of the connection. Connections that are found to be deprecated, and/or are no longer being used to conduct business or other approved business transactions will be terminated immediately. Should a security incident or a finding that a circuit has been deprecated and is no longer being used to conduct business or other approved business transactions necessitate a modification of existing permissions, or termination of connectivity, IT Manager will notify the POC of the sponsoring contracting authority of the change prior to taking any action.

7 Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy.

Back to Trace International

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Information Security Operations Management Procedure

A. Operational Procedures and Responsibilities

1. Documented Operating Procedures

1.1 Operating procedures and responsibilities for information systems must be authorised, documented and maintained.
1.2 Information Owners and System Owners must ensure that Standard Operating Procedures (SOP) and standards are:

  1. documented;
  2. approved by the appropriate authority;
  3. consistent with University policies;
  4. reviewed and updated periodically;
  5. reviewed and updated when there are changes to equipment/systems or changes in business services and the supporting information systems operations; and
  6. reviewed and updated following a related security incident investigation.

1.3 The documentation must contain detailed instructions regarding:

  1. information processing and handling;
  2. system restart and recovery procedures;
  3. backup and recovery including on-site and off-site storage;
  4. exceptions handling, including a log of exceptions;
  5. output and media handling, including secure disposal or destruction;
  6. Management of audit and system log information;
  7. change management including scheduled maintenance and interdependencies;
  8. computer room management and safety;
  9. Information Incident Management Process;
  10. Disaster Recovery;
  11. Business Continuity Plan; and
  12. contact information for operations, technical, emergency and business personnel.

2. Change Management

2.1 Changes to business processes and information systems that affect information security must be controlled.
2.2 All changes to the Organization’s ICT services and systems environment, including provisioning and de-provisioning of assets, promotion of code, configuration changes and changes to Standard Operating Procedures must be authorised by the IT Change Advisory Board (CAB).
2.3 The change management process must follow the guidelines, approvals and templates provided as per the Transition Process.
2.4 Changes must be controlled by:

  1. identifying and recording significant changes;
  2. assessing the potential impact, including that on security, of the changes;
  3. obtaining approval of changes from those responsible for the information system;
  4. planning and testing changes including the documentation of rollback procedures;
  5. communicating change details to relevant personnel, Users and stakeholders; and
  6. evaluating that planned changes were implemented as intended.

2.5 Information Owners and System Owners must plan for changes by:

  1. assessing the potential impact of the proposed change on security by conducting a security review and a Threat and Risk Assessment;
  2. identifying the impact on agreements with business partners and external parties including information sharing agreements, licensing and provision of services;
  3. preparing change implementation plans that include testing and contingency plans in the event of problems;
  4. obtaining approvals from affected Information Owners; and
  5. training techniques of operational staff as necessary;

2.6 Information Owners and System Owners must implement changes by:

  1. notifying affected internal parties, business partners and external parties;
  2. following the documented implementation plans;
  3. training users if necessary;
  4. documenting the process throughout the testing and implementation phases; and
  5. confirming the changes have been performed and no unintended changes took place

3. Capacity Management

3.1 The use of information system resources must be monitored and optimised with projections made of future capacity requirements.
3.2 Information Owners and System Owners are responsible for implementing capacity management processes by:

  1. documenting capacity requirements and capacity planning processes;
  2. including capacity requirements in service agreements; and
  3. monitoring and optimising information systems to detect impending capacity limit.

3.3 Information Owners and System Owners must project future capacity requirements based on:

  1. new business and information systems requirements;
  2. statistical or historical capacity requirements; and
  3. current and expected trends in information processing capabilities (e.g. the introduction of more efficient hardware or software).

3.4 Information Owners and System Owners must use trend information from the capacity management process to identify and remediate potential bottlenecks that present a threat to system security or services

4. Separation of Development, Testing and Production Environments

4.1 Development, testing and production environments must be separated to reduce the risks of unauthorised access or changes to the production environment.
4.2 Information Owners and System Owners must:

  1. separate production environments from test and development environments by using different servers, networks and where possible different domains;
  2. ensure that production servers do not host test or development services or applications;
  3. prevent the use of test and development identities as credentials for production systems;
  4. store source code in a secure location away from the production environment and restrict access to specified personnel;
  5. prevent access to compilers, editors and other tools from production systems;
  6. use approved change management processes for promoting software from development/test to production;
  7. prohibit the use of production data in development, test or training systems; and
  8. prohibit the use of sensitive information in development, test or training systems in accordance with the System Acquisition, Development and Maintenance Procedure

B. Protection from Malware

1. Controls Against Malicious Code

1.1 Detection, prevention and recovery controls – supported by user awareness procedures – must be implemented to protect against malware.
1.2 Information Owners and System Owners must protect University information systems from malicious code by:

  1. installing, updating and using software designed to scan, detect, isolate and delete malicious code;
  2. preventing unauthorised Users from disabling installed security controls;
  3. prohibiting the use of unauthorised software;
  4. checking files, email attachments and file downloads for malicious code before use;
  5. maintaining business continuity plans to recover from malicious code incidents;
  6. maintain a critical incident management plan to identify and respond to malicious code incidents;
  7. maintaining a register of specific malicious code countermeasures (e.g. blocked websites, blocked file extensions, blocked network ports) including a description, rationale, approval authority and the date applied; and
  8. developing user awareness programs for malicious code countermeasures.

1.3 The IT Security staff are responsible for communicating technical advice and providing information and awareness activities regarding malicious code

C. Backup

1. Information Backup

1.1 Backup copies of information, software and system images must be made, secured, and be available for recovery.
1.2 Information Owners and System Owners must define and document backup and recovery processes that consider the confidentiality, integrity and availability requirements of information and information systems.
1.3 Backup and recovery processes must comply with:

  1. University business continuity plans (if applicable);
  2. policy, legislative, regulatory and other obligations; and
  3. records management requirements (refer Records Management Policy).

1.4 The documentation for backup and recovery must include:

  1. types of information to be backed up;
  2. schedules for the backup of information and information systems;
  3. backup media management;
  4. methods for performing, validating and labelling backups; and
  5. methods for validating the recovery of information and information systems.

1.5 Backup media and facilities must be appropriately secure based on a security review or Risk Assessment. Controls to be applied include:

  1. use approved encryption;
  2. physical security;
  3. access controls;
  4. methods of transit to and from off-site locations;
  5. appropriate environmental conditions while in storage; and
  6. off-site locations must be at a sufficient distance to escape damage from an event at the main site principles

D. Log Management

1. Event Logging

1.1 Event logs recording user activities, exceptions, faults and information security events must be produced, kept and regularly reviewed.
1.2 Information Owners must ensure that event logs are used to record user and system activities, exceptions and events (security and operational). The degree of detail to be logged must be based on the value and sensitivity of the information and the criticality of the system. The resources required to analyse the logs must also be considered. Where applicable, event logs must include:

  1. user ID;
  2. system activities;
  3. dates, times and details of key events (e.g. login, logoff);
  4. device identity and location;
  5. login method;
  6. records of successful and unsuccessful system access attempts;
  7. records of successful and unsuccessful data and other resource access attempts;
  8. changes to system configuration;
  9. use of elevated privileges;
  10. use of system utilities and applications;
  11. network addresses and protocols;
  12. alarms raised by the access control system;
  13. activation and de-activation of protection systems (e.g. anti-virus, intrusion detection); and
  14. records of transactions executed by users in applications.

1.3 Event logs may contain sensitive information and therefore must be safeguarded in accordance with the requirements of the section on the Protection of Log Information.
1.4 System administrators must not have the ability to modify, erase or de-activate logs of their own activities.
1.5 If event logging is disabled the decision must be documented. Include the name and position of the approver, date and rationale for de-activating the log.
1.6 Event logs may be configured to alert someone if certain events or signatures are detected. Information Owners and System Owners must establish and document alarm response procedures to ensure they are responded to immediately and consistently. Normally, response to an alarm will include:

  1. identification of the event;
  2. isolation of the event and affected assets;
  3. identification and isolation of the source;
  4. corrective action;
  5. forensic analysis;
  6. action to prevent recurrence; and
  7. securing event logs as evidence

2. Protection of Log Information

2.1 Information system logging facilities and log information must be protected against tampering and unauthorised access.
2.2 Information Owners must implement controls to protect logging facilities and log files from unauthorised modification, access or destruction. Controls must include:

  1. physical security safeguards;
  2. permission for administrators and operators to erase or de-activate logs;
  3. multifactor authentication for access to highly-restricted records;
  4. backup of audit logs to off-site facilities;
  5. automatic archiving of logs to remain within storage capacity; and
  6. scheduling the audit logs as part of the records management process.

2.3 Event logs must be retained in accordance with the records retention schedule for the information system.
2.4 System logs for University critical IT infrastructure (P1 list) must be retained for at least 30 days online and archived for 90 days.
2.5 Datacentre physical access logs must be made available for at least 90 days and CCTV records must be retained for at least 30 days.
2.6 Logs must be retained indefinitely if an investigation has commenced or it is known that evidence may be obtained from them

3. Administrator and Operator Logs

3.1 Activities of privileged users must be logged and the log subject to regular independent review.
3.2 The activities of system administrators, operators and other privileged users must be logged including:

  1. the time an event (e.g. success or failure) occurred;
  2. event details including files accessed, modified or deleted, errors and corrective action is taken;
  3. the account and the identity of the privileged user involved; and
  4. the systems processes involved.

3.3 Logs of the activities of privileged users must be checked by the Information Owner or delegate. Checks must be conducted regularly and randomly. The frequency must be determined by the value and sensitivity of the information and criticality of the system. Following verification of the logs, they must be archived in accordance with the applicable records retention schedule.

4. Clock Synchronisation

4.1 Computer clocks must be synchronised for accurate recording.
4.2 System administrators must synchronise information system clocks to the local router gateway or a University-approved host.
4.3 System administrators must confirm system clock synchronisation following power outages and as part of the incident analysis and event log review

E. Control of Operational Software

1. Installation of Software on Production Systems

1.1 The installation of software on production information systems must be controlled.
1.2 To minimise the risk of damage to production systems Information Owners must implement the following procedures when installing software:

  1. updates of production systems must be planned, approved, assessed for impacts, tested and logged;
  2. a Change and Release Coordinator must be appointed to coordinate the install and update of software, applications and program libraries;
  3. operations personnel and end users must be notified of the changes, potential impacts and, if required, given additional training;
  4. production systems must not contain development code or compilers;
  5. user acceptance testing must be extensively and successfully conducted on a separate system prior to production implementation;
  6. a rollback strategy must be in place and previous versions of application software retained;
  7. old software versions must be archived with configuration details and system documentation; and
  8. updates to program libraries must be logged

F. Vulnerability Management

1. Management of Technical Vulnerabilities

1.1 Regular assessments must be conducted to evaluate information system vulnerabilities and the management of associated risk.
1.2 To support technical vulnerability management, Information Owners and System Owners must maintain an inventory of information assets in accordance with the Information Security Asset Management Procedure. Specific information must be recorded including:

  1. the software vendor;
  2. version numbers;
  3. the current state of deployment; and
  4. the person(s) responsible for the system.

1.3 Vulnerabilities which impact the information systems must be addressed in a timely manner to mitigate or minimise the impact on the operations. The IT Security Team shall ensure that vulnerability assessments (VA) are conducted for the organization’s ICT services and systems on a regular basis.
1.4 Vulnerability remediation efforts, including patch implementations, shall be coordinated and processed according to the Patch Management Procedure and Risk Management Framework.
1.5 All internal and external organization ICT systems and resources are covered in this Procedure:
(a) Internal Vulnerability Assessments

  1. Servers used for internal hosting and supporting Infrastructure
  2. Servers which will be accessed through the reverse proxy
  3. Research specific servers and applications
  4. Research devices and systems
  5. Desktops and workstations

(b) External Vulnerability Assessments

  1. Perimeter network devices exposed to the internet
  2. All external facing servers and services
  3. Network appliances, streaming devices and essential IP assets that are internet facing.
  4. Public-facing research applications and devices
  5. Cloud-based services

2. Vulnerability Management Cycle

2.1 Asset Discovery

  1. Asset Discovery scan will be executed on a monthly basis or quarterly on the segments to determine the live assets connected to the network.
  2. The network team will share the IP segments of all assets within the University including Datacentres and other Virtual LANs with the IT Security Team.
  3. IT Security Team will perform an asset discovery scan on the segments.
  4. Any assets added or removed from the segment will be detected in the asset discovery scan.
  5. IT Security Team will share with the Network team the addition/removal of servers/devices for reconfirmation based on the discovery scan.
  6. The final list of IP/IP Segments will be scanned for Vulnerabilities

2.2 Scan – Remediate – Rescan

  1. IT Security team shall perform Vulnerability Analysis Scan on all University Critical Infrastructure Servers on a monthly basis and non-critical assets on at least a quarterly basis.
  2. IT Security Team will perform a risk assessment to map the risk, threat, likelihood and impact rating for the vulnerabilities noted.
  3. The University Risk Management Framework shall be followed to perform the risk assessment.
  4. IT Security Team shall inform the System Owners regarding the results of the scans and share the vulnerability reports with the Responsible Administrators for each system.
  5. All vulnerabilities identified in the VA Scan shall be remediated by according to the Remediation timeline.
  6. The System Owners shall inform IT Security Team regarding the completion of vulnerability remediation.
  7. Vulnerabilities that cannot be actioned within the defined timeframe will need an exception approved.

2.3 Ad-Hoc Scans

Ad-hoc scans include scans on any new infrastructure devices/servers/services prior to production deployment as per the following process.

  1. New service owners shall complete a Service Desk request ticket and submit to the IT Security Team for action.
  2. The IT Security Team shall perform Vulnerability Analysis Scan of specific systems (including servers) as per the environment and technology used for the system.
  3.  VA report shall be submitted to the Business owner and respective System Owner or team.
  4. IT Security Team lead will validate with respective System Owners on the closure of all the vulnerabilities and then perform a rescan.
  5. Vulnerabilities that cannot be actioned within the defined timeframe will need an exception approved, with risk acceptance and compensating controls implemented and documented.
  6. Assets/ services/devices can be released to production only after the final sign off by IT Security Team

3. Classification of Vulnerabilities

3.1 Vulnerabilities are classified based on their impact in a given environment, to data/information or to the University’s reputation Rating

Rating Red Hat,  Microsoft, Adobe
Rating
Typical CVSS
Score
Description
Critical Critical 10 A vulnerability whose exploitation could allow code execution or complete system compromise without user interaction. These scenarios include self-propagating malware or unavoidable common use scenarios where code execution occurs without warnings or prompts. This could include browsing to a web page or opening an email or no action at all.
High Important 7.0 – 9.9 A vulnerability whose exploitation could result in the compromise of the confidentiality, integrity, or availability of user data, or of the integrity or availability of processing resources. This includes common use scenarios where a system is compromised with warnings or prompts, regardless of their provenance, quality, or usability. Sequences of user actions that do not generate prompts or warnings are also covered.
Medium Moderate 4.0 – 6.9 The impact of the vulnerability is mitigated to a significant degree by factors such as authentication requirements or applicability only to non-default configurations. The vulnerability is normally difficult to exploit.
Low Low < 4.0 This classification applies to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.

4. Remediation Timeline and Risk Acceptance

4.1 All vulnerabilities identified in a VA Scan shall be addressed within the timeline described below. If any particular vulnerability cannot be remediated within this timeframe, the risk of data loss/attack on the device should be formally documented and accepted by the respective groups in the below table. Remediation time and risk acceptance for the identified vulnerabilities shall be as follows:

Vulnerability Level

Remediation Timelines

Risk Acceptance

External Facing Devices

Internal Devices

Critical 1 Week 1 Week CIO or Risk Management Office
High 2 Weeks 2 Weeks CIO
Medium 3 Weeks Next Maintenance Window Information Owner
Low Next Maintenance Window Next Maintenance Window Information Owner

5. Third-Party Scans

5.1 A third party must be engaged annually to perform vulnerability assessment & penetration testing covering all internet-facing organization ICT services and systems and critical internal non-internet facing ICT services and systems.

6. Vulnerability Management Roles and Responsibilities

6.1 IT Security Team

  1. Perform asset discovery and performing Vulnerability Management Process
  2. Approve the Vulnerability Assessment Schedule
  3. Oversee vulnerability remediation.
  4. Targeting vulnerability program maturity through metrics development
  5. Monitor security sources for vulnerability announcements and emerging threats that correspond to the system inventory.

6.2 System Owners

  1. Responsible for implementing remediating actions defined as a result of detected vulnerabilities.
  2. testing and evaluating options to mitigate or minimize the impact of vulnerabilities;
  3. applying corrective measures to address the vulnerabilities, and
  4. reporting to the IT Security Team on progress in responding to vulnerabilities

6.3 Depending on how urgently a technical vulnerability needs to be addressed, the action taken should be carried out according to the change management controls or by following the Information Security Incident Management Guidelines.
6.4 Responsibilities for vulnerability response must be included in service agreements with suppliers.

7. Restrictions on Software Installation

7.1 Rules governing the installation of software by users must be established and implemented.
7.2 Users are not allowed to install software on University devices unless specifically authorized by a System Owner or a system administrator. System Owners are responsible for the installation of software, updates, and patches.

H. Information Security Audit Considerations

1. Information Systems Audit Controls

1.1 Audit requirements and activities involving checks on production systems must be planned and approved to minimize disruption to business processes.
1.2 Prior to commencing compliance checking activities such as audits or security reviews of production systems the CIO, and the Information Owner must define, document and approve the activities. Among the items upon which they must agree are:

  1. the audit requirements and scope of the checks;
  2. audit personnel must be independent of the activities being audited;
  3. the checks must be limited to read-only access to software and data, except for isolated copies of system files, which must be erased or given appropriate protection if required when the audit is complete;
  4. the resources performing the checks must be explicitly identified;
  5. existing security metrics will be used where possible;
  6. all access must be monitored and logged and all procedures, requirements and responsibilities must be documented;
  7. audit tests that could affect system availability must be run outside business hours; and
  8. appropriate personnel must be notified in advance in order to be able to respond to any incidents resulting from the audit.

 

Example of Capacity Management procedure

Capacity Management is the continuous and iterative process that monitors, analyses and evaluates the performance and capacity of the IT infrastructure and, with the data obtained, it optimizes the service or submits an RFC to Change Management. All the information obtained in these activities, and that generated by Capacity Management using that information, is stored and recorded in the Capacity Database (CDB) available with the IT Manager.

1

  1. Monitoring

The main objective is to ensure that the performance of the IT infrastructure matches the requirements of the SLAs. As well as technical aspects, monitoring needs to include details of licences and other administrative information.

2. Analysis and Evaluation

The data collected needs to be analyzed to assess whether corrective action needs to be taken, such as requesting an increase in capacity or better Demand Management.

3. Optimization and changes

If it is decided that capacity needs to be increased, an RFC will be raised and sent to Change Management to set in train the whole process involved in implementing the change. Capacity Management will lend its support throughout the process and it will be jointly responsible, together with Change Management and Release Management for ensuring that the change requested meets the envisaged objectives. In the case where a simple rationalization of demand will be enough to resolve the deficiencies or non-compliances with SLAs, Capacity Management itself will be responsible for managing this sub-process.

4. Capacity Database

The CDB must cover all the business, financial, technical and service information received and generated by Capacity Management in relation to the capacity of the infrastructure and its elements. Ideally, the CDB must be interrelated with the CMDB so that the CMDB is able to give a complete image of the systems and applications and includes all the information about their capacity. However, this does not mean that the two databases cannot be “physically independent”.

Back to Trace International

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.