This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.
The incident management process describes the steps that the Scheme Owner, Satellite, Adhering and Certified Parties MUST take to solve incidents in the iSHARE network.
An incident is an event, not part of the standard service operation, that results in a potential impact or risk with regards to the quality, availability, confidentiality and/or integrity of (data within) the Trust Framework. This includes the data used for identification, authentication and authorisation purposes in the context of data exchange, but not the contents of the actual data exchange.
Note incident resolution is NOT part of regular maintenance, and therefore is NOT subject to maintenance windows as described under service levels.
Three classifications of incidents are recognised within iSHARE. Note that the impact or risk described is non-exhaustive.
Classification | Impact or risk |
---|---|
Minor incident |
|
Calamity |
|
Crisis |
|
The goal of the incident management process is to handle and solve different levels of incidents in a structured way and with minimal disruption to the functioning of the iSHARE network.
Several parties have responsibilities and tasks in the incident management process:
Non-compliant/Causing party (Incidents pertaining to:) | Reporting party | Steering (facilitating) party |
---|---|---|
Adhering party | Any | Satellite |
Certified party | Any | Satellite |
Satellite | Any | Scheme Owner |
Before initiating the process as below, the reporting party, in conjunction with the causing party (if not the same) MUST assess together whether the event deemed an incident is indeed an incident. At any point the reporting party can approach a legal entity (local or international) for the resolution of the incident. This needs to be informed to the concerned Satellite/ Scheme owner as well.