Versions Compared

Old Version 58

changes.mady.by.user Denise Hoppenbrouwer

Saved on

compared with

New Version 59

changes.mady.by.user Denise Hoppenbrouwer

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This part of the iSHARE scheme Scheme is considered normative and is therefore compliant with RFC 2119.


The incident management process describes the steps that the Scheme Owner and adheringAdhering- and certified parties 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 iSHARE schemeScheme. 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
  • Expected unavailability of < 8 hours of an adhering party Adhering Party or < 4 hours of a certified party Certified Party or < 2 hours of the Scheme Owner, 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 adheringAdhering/certified partiesCertified Parties, and/or;
  • Serious impediment(s) to other adheringAdhering/certified partyCertified Party(s), and/or;
  • Expected unavailability of > 8 hours of an adhering party Adhering Party or > 4 hours of a certified party Certified Party or > 2 hours of the Scheme Owner, 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 adheringAdhering/certified partiesCertified Parties, and/or;
  • Serious impact on image and trustworthiness of iSHARE, and/or;
  • Expected unavailability of > 48 hours of a certified party Certified Party or > 12 hours of the Scheme Owner, and/or;
  • Political implications, and/or;
  • Fundamental legal or technical vulnerability.

Goal

...

  • The Scheme Owner proactively coordinates the handling and solving of incidents, and assists if necessary;
  • Adhering/certified partiesCertified Parties are responsible for reporting all incidents in the iSHARE network, and taking the steps necessary to handle and solve incidents.

...

  1. The reporting party (i.e. any adheringAdhering/certified party Certified Party or the Scheme Owner itself) reports an incident to the Scheme Owner, including an estimation of the incident classification;
  2. The Scheme Owner assesses the incident and the estimated incident classification by the reporting party, and:
    1. Accepts the incident classification and moves to step 3; 
      or
    2. Changes the incident classification and moves to step 3;
      or
    3. Rejects the reported event as an incident, and communicates why to the reporting party.
  3. The Scheme Owner registers the incident and initiates incident handling, as follows:
    1. If classified as a minor incident:
      1. If the minor incident is assessed the result of non-compliance with scheme rules and guidelines, and/or if it has had significant negative impact on the normal operation of the iSHARE network, the warnings, suspension and exclusion process will also be initiated;
      2. The Scheme Owner gives the reporting party, the causing party and/or (an)other party(s) - whichever it deems most capable/suitable - the responsibility of handling the minor incident, under supervision of the Scheme Owner (see step 4); 
      3. 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.
    2. If classified as a calamity:
      1. If the calamity is assessed the result of non-compliance with scheme rules and guidelines, and/or if it has had significant negative impact on the normal operation of the iSHARE network, the warnings, suspension and exclusion process will also be initiated;
      2. The Scheme Owner gives the reporting party, the causing party and/or (an)other party(s) - whichever it deems most capable/suitable - the responsibility of handling the calamity, under supervision of the Scheme Owner (see step 4); 
        • IF there is a data security breach that needs to be reported in line with meldplicht datalekken, the party(s) 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;
      3. The Scheme Owner informs the 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);
      4. The Scheme Owner sets up an action plan to minimise risks and damage.
    3. If classified as a crisis:
      1. If the crisis is assessed the result of non-compliance with scheme rules and guidelines, and/or if it has had significant negative impact on the normal operation of the iSHARE network, the warnings, suspension and exclusion process will also be initiated;
      2. The Scheme Owner gives the reporting party, the causing party and/or (an)other party(s) - whichever it deems most capable/suitable - the responsibility of handling the crisis, under supervision of and assisted by the Scheme Owner (see step 4). Different to the process for minor incidents and calamities, the Scheme Owner 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 meldplicht datalekken, the party(s) 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;
      3. The Scheme Owner informs the iSHARE network 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);
      4. The Scheme Owner sets up an action plan to minimise risks and damage.
  4. The Scheme Owner coordinates the contact with the involved parties, monitors progress and assists in handling the incident if necessary. The Scheme Owner also communicates progress to the iSHARE network in case of a calamity or crisis. If progress is non-compliant to the incident service level, the Scheme Owner MAY choose to upscale (from incident to calamity or from calamity to crisis);
  5. When the incident is handled and therefore solved, the Scheme Owner closes the incident;
    1. In case of a minor incident, the responsible party communicates the incident closure to the parties impacted by it;
    2. In case of a calamity or crisis, the Scheme Owner communicates the incident closure to the iSHARE network.
  6. The Scheme Owner evaluates the incident with the reporting and/or (an)other party(s), and registers the evaluation for future learning. It can choose to share the gained insights with (selected) parties in the iSHARE network.