Security Incident and Data Breach Response

Purpose

This policy governs the actions required for reporting or responding to security incidents involving Chemwatch information technology resources to ensure effective and consistent reporting and handling of such events.

Scope

This policy applies to all employees using Chemwatch information technology resources or data.

Policy

Incident response will be handled appropriately based on the type and severity of the incident in accordance with the Incident Response Summary Table below.

Roles and Responsibilities

The incident manager is responsible for managing the response to a security incident as defined in the incident response summary table.

Process Overview

This procedure involves the following steps:

Detection of an incident.
Containment of the breach.
Assessing the impact.
Notification based on the impact.
Post mortem review and process/policies adjustments.

Implementing Procedures

Reporting Security incidents
Any member of staff at Chemwatch must report any suspected incident to I.T. managers.
Responding to Security Incidents
1. Incident Severity
  Incident response will be managed based on the level of severity of the incident. The level of severity is a measure of its impact on or threat to the operation or integrity of the company and its information. Four levels of incident severity will be used to guide incident response: high, medium, low, and NA (Not Applicable).
  1. High
    The severity of a security incident will be considered "high " if any of the following conditions exist:
    1. Threatens to have a significant adverse impact on a large number of systems and/or people (for example, the entire company is affected)
    2. Threatens confidential data
    3. Adversely impacts our enterprise system or service critical to our operations.
  2. Medium
    The severity of a security incident will be considered "medium" if any of the following conditions exist:
    1. Adversely impacts a moderate number of systems and/or people.
    2. Adversely impacts a non-critical enterprise system or service
    3. Adversely impacts a departmental system or service, such as a file server
    4. Disrupts a building network
  3. Low
    Low severity incidents have the following characteristics:
    1. Adversely impacts a very small number of systems or individuals
    2. Disrupts a very small number of network devices or segments
  4. NA (Not Applicable)
    This is used for events reported as a suspected IT security incident but upon investigation of the suspicious activity, no evidence of a security incident is found.
2. Incident Response Summary Table
  The following table summarizes the handling of IT security incidents based on incident severity, including response time, the responsible incident managers, and notification and reporting requirements. Check /wiki/spaces/CW/pages/27950367 on Levels of security issues. If client data is compromised at any level, affected clients should be notified within 24 hours.

Incident Severity	Levels	Characteristics (one or more condition present determines the severity)	Response Time	Incident Manager	Risk Controls	Who to Notify	Post-Incident Report Required*
High	5,4	Threatens to have a significant adverse impact on a large number of systems and/or people (for example, the entire company is affected) Threatens confidential data Adversely impacts our enterprise system or service critical to our operations.	2 hours since identification	One of 3 Senior I.T. managers	Restrict access to the system and data until resolved.	Other I.T. staff Customer Service Technical support/helpdesk staff All department heads	Yes
Medium	3,2	Adversely impacts a moderate number of systems and/or people. Adversely impacts a non-critical enterprise system or service Adversely impacts a departmental system or service, such as a file server Disrupts a building network	4 hours	One of 3 Senior I.T. managers	Consider restricting access to the system and data until resolved.	Other I.T. staff Customer Service Technical support/helpdesk staff All department heads	Yes
Low	1	Adversely impacts a very small number of systems or individuals Disrupts a very small number of network devices or segments	Next business day	One of 3 Senior I.T. managers	None	Affected individuals	No
N/A	"Not Applicable" - used for suspicious activities which upon investigation are determined not to be an IT security incident.

All security incidents/data breaches, High Medium and Low, will be logged in our Planfix system for monitoring. We have created a dedicated task and pipeline to keep track of incidents as seen in the below screen shot. All IT team members, and our CTO will be notified when a data breach task is created in Planfix and will be able to follow the progress of the incident through the various stages of this pipeline which is modeled on the notifiable data breaches scheme summary diagram.

Authorities to Notify

https://www.cyber.gov.au/

Workflow and Procedures

Planfix is currently used to record and track Security Incidents and Data Breaches. The project is called Data Breach. User search bar to quickly find it to report a problem. IT are responsible for tracking the icident reports 24x7.

The image below shows the stages the process has:

The image below shows an example of an incident event (test incident created while testing the flow).

Notifiable Data Breach Schema

Notification Template

You will need the following information to complete this template:

Information	Description
App name	The name of your Marketplace app.
Nature of incident	A concise description of what the identified incident is and its potential impact in 2-3 sentences. In cases where end user data has been leaked, also provide an indication of the extent of the data exposure and type(s) of data affected. For example, this may have been an issue in your Marketplace app which meant that a specific customer's data was visible to another customer during a three-hour period.
Source of incident information	How you learned about the existence of this issue. For example, through notification from another party, from self-discovery, etc.
Investigation details	What actions you undertook as part of investigating the incident to confirm its potential scope and impact.
Remediation actions	What actions you are taking (or have taken) to fix the incident.
Information about likelihood of exploitation / real-world impact	Details of whether the incident is likely to have resulted in actual impact to customers. For example, if there was any evidence in logs that indicates unauthorized access to customer data, the number of customers affected, etc.
Information about steps customers need to take (if applicable)	For server apps, instructions to fix the error on the managed environment. For example, directions for downloading the latest fix version and applying to server instance.