Module 04 Course Project - Comprehensive Security Plan

1.0 Purpose

The purpose is to implement policies and procedures to ensure that physical access controls exist that ensure that all cardholder data can only be accessed by authorized personnel.

2.0 Scope

This policy applies to all <company name> employees, contractors, consultants, and temps who utilize <company name> IT resources described herein their assigned job responsibilities.

3.0 Policy

3.1 Facility Access

1. Facility entry controls will be implemented to limit and monitor physical access to systems that process or transmit cardholder data.

2. Physical access to publicly accessible network jacks, wireless access points, gateways, and handheld devices will be restricted.

3.2 Visitors

1. Procedures will exist to help personnel to easily distinguish between employees and visitors in areas where cardholder data is accessible.

2. All visitors will be authorized before entering areas where cardholder data is processed or maintained.

3. All visitors will be given a token, such as a badge or access device, which identifies them as non-employees, and will be required to surrender the device before leaving the facility or on the data of expiration.

4. All visitors to sensitive area must complete a visitor’s log which will be maintained for a minimum of three months, unless otherwise restricted by law.

3.3 Media Controls

1. All media back-ups will be stored in a secure location, preferably in an offsite facility, such as an alternate or backup site, or a commercial storage facility.

2. All paper and electronic media (including computers, networking and communications hardware, telecommunication lines, paper receipts, paper reports, and faxes) that contain cardholder data will be physically secured.

3. Strict control will be maintained over the internal and external distribution of any kind of media that contains cardholder data, such that the media is identified as confidential, and will only be sent by secured and traceable courier.

4. Management will approve in advance any and all media being moved from a secured area.

5. Strict control will be maintained over the storage and accessibility of media that contains cardholder data such that it is inventoried securely stored, and protected by a password.

6. Media containing cardholder data will be destroyed when it is no longer needed for business or legal reasons. The means of destruction will be cross-cut shred, incineration or pulping of hardcopy materials. Electronic data will be destroyed using a method (purge, degauss, or shred) which ensures that cardholder data cannot be reconstructed.

3.4 Individual Access

1. All systems and applications which store critical information will require a unique user name for all users.

2. All unique user names will require a password, token device, or biometrics to authenticate the user.

4.0 Enforcement

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

5.0 Definitions

Term Definition

N/A

6.0 References

7.0 Revision History

Initial effective date:

Acceptable Encryption Policy

1.0 Purpose

The purpose of this policy is to provide guidance that limits the use of encryption to those algorithms that have received substantial public review and have been proven to work effectively. Additionally, this policy provides direction to ensure that Federal regulations are followed, and legal authority is granted for the dissemination and use of encryption technologies outside of the United States.

2.0 Scope

This policy applies to all <Company Name> employees and affiliates.

3.0 Policy

Proven, standard algorithms such as DES, Blowfish, RSA, RC5 and IDEA should be used as the basis for encryption technologies. These algorithms represent the actual cipher used for an approved application. For example, Network Associate's Pretty Good Privacy (PGP) uses a combination of IDEA and RSA or Diffie-Hellman, while Secure Socket Layer (SSL) uses RSA encryption. Symmetric cryptosystem key lengths must be at least 56 bits. Asymmetric crypto-system keys must be of a length that yields equivalent strength. <Company Name>’s key length requirements will be reviewed annually and upgraded as technology allows.

The use of proprietary encryption algorithms is not allowed for any purpose, unless reviewed by qualified experts outside of the vendor in question and approved by InfoSec. Be aware that the export of encryption technologies is restricted by the U.S. Government. Residents of countries other than the United States should make themselves aware of the encryption technology laws of the country in which they reside.

4.0 Enforcement

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

5.0 Definitions

Term Definition

Proprietary Encryption An algorithm that has not been made public and/or has not withstood public scrutiny. The developer of the algorithm could be a vendor, an individual, or the government.

Symmetric Cryptosystem A method of encryption in which the same key is used for both encryption and decryption of the data.

Asymmetric Cryptosystem A method of encryption in which two different keys are used: one for encrypting and one for decrypting the data (e.g., public-key encryption).

6.0 Revision History

Audit Vulnerability Scan Policy

1.0 Purpose

The purpose of this agreement is to set forth our agreement regarding network security scanning offered by the <Internal or External Audit Name> to the <Company Name>. <Internal or External Audit Name> shall utilize <Approved Name of Software> to perform electronic scans of Client’s networks and/or firewalls or on any system at <Company Name>.

Audits may be conducted to:

· Ensure integrity, confidentiality and availability of information and resources

· Investigate possible security incidents ensure conformance to <Company Name> security policies

· Monitor user or system activity where appropriate.

2.0 Scope

This policy covers all computer and communication devices owned or operated by <Company Name>. This policy also covers any computer and communications device that are present on <Company Name> premises, but which may not be owned or operated by <Company Name>. The <Internal or External Audit Name> will not perform Denial of Service activities.

3.0 Policy

When requested, and for the purpose of performing an audit, consent to access needed will be provided to members of <Internal or External Audit Name>. <Company Name> hereby provides its consent to allow of <Internal or External Audit Name> to access its networks and/or firewalls to the extent necessary to allow [Audit organization] to perform the scans authorized in this agreement. <Company Name> shall provide protocols, addressing information, and network connections sufficient for <Internal or External Audit Name> to utilize the software to perform network scanning.

This access may include:

· User level and/or system level access to any computing or communications device

· Access to information (electronic, hardcopy, etc.) that may be produced, transmitted or stored on <Company Name> equipment or premises

· Access to work areas (labs, offices, cubicles, storage areas, etc.)

· Access to interactively monitor and log traffic on <Company Name> networks.

3.1 Network Control.

If Client does not control their network and/or Internet service is provided via a

second or third party, these parties are required to approve scanning in writing if scanning is to occur outside of the <Company Name’s> LAN. By signing this agreement, all involved parties acknowledge that they authorize of <Internal or External Audit Name> to use their service networks as a gateway for the conduct of these tests during the dates and times specified.

3.2 Service Degradation and/or Interruption. Network performance and/or availability may be affected by the network scanning. <Company Name> releases <Internal or External Audit Name> of any and all liability for damages that may arise from network availability restrictions caused by the network scanning,

unless such damages are the result <Internal or External Audit Name> gross negligence or intentional

misconduct.

3.3 Client Point of Contact During the Scanning Period. <Company Name> shall identify in writing a person to be available if the result <Internal or External Audit Name> Scanning Team has questions regarding data discovered or requires assistance.

3.4 Scanning period. <Company Name> and <Internal or External Audit Name> Scanning Team shall identify in writing the allowable dates for the scan to take place.

4.0 Enforcement

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

5.0 Revision History

1.0 Purpose

2.0 Scope

This policy covers appropriate use of any email sent from a <COMPANY NAME> email address and applies to all employees, vendors, and agents operating on behalf of <COMPANY NAME>.

3.0 Policy

3.1 Prohibited Use. The <COMPANY NAME> email system shall not to be used for the creation or distribution of any disruptive or offensive messages, including offensive comments about race, gender, hair color, disabilities, age, sexual orientation, pornography, religious beliefs and practice, political beliefs, or national origin. Employees who receive any emails with this content from any <COMPANY NAME> employee should report the matter to their supervisor immediately.

3.2 Personal Use.

Using a reasonable amount of <COMPANY NAME> resources for personal emails is acceptable, but non-work related email shall be saved in a separate folder from work related email. Sending chain letters or joke emails from a <COMPANY NAME> email account is prohibited. Virus or other malware warnings and mass mailings from <COMPANY NAME> shall be approved by <COMPANY NAME> VP Operations before sending. These restrictions also apply to the forwarding of mail received by a <COMPANY NAME> employee.

3.3 Monitoring

<COMPANY NAME> employees shall have no expectation of privacy in anything they store, send or receive on the company’s email system. <COMPANY NAME> may monitor messages without prior notice. <COMPANY NAME> is not obliged to monitor email messages.

4.0 Enforcement

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

5.0 Definitions

Term Definition

Email The electronic transmission of information through a mail protocol such as SMTP or IMAP. Typical email clients include Eudora and Microsoft Outlook.

Forwarded email Email resent from an internal network to an outside point.

Chain email or letter Email sent to successive people. Typically the body of the note has direction to send out multiple copies of the note and promises good luck or money if the direction is followed.

Sensitive information Information is considered sensitive if it can be damaging to <COMPANY NAME> or its customers' reputation or market standing.

Virus warning. Email containing warnings about virus or malware. The overwhelming majority of these emails turn out to be a hoax and contain bogus information usually intent only on frightening or misleading users.

Unauthorized Disclosure The intentional or unintentional revealing of restricted information to people, both inside and outside <COMPANY NAME>, who do not have a need to know that information.

6.0 Revision History

Remote Access

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2006 All Ri

Removable Media

1.0 Overview

Removable media is a well-known source of malware infections and has

been directly tied to the loss of sensitive information in many

organizations.

2.0 Purpose

To minimize the risk of loss or exposure of sensitive information

maintained by <Company Name> and to reduce the risk of acquiring malware

infections on computers operated by <Company Name>.

3.0 Scope

This policy covers all computers and servers operating in <company

name>.

4.0 Policy

<Company Name> staff may only use <Company Name> removable media in

their work computers. <Company Name>removable media may not be

connected to or used in computers that are not owned or leased by the

<Company Name> without explicit permission of the <Company Name> info

sec staff. Sensitive information should be stored on removable media

only when required in the performance of your assigned duties or when

providing information required by other state or federal agencies. When

sensitive information is stored on removable media, it must be

encrypted in accordance with the <Company Name> Acceptable Encryption Policy.

5.0 Enforcement

Any employee found to have violated this policy may be subject to

disciplinary action, up to and including

termination of employment.

6.0 Definitions

Removable Media: Device or media that is readable and/or writeable by

the end user and is able to be moved from computer to computer without

modification to the computer. This includes flash memory devices such

as thumb drives, cameras, MP3 players and PDAs; removable hard drives

(including hard drive-based MP3 players); optical disks such as CD and

DVD disks; floppy disks and any commercial music and software disks not

provided by <Company Name>.

Encryption: A procedure used to convert data from its original form to

a format that is unreadable and/or unusable to anyone without the

tools/information needed to reverse the encryption process.

Sensitive Information: Information which, if made available to

unauthorized persons, may adversely affect <Company Name>, its programs,

or participants served by its programs. Examples include, but are not

limited to, personal identifiers and , financial information,

Malware: Software of malicious intent/impact such as viruses, worms,

and Spyware.

7.0 Revision History

Original Issue Date:

Deliverable 3: Disaster Recovery Plan

Mandatory

This Disaster Recovery Plan (DRP) captures, in a single repository, all of the information that describes <<Organization’s Name>> ability to withstand a disaster as well as the processes that must be followed to achieve disaster recovery.

This section should be completed by all organizations. It helps position the DRP, detailing what is included in the plan and what areas are addressed. Edit this section to suit your organization’s needs, lists and paragraphs should be made relevant to your organization.

Elective

A disaster can be caused by man or nature and results in <<Organization Name>> IT department not being able to perform all or some of their regular roles and responsibilities for a period of time. <<Organization Name>> defines disasters as the following:

· Edit this list to reflect your organization

· One or more vital systems are non-functional

· The building is not available for an extended period of time but all systems are functional within it

· The building is available but all systems are non-functional

· The building and all systems are non functional

The following events can result in a disaster, requiring this Disaster Recovery document to be activated:

· Edit this list to reflect your organization

· Fire

· Flash flood

· Pandemic

· Power Outage

· War

· Theft

· Terrorist Attack

Mandatory

The purpose of this DRP document is twofold: first to capture all of the information relevant to the enterprise’s ability to withstand a disaster, and second to document the steps that the enterprise will follow if a disaster occurs.

Note that in the event of a disaster the first priority of <<Organization Name>> is to prevent the loss of life. Before any secondary measures are undertaken, <<Organization Name>> will ensure that all employees, and any other individuals on the organization’s premises, are safe and secure.

After all individuals have been brought to safety, the next goal of <<Organization Name>> will be to enact the steps outlined in this DRP to bring all of the organization’s groups and departments back to business-as-usual as quickly as possible. This includes:

· Edit this list to reflect your organization

· Preventing the loss of the organization’s resources such as hardware, data and physical IT assets

· Minimizing downtime related to IT

· Keeping the business running in the event of a disaster

This DRP document will also detail how this document is to be maintained and tested.

Mandatory

The <<Organization Name>> DRP takes all of the following areas into consideration:

· Edit this list to reflect your organization

· Network Infrastructure

· Servers Infrastructure

· Telephony System

· Data Storage and Backup Systems

· Data Output Devices

· End-user Computers

· Organizational Software Systems

· Database Systems

· IT Documentation

This DRP does not take into consideration any non-IT, personnel, Human Resources and real estate related disasters. For any disasters that are not addressed in this document, please refer to the business continuity plan created by <<Organization Name>> or contact <<Business Continuity Lead>> at <<Business Continuity Lead Contact Information>>.

Mandatory

Any changes, edits and updates made to the DRP will be recorded in here. It is the responsibility of the Disaster Recovery Lead to ensure that all existing copies of the DRP are up to date. Whenever there is an update to the DRP, <<Organization Name>> requires that the version number be updated to indicate this.

Add rows as required as the DR Plan is amended.

Mandatory

In the event of a disaster, different groups will be required to assist the IT department in their effort to restore normal functionality to the employees of <<Organization Name>>. The different groups and their responsibilities are as follows:

· Edit this list to reflect your organization

· Disaster Recovery Lead(s)

· Disaster Management Team

· Facilities Team

· Network Team

· Server Team

· Applications Team

· Operations Team

· Management Team

· Communications Team

· Finance Team

The lists of roles and responsibilities in this section have been created by <<Organization Name>> and reflect the likely tasks that team members will have to perform. Disaster Recovery Team members will be responsible for performing all of the tasks below. In some disaster situations, Disaster Recovery Team members will be called upon to perform tasks not described in this section.

Please note that the following teams will vary depending on the size of your organization. Some teams/roles may be combined or may be split into more than one team.

Mandatory

The Disaster Recovery Lead is responsible for making all decisions related to the Disaster Recovery efforts. This person’s primary role will be to guide the disaster recovery process and all other individuals involved in the disaster recovery process will report to this person in the event that a disaster occurs at <<Organization Name>>, regardless of their department and existing managers. All efforts will be made to ensure that this person be separate from the rest of the disaster management teams to keep his/her decisions unbiased; the Disaster Recovery Lead will not be a member of other Disaster Recovery groups in <<Organization Name>>.

· Edit this list to reflect your organization

· Make the determination that a disaster has occurred and trigger the DRP and related processes.

· Initiate the DR Call Tree.

· Be the single point of contact for and oversee all of the DR Teams.

· Organize and chair regular meetings of the DR Team leads throughout the disaster.

· Present to the Management Team on the state of the disaster and the decisions that need to be made.

· Organize, supervise and manage all DRP test and author all DRP updates.

Add or delete rows to reflect the size the Disaster Recovery Team in your organization.

Elective

The Disaster Management Team that will oversee the entire disaster recovery process. They will be the first team that will need to take action in the event of a disaster. This team will evaluate the disaster and will determine what steps need to be taken to get the organization back to business as usual.

Please note than in a small organization, these roles may be performed by the Disaster Recovery Lead.

· Edit this list to reflect your organization

· Set the DRP into motion after the Disaster Recovery Lead has declared a disaster

· Determine the magnitude and class of the disaster

· Determine what systems and processes have been affected by the disaster

· Communicate the disaster to the other disaster recovery teams

· Determine what first steps need to be taken by the disaster recovery teams

· Keep the disaster recovery teams on track with pre-determined expectations and goals

· Keep a record of money spent during the disaster recovery process

· Ensure that all decisions made abide by the DRP and policies set by <<Organization Name>>

· Get the secondary site ready to restore business operations

· Ensure that the secondary site is fully functional and secure

· Create a detailed report of all the steps undertaken in the disaster recovery process

· Notify the relevant parties once the disaster is over and normal business functionality has been restored

· After <<Organization Name>> is back to business as usual, this team will be required to summarize any and all costs and will provide a report to the Disaster Recovery Lead summarizing their activities during the disaster

Add or delete rows to reflect the size the Disaster Management Team in your organization.

Mandatory

The Network Team will be responsible for assessing damage specific to any network infrastructure and for provisioning data and voice network connectivity including WAN, LAN, and any telephony connections internally within the enterprise as well as telephony and data connections with the outside world. They will be primarily responsible for providing baseline network functionality and may assist other IT DR Teams as required.

Role & Responsibilities

· Edit this list to reflect your organization

· In the event of a disaster that does not require migration to standby facilities, the team will determine which network services are not functioning at the primary facility

· If multiple network services are impacted, the team will prioritize the recovery of services in the manner and order that has the least business impact.

· If network services are provided by third parties, the team will communicate and co-ordinate with these third parties to ensure recovery of connectivity.

· In the event of a disaster that does require migration to standby facilities the team will ensure that all network services are brought online at the secondary facility

· Once critical systems have been provided with connectivity, employees will be provided with connectivity in the following order:

· All members of the DR Teams

· All C-level and Executive Staff

· All IT employees

· All remaining employees

· Install and implement any tools, hardware, software and systems required in the standby facility

· Install and implement any tools, hardware, software and systems required in the primary facility

· After <<Organization Name>> is back to business as usual, this team will be summarize any and all costs and will provide a report to the Disaster Recovery Lead summarizing their activities during the disaster

Add or delete rows to reflect the size of the Network Team in your organization.

Mandatory

The Server Team will be responsible for providing the physical server infrastructure required for the enterprise to run its IT operations and applications in the event of and during a disaster. They will be primarily responsible for providing baseline server functionality and may assist other IT DR Teams as required.

Role & Responsibilities

· Edit this list to reflect your organization

· In the event of a disaster that does not require migration to standby facilities, the team will determine which servers are not functioning at the primary facility

· If multiple servers are impacted, the team will prioritize the recovery of servers in the manner and order that has the least business impact. Recovery will include the following tasks:

· Assess the damage to any servers

· Restart and refresh servers if necessary

· Ensure that secondary servers located in standby facilities are kept up-to-date with system patches

· Ensure that secondary servers located in standby facilities are kept up-to-date with application patches

· Ensure that secondary servers located in standby facilities are kept up-to-date with data copies

· Ensure that the secondary servers located in the standby facility are backed up appropriately

· Ensure that all of the servers in the standby facility abide by <<Organization Name>>’s server policy

· Install and implement any tools, hardware, and systems required in the primary facility

· After <<Organization Name>> is back to business as usual, this team will be summarize any and all costs and will provide a report to the Disaster Recovery Lead summarizing their activities during the disaster

Contact Information

Add or delete rows to reflect the size of the Server Team in your organization.

Mandatory

· Edit this list to reflect your organization

· In the event of a disaster that does not require migration to standby facilities, the team will determine which applications are not functioning at the primary facility

· If multiple applications are impacted, the team will prioritize the recovery of applications in the manner and order that has the least business impact. Recovery will include the following tasks:

· Assess the impact to application processes

· Restart applications as required

· Patch, recode or rewrite applications as required

· Ensure that secondary servers located in standby facilities are kept up-to-date with application patches

· Ensure that secondary servers located in standby facilities are kept up-to-date with data copies

· Install and implement any tools, software and patches required in the standby facility

· Install and implement any tools, software and patches required in the primary facility

· After <<Organization Name>> is back to business as usual, this team will be summarize any and all costs and will provide a report to the Disaster Recovery Lead summarizing their activities during the disaster

Contact Information

Add or delete rows to reflect the size of the Application Team in your organization.

Mandatory

This team’s primary goal will be to provide employees with the tools they need to perform their roles as quickly and efficiently as possible. They will need to provision all <<Organization Name>> employees in the standby facility and those working from home with the tools that their specific role requires.

Role & Responsibilities

· Edit this list to reflect your organization

· Maintain lists of all essential supplies that will be required in the event of a disaster

· Ensure that these supplies are provisioned appropriately in the event of a disaster

· Ensure sufficient spare computers and laptops are on hand so that work is not significantly disrupted in a disaster

· Ensure that spare computers and laptops have the required software and patches

· Ensure sufficient computer and laptop related supplies such as cables, wireless cards, laptop locks, mice, printers and docking stations are on hand so that work is not significantly disrupted in a disaster

· Ensure that all employees that require access to a computer/laptop and other related supplies are provisioned in an appropriate timeframe

· If insufficient computers/laptops or related supplies are not available the team will prioritize distribution in the manner and order that has the least business impact

· This team will be required to maintain a log of where all of the supplies and equipment were used

· After <<Organization Name>> is back to business as usual, this team will be required to summarize any and all costs and will provide a report to the Disaster Recovery Lead summarizing their activities during the disaster

Add or delete rows to reflect the size of the Operations Team in your organization.

Mandatory

The Senior Management Team will make any business decisions that are out of scope for the Disaster Recovery Lead. Decisions such as constructing a new data center, relocating the primary site etc. should be make by the Senior Management Team. The Disaster Recovery Lead will ultimately report to this team.

Role & Responsibilities

· Edit this list to reflect your organization

· Ensure that the Disaster Recovery Team Lead is help accountable for his/her role

· Assist the Disaster Recovery Team Lead in his/her role as required

· Make decisions that will impact the company. This can include decisions concerning:

· Rebuilding of the primary facilities

· Rebuilding of data centers

· Significant hardware and software investments and upgrades

· Other financial and business decisions

Add or delete rows to reflect the size of the Management Team in your organization.

Elective

This will be the team responsible for all communication during a disaster. Specifically, they will communicate with <<Organization Name>>’s employees, clients, vendors and suppliers, banks, and even the media if required.

Role & Responsibilities

· Edit this list to reflect your organization

· Communicate the occurrence of a disaster and the impact of that disaster to all <<Organization Name>>‘s employees

· Communicate the occurrence of a disaster and the impact of that disaster to authorities, as required

· Communicate the occurrence of a disaster and the impact of that disaster to all <<Organization Name>>‘s partners

· Communicate the occurrence of a disaster and the impact of that disaster to all <<Organization Name>>‘s clients

· Communicate the occurrence of a disaster and the impact of that disaster to all <<Organization Name>>‘s vendors

· Communicate the occurrence of a disaster and the impact of that disaster to media contacts, as required

· After <<Organization Name>> is back to business as usual, this team will be required to summarize any and all costs and will provide a report to the Disaster Recovery Lead summarizing their activities during the disaster

Add or delete rows to reflect the size of the Communications Team in your organization.

Mandatory

In a disaster recovery or business continuity emergency, time is of the essence so <<Organization Name>> will make use of a Call Tree to ensure that appropriate individuals are contacted in a timely manner.

· The Disaster Recovery Team Lead calls all Level 1 Members (Blue cells)

· Level 1 members call all Level 2 team members over whom they are responsible (Green cells)

· Level 1 members call all Level 3 team members over whom they are directly responsible (Beige cells)

· Level 2 Members call all Level 3 team members over whom they are responsible (Beige cells)

· In the event a team member is unavailable, the initial caller assumes responsibility for subsequent calls (i.e. if a Level 2 team member is inaccessible, the Level 1 team member directly contacts Level 3 team members).

Add as many levels as you need for your organization.

Mandatory

This section explains where all of the organization’s data resides as well as where it is backed up to. Use this information to locate and restore data in the event of a disaster.

In this section it is important to explain where the organization’s data resides. Discuss the location of all the organization’s servers, backups and offsite backups and list what information is stored on each of these.

Please list all of the data in your organization in order of their criticality. Add or delete rows as needed to the table below.

Mandatory

If a disaster occurs in <<Organization Name>>, the first priority is to ensure that all employees are safe and accounted for. After this, steps must be taken to mitigate any further damage to the facility and to reduce the impact of the disaster to the organization.

Regardless of the category that the disaster falls into, dealing with a disaster can be broken down into the following steps:

· Edit this list to reflect your organization

1) Disaster identification and declaration

2) DRP activation

3) Communicating the disaster

4) Assessment of current and and prevention of further damage

5) Standby facility activation

6) Establish IT operations

7) Repair and rebuilding of primary facility

Mandatory

Since it is almost impossible to predict when and how a disaster might occur, <<Organization Name>> must be prepared to find out about disasters from a variety of possible avenues. These can include:

· Edit this list to reflect your organization

· First hand observation

· System Alarms and Network Monitors

· Environmental and Security Alarms in the Primary Facility

· Security staff

· Facilities staff

· End users

· 3rd Party Vendors

· Media reports

Once the Disaster Recovery Lead has determined that a disaster had occurred, s/he must officially declare that the company is in an official state of disaster. It is during this phase that the Disaster Recovery Lead must ensure that anyone that was in the primary facility at the time of the disaster has been accounted for and evacuated to safety according to the company’s Evacuation Policy.

While employees are being brought to safety, the Disaster Recovery Lead will instruct the Communications Team to begin contacting the Authorities and all employees not at the impacted facility that a disaster has occurred.

Mandatory

Once the Disaster Recovery Lead has formally declared that a disaster has occurred s/he will initiate the activation of the DRP by triggering the Disaster Recovery Call Tree. The following information will be provided in the calls that the Disaster Recovery Lead makes and should be passed during subsequent calls:

· Edit this list as required

· That a disaster has occurred

· The nature of the disaster (if known)

· The initial estimation of the magnitude of the disaster (if known)

· The initial estimation of the impact of the disaster (if known)

· The initial estimation of the expected duration of the disaster (if known)

· Actions that have been taken to this point

· Actions that are to be taken prior to the meeting of Disaster Recovery Team Leads

· Scheduled meeting place for the meeting of Disaster Recovery Team Leads

· Scheduled meeting time for the meeting of Disaster Recovery Team Leads

· Any other pertinent information

If the Disaster Recovery Lead is unavailable to trigger the Disaster Recovery Call Tree, that responsibility shall fall to the Disaster Management Team Lead

Refer to the “Communicating During a Disaster” section of this document.

Mandatory

Before any employees from <<Organization Name>> can enter the primary facility after a disaster, appropriate authorities must first ensure that the premises are safe to enter.

The first team that will be allowed to examine the primary facilities once it has been deemed safe to do so will be the Facilities Team. Once the Facilities Team has completed an examination of the building and submitted its report to the Disaster Recovery Lead, the Disaster Management, Networks, Servers, and Operations Teams will be allowed to examine the building. All teams will be required to create an initial report on the damage and provide this to the Disaster Recovery Lead within <<state timeframe>> of the initial disaster.

During each team’s review of their relevant areas, they must assess any areas where further damage can be prevented and take the necessary means to protect <<Organization Name>> assets. Any necessary repairs or preventative measures must be taken to protect the facilities; these costs must first be approved by the Disaster Recovery Team Lead.

Mandatory

Should a disaster actually occur and <<Organization Name>> need to exercise this plan, this section will be referred to frequently as it will contain all of the information that describes the manner in which <<Organization Names>> information system will be recovered.

This section will contain all of the information needed for the organization to get back to its regular functionality after a disaster has occurred. It is important to include all Standard Operating Procedures documents, run-books, network diagrams, software format information etc. in this section.

Mandatory

In this section, include a detailed system architecture diagram. Ensure that all of the organization’s systems and their locations are clearly indicated.

<<System Architecture Diagram>>

Mandatory

Please list all of the IT Systems in your organization in order of their criticality. Next, list each system’s components that will need to be brought back online in the event of a disaster. Add or delete rows as needed to the table below.

Deliverable 4 – Incident Response Plan

Document Control