About Junari
< Back to Article ListIS-05 Incident Management Procedure
Last updated: 13 November 2024 at 14:42:26 UTC by Mya Tyler-Lovett
Incident Management Procedure
Document Ref No |
IS-0 |
Version No |
V1 |
Last review date |
16/10/2021 |
Approved by |
Dom Tyler |
Next review |
16/10/2022 |
Contents
Receipt and classification of incidents, events, weaknesses and non-conformities 3
Personal data breach notification 4
Notifying supervisory authority 5
1. Purpose, scope and users
The purpose of this document is to ensure the effective handling and quick response to security events, weaknesses and non-conformities.
This document is applied to the entire Information Security Management System (ISMS) scope including Data Protection policies, i.e. to all employees and assets used within the ISMS scope, as well as to suppliers and other persons outside the organisation who come into contact with systems and information within the ISMS scope.
Users of this document are all employees of Junari, as well as all above mentioned persons.
2. Incident management
An information security incident is a "single or a series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security or business continuity" (ISO/IEC 27000).
2.1. Receipt and classification of incidents, events, weaknesses and non-conformities
Each employee, supplier or other third party who is in contact with information and/or systems of Junari must report any system events, weaknesses and non-conformities which could lead to a possible incident in the following way:
● Incidents, weaknesses and events must be reported to Mark Hutchinson and logged as a security incident in the Incident Log. A description of the incident as well as any corrective/preventive actions should be recorded.
2.2. Treating Security Incidents
If a security incident was reported, the person most appropriate to deal with the issue should be identified and detailed in the incident log as the incident owner. The incident owner should take the following steps.
1. Take measures to contain the incident
2. Analyse the cause of the incident
3. Take corrective actions to eliminate the cause of the incident
4. Inform persons who were involved in the incident about the incident treatment process
5. Record the resolution steps and outcome in the incident log
2.3. Collection of evidence
During investigations, care must be taken to preserve evidence that may help to establish the origin of technical incidents and/or be used as evidence in legal and other proceedings.
2.4. Learning from incidents
Junari must review a sample of minor incidents at least annually and must analyse recorded incidents in advance of Management Review meetings and identify causes and trends and, if necessary, suggest corrective actions.
3. Personal data breach notification
In the event of a personal data breach, Junari may be required to notify the Data Controller, Data Subjects and the Supervisory Authority.
3.1. Notifying data controllers
When a personal data breach or suspected data breach affects personal data that is being processed on behalf of a third party, Junari must report any personal data breach to the respective data controller/controllers without undue delay.
The Incident Owner will send notification to the controller that will include the following:
● A description of the nature of the breach
● Categories of personal data affected
● Approximate number of data subjects affected
● Name and contact details of the Incident Owner
● Potential consequences of the personal data breach
● Measures taken to address the personal data breach
● Any additional information relating to the data breach
3.2. Notifying data subjects
The Board of Directors/Senior Management Team must assess if the personal data breach is likely to result in high risk to the rights and freedoms of the data subjects. If yes, the Incident Owner must notify without undue delay the affected data subjects.
The Notification to the data subjects must be written in clear and plain language and must contain the same information listed in Section 3.1.
If, due to the number of affected data subjects, it is disproportionately difficult to notify each affected data subject, the Incident Owner must take the necessary measures to ensure that the affected data subjects are notified by using appropriate, publicly available channels (i.e.
3.3. Notifying supervisory authority
When the personal data breach or suspected data breach affects personal data that is being processed by Junari as a data controller, the Incident Owner must: -
● Establish whether the personal data breach should be reported to the relevant Supervisory Authority.
● Carry out a Data Protection Impact Assessment on the processing activity affected by the data breach.
If the personal data breach is not likely to result in a risk to the rights and freedoms of the affected data subjects, no notification is required. However, the data breach should be recorded in the Incident Log.
If the personal data breach is likely to result in a risk to the rights and freedoms of the data subjects affected by the personal data breach, the Supervisory Authority must be notified without undue delay and no later than 72 hours of Junari becoming aware of the breach. Any possible reasons for delay beyond 72 hours must be communicated to the Supervisory Authority.
The notification to the Supervisory Authority must contain the same information listed in Section 3.1.
4. Document management
This policy shall be available to all Junari Employees and any Third Parties where required. The policy must be reviewed and, if necessary, updated at least once a year. Notice of significant revisions shall be provided to Junari Employees via email.
5. Version history
Summary of Change |
Date of Change |
Author |
Version No |
First Draft |
16/10/2021 |
Dom Tyler |
1 |
|
|
|
|
|
|
|
|