Incident Management
Last updated
Last updated
Copyright © 2024 iSHARE Foundation
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 |
---|---|
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:
The Steering party proactively coordinates the handling and solving of incidents, and assists if necessary;
All parties are responsible for reporting all incidents in the data space/iSHARE Network, and taking the steps necessary to handle and solve incidents.
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.
The reporting party reports an incident to the Steering party, including an estimation of the incident classification;
The Steering party assesses the incident and the estimated incident classification by the reporting party, and:
Accepts the incident classification and moves to step 3; or
Changes the incident classification and moves to step 3; or
Rejects the reported event as an incident, and communicates why to the reporting party.
The Steering party registers the incident and initiates incident handling, as follows:
If classified as a minor incident:
If the minor incident is assessed as the result of non-compliance with rules and guidelines, and/or if it has had significant negative impact on the normal operation of the data space/iSHARE network, the warnings, suspension and exclusion process will also be initiated;
The Steering party gives the reporting party, the causing party and/or (an)other party(ies) - whichever it deems most capable/suitable - the responsibility of handling the minor incident, under supervision of the Steering party (see step 4);
The party(s) responsible for handling the minor incident communicates the minor incident, the incident manager, and that the minor incident is being solved, to the parties impacted by it.
If classified as a calamity:
If the calamity is assessed as the result of non-compliance with rules and guidelines, and/or if it has had significant negative impact on the normal operation of the data space, the warnings, suspension and exclusion process will also be initiated;
The Steering party gives the reporting party, the causing party and/or (an)other party(ies) - whichever it deems most capable/suitable - the responsibility of handling the calamity, under supervision of the Steering party (see step 4);
IF there is a data security breach that needs to be reported in line with Data leaks reporting (meldplicht datalekken), the party(ies) responsible for handling the calamity report the data security breach to the Autoriteit Persoonsgegevens (personal data authority) and follow the authority's guidelines on the rest of the incident management process;
The Steering party informs the data space/iSHARE network of the calamity (and that it is being solved) and who the incident manager is, as well as any parties outside the network that it deems necessary to inform (e.g. branch organisations, the NCSC or even law enforcement);
The Steering party sets up an action plan to minimise risks and damage.
If classified as a crisis:
If the crisis is assessed as the result of non-compliance with rules and guidelines, and/or if it has had significant negative impact on the normal operation of the data space, the warnings, suspension and exclusion process will also be initiated;
The Satellite gives the reporting party, the causing party and/or (an)other party(ies) - whichever it deems most capable/suitable - the responsibility of handling the crisis, under supervision of and assisted by the Steering party (see step 4). Different to the process for minor incidents and calamities, the Steering party can also choose to take the responsibility of handling the crisis itself even if it is not the causing party;
IF there is a data security breach that needs to be reported in line with Data leaks reporting (meldplicht datalekken), the party(ies) responsible for handling the calamity report the data security breach to the Autoriteit Persoonsgegevens (personal data authority) and follow the authority's guidelines on the rest of the incident management process;
The Steering party informs the data space of the crisis (and that it is being solved) and who the incident manager is, as well as any parties outside the network that it deems necessary to inform (e.g. branch organisations, the NCSC or even law enforcement);
The Satellite sets up an action plan to minimise risks and damage.
The Steering party coordinates the contact with the involved parties, monitors progress and assists in handling the incident if necessary. The Steering party also communicates progress to the data space in case of a calamity or crisis. If progress is non-compliant to the incident service level, the Steering party MAY choose to upscale (from incident to calamity or from calamity to crisis);
When the incident is handled and therefore solved, the Steering party closes the incident;
In case of a minor incident, the responsible party communicates the incident closure to the parties impacted by it;
In case of a calamity or crisis, the Steering party communicates the incident closure to the data space.The Steering party evaluates the incident with the reporting and/or (an)other party(ies), and registers the evaluation for future learning. It can choose to share the gained insights with (selected) parties in the data space/iSHARE network.
Minor incident
Expected unavailability of < 8 hours of an Adhering Party or < 4 hours of a Certified Party or < 2 hours of the Satellite, and/or;
(Potential) data security breach, for example through the loss of a USB stick, laptop, hard disk, or because of hacking attempts or found malware, and/or;
Fraud or presumption of fraud by, for example an employee or a hacker.
Calamity
Direct involvement of three or more Adhering/Certified Parties, and/or;
Serious impediment(s) to other Adhering/Certified Party(ies), and/or;
Expected unavailability of > 8 hours of an Adhering Party or > 4 hours of a Certified Party or > 2 hours of the Satellite, and/or;
Data security breach that needs to be reported in line with meldplicht datalekken, and/or;
(Other) impact on confidentiality and integrity.
Crisis
Involvement of 10 or more Adhering/Certified Parties, and/or;
Serious impact on image and trustworthiness of iSHARE, and/or;
Expected unavailability of > 48 hours of a Certified Party or > 12 hours of the Satellite, and/or;
Political implications, and/or;
Fundamental legal or technical vulnerability.
Non-compliant/Causing party (Incidents pertaining to:)
Reporting party
Steering (facilitating) party
Adhering party
Any
Satellite
Certified party
Any
Satellite
Satellite
Any
Scheme Owner