Comprehensive Security Plan

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

Introduction

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.

Definition of a Disaster

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

Purpose

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.

Scope

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

Version Information & Changes

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.

Disaster Recovery Teams & Responsibilities

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.

Disaster Recovery Lead

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

Role and Responsibilities

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.

Contact Information

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

Disaster Management Team

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.

Role & Responsibilities

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

Contact Information

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

Network Team

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

Contact Information

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

Server Team

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 standby facility

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.

Applications Team

Mandatory

The Applications Team will be responsible for ensuring that all enterprise applications operates as required to meet business objectives in the event of and during a disaster. They will be primarily responsible for ensuring and validating appropriate application performance 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 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.

Operations Team

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

Contact Information

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

Senior Management Team

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

Contact Information

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

Communication Team

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

Contact Information

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

Disaster Recovery Call Tree

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.

Data and Backups

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.

Data in Order of Criticality

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

Dealing with a Disaster

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

Disaster identification and declaration

DRP activation

Communicating the disaster

Assessment of current and and prevention of further damage

Standby facility activation

Establish IT operations

Repair and rebuilding of primary facility

Disaster Identification and Declaration

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.

DRP Activation

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

Communicating the Disaster

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

Assessment of Current and Prevention of Further Damage

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.

Restoring IT Functionality

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.

Current System Architecture

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

IT Systems

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

Revision History

Document Approvals

This document requires the following approvals:

Document Distribution

This document will be distributed to:

Contributors

Development of this policy was assisted through information provided by the following organizations:

[Company Name] will ensure that it reacts appropriately to any actual or suspected incidents relating to information systems and information within the custody of the Organization.

Purpose

The aim of this policy is to ensure that [Company Name] reacts appropriately to any actual or suspected security incidents relating to information systems and data.

Scope

This document applies to all Departments, Partners, Employees of the organization, contractual third parties and agents of the organization who use [Company Name] IT facilities and equipment or have access to, or custody of, customer information or [Company Name] information.

All users must understand and adopt the use of this policy and are responsible for ensuring the safety and security of the Organization systems and the information that they use or manipulate.

All users have a role to play and a contribution to make to the safe and secure use of technology and the information that it holds.

Definition

This policy needs to be applied as soon as information systems or data are suspected to be, or are actually affected by an adverse event which is likely to lead to a security incident.

The definition of an “information management security incident” (‘Information Security Incident’ in the remainder of this policy and procedure) is an adverse event that has caused or has the potential to cause damage to an organization’s assets, reputation and/or personnel. Incident management is concerned with intrusion, compromise and misuse of information and information resources, and the continuity of critical information systems and processes.

An Information Security Incident includes, but is not restricted to, the following:

The loss or theft of data or information.

The transfer of data or information to those who are not entitled to receive that information.

Attempts (either failed or successful) to gain unauthorized access to data or information storage or a computer system.

Changes to information or data or system hardware, firmware, or software characteristics without the Organization knowledge, instruction, or consent.

Unwanted disruption or denial of service to a system.

The unauthorized use of a system for the processing or storage of data by any person.

Examples of some of the more common forms of Information Security Incidents have been provided in Appendix 2.

Risks

[Company Name] recognizes that there are risks associated with users accessing and handling information to conduct official business.

This policy aims to mitigate the following risks [amend the list as appropriate]:

To reduce the impact of information security breaches by ensuring incidents are followed up correctly.

To help identify areas for improvement to decrease the risk and impact of future incidents.

Non-compliance with this policy could have a significant effect on the efficient operation of the Organization and may result in financial loss and an inability to provide necessary services to our customers.

Procedure for Incident Handling

Events and weaknesses need to be reported at the earliest possible stage as they need to be assessed by an [Name a role – although likely to be an Information Security Advisor]. The Advisor [or other named role] enables the [Name a department – e.g. Information Services department] to identify when a series of events or weaknesses have escalated to become an incident. It is vital for the [Name a department – e.g. Information Services department] to gain as much information as possible from the business users to identify if an incident is occurring.

Policy Compliance

If any user is found to have breached this policy, they may be subject to [Company Name] disciplinary procedure. If a criminal offence is considered to have been committed further action may be taken to assist in the prosecution of the offender(s).

If you do not understand the implications of this policy or how it may apply to you, seek advice from [name appropriate department].

Policy Governance

The following table identifies who within [Company Name] is Accountable, Responsible, Informed or Consulted with regards to this policy. The following definitions apply:

Responsible – the person(s) responsible for developing and implementing the policy.

Accountable – the person who has ultimate accountability and authority for the policy.

Consulted – the person(s) or groups to be consulted prior to final policy implementation or amendment.

Informed – the person(s) or groups to be informed after policy implementation or amendment.

Responsible	[Insert appropriate Job Title]
Accountable	[Insert appropriate Job Title. It is important that only one role is held accountable.]
Consulted	[Insert appropriate Job Title, Department or Group Department, Employee Panels, etc.]
Informed	[Insert appropriate Job Title, Department or Group.]

Review and Revision

This policy, and all related appendices will be reviewed as it is deemed appropriate, but no less frequently than every 12 months.

Policy review will be undertaken by [Name an appropriate role].

References

The following [Company Name] policy documents are directly relevant to this policy [amend the list as appropriate]:

Email Policy.

Internet Acceptable Use Policy.

Software Policy.

GCSx Acceptable Usage Policy and Personal Commitment Statement.

Computer, Telephone and Desk Use Policy.

Removable Media Policy.

Remote Working Policy.

IT Access Policy.

Legal Responsibilities Policy.

Information Protection Policy.

Human Resources Information Security Standards.

IT Infrastructure Policy.

Communications and Operation Management Policy.

Key Messages

All staff should report any incidents or suspected incidents immediately by [enter appropriate details here].

We can maintain your anonymity when reporting an incident if you wish.

If you are unsure of anything in this policy, you should ask for advice from [name an appropriate department]

Appendix 1 – Process Flow; Reporting an Information Security Event or Weakness

[Include a diagram similar to the one below if required]

Appendix 2 – Examples of Information Security Incidents

Examples of the most common Information Security Incidents are listed below. It should be noted that this list is not exhaustive.

Malicious

Giving information to someone who should not have access to it - verbally, in writing or electronically.

Computer infected by a Virus or other malware.

Sending a sensitive e-mail to 'all staff' by mistake.

Receiving unsolicited mail of an offensive nature.

Receiving unsolicited mail which requires you to enter personal data.

Finding data that has been changed by an unauthorized person.

Receiving and forwarding chain letters – including virus warnings, scam warnings and other emails which encourage the recipient to forward onto others.

Unknown people asking for information which could gain them access to data (e.g. a password or details of a third party).

Misuse

Use of unapproved or unlicensed software on [Company Name] equipment.

Accessing a computer database using someone else's authorization (e.g. someone else's user id and password).

Writing down your password and leaving it on display / somewhere easy to find.

Printing or copying confidential information and not storing it correctly or confidentially.

Theft / Loss

Theft / loss of a hard copy file.

Theft / loss of any [Company Name] computer equipment.

Appendix 3 - Procedure for Incident Handling

Reporting Information Security Events or Weaknesses

The following sections detail how users and IT Support Staff [or equivalent] must report information security events or weaknesses. Appendix 1 provides a process flow diagram illustrating the process to be followed when reporting information security events or weaknesses [include if so required].

Reporting Information Security Events for all Employees

Security events, for example, a virus infection, could quickly spread and cause data loss across the organization. All users must understand, and be able to identify that any unexpected or unusual behavior on the workstation could potentially be a software malfunction. If an event is detected users must:

Note the symptoms and any error messages on the screen.

Disconnect the workstation from the network if an infection is suspected (with assistance from IT Support Staff [or equivalent department]).

Not use any removable media (for example USB memory sticks) that may also have been infected.

All suspected security events should be reported immediately to the Information Services Helpdesk [or equivalent department] on [state phone number].

If the Information Security event is in relation to paper or hard copy information, for example, personal information files that may have been stolen from a filing cabinet, this must be reported to Senior Management and either the Data Protection Officer [or equivalent posts] for the impact to be assessed.

The Information Services Helpdesk [or equivalent] will require you to supply further information, the nature of which will depend upon the nature of the incident. However, the following information must be supplied [amend the list as appropriate]:

Contact name and number of person reporting the incident.

The type of data, information or equipment involved.

Whether the loss of the data puts any person or other data at risk.

Location of the incident.

Inventory numbers of any equipment affected.

Date and time the security incident occurred.

Location of data or equipment affected.

Type and circumstances of the incident.

Reporting Information Security Weaknesses for all Employees

Security weaknesses, for example, a software malfunction, must be reported through the same process as security events. Users must not attempt to prove a security weakness as such an action may be considered to be misuse.

Weaknesses reported to application and service providers by employees must also be reported internally to Information Services [or equivalent department]. The service provider’s response must be monitored and the effectiveness of its action to repair the weakness must be recorded by Information Services [or equivalent department].

Reporting Information Security Events for IT Support Staff [or equivalent staff]

Information security events and weaknesses must be reported to a nominated central point of contact within Information Services [or equivalent department] as quickly as possible and the incident response and escalation procedure must be followed.

Security events can include:

Uncontrolled system changes.

Access violations – e.g. password sharing.

Breaches of physical security.

Non compliance with policies.

Systems being hacked or manipulated.

Security weaknesses can include:

Inadequate firewall or antivirus protection.

System malfunctions or overloads.

Malfunctions of software applications.

Human errors.

The reporting procedure must be quick and have redundancy built in. All events must be reported to at least two nominated people within Information Services [or equivalent department] who must both be required to take appropriate action. The reporting procedure must set out the steps that are to be taken and the time frames that must be met. [It may be more appropriate to establish a single line of reporting with demonstrable accountability of the person / role required to take action on the reported event]

An escalation procedure must be incorporated into the response process so that users and support staff are aware who else to report the event to if there is not an appropriate response within a defined period.

Incidents must be reported to the Business Continuity Management teams [or equivalent departments] should the incident become service affecting.

Management of Information Security Incidents and Improvements

A consistent approach to dealing with all security events must be maintained across the organization. The events must be analysed and the Security Advisor [or equivalent role] must be consulted to establish when security events become escalated to an incident. The incident response procedure must be a seamless continuation of the event reporting process and must include contingency plans to advise the organzation on continuing operation during the incident.

All high and medium incidents should be reported to [enter details here]. All low incidents should be reported to To d[enter details here].

Collection of Evidence

If an incident may require information to be collected for an investigation, strict rules must be adhered to. The collection of evidence for a potential investigation must be approached with care. Internal Audit [or equivalent department] must be contacted immediately for guidance, and strict processes must be followed for the collection of forensic evidence. If in doubt about a situation, for example concerning computer misuse, contact the [Name an appropriate department – e.g. IT Helpdesk] for advice.

Responsibilities and Procedures

Management responsibilities and appropriate procedures must be established to ensure an effective response against security events. The security advisor from Information Services [or equivalent department] must decide when events are classified as an incident and determine the most appropriate response.

An incident management process must be created and include details of:

Identification of the incident, analysis to ascertain its cause and vulnerabilities it exploited.

Limiting or restricting further impact of the incident.

Tactics for containing the incident.

Corrective action to repair and prevent reoccurrence.

Communication across the organization to those affected.

The process must also include a section referring to the collection of any evidence that might be required for analysis as forensic evidence. The specialist procedure for preserving evidence must be carefully followed.

The actions required to recover from the security incident must be under formal control. Only identified and authorized staff should have access to the affected systems during the incident and all of the remedial actions should be documented in as much detail as possible.

Learning from Information Security Incidents

To learn from incidents and improve the response process incidents must be recorded and a Post Incident Review conducted. The following details must be retained:

Types of incidents.

Volumes of incidents and malfunctions.

Costs incurred during the incidents.

The information must be collated and reviewed on a regular basis by Information Services [or equivalent department] and any patterns or trends identified. Any changes to the process made as a result of the Post Incident Review must be formally noted.

Rasmussen College