iSHARE Trust Framework
Other resources
Version 2.1 (current version)
Version 2.1 (current version)
  • iSHARE Trust Framework
  • Introduction
    • Goals and scope of the iSHARE Trust Framework
    • Guiding principles
    • Governance
  • Releases
    • Release notes
    • Release planning
    • Version history
  • Main aspects of the iSHARE Trust Framework
    • Key functionality
      • Support Machine to Machine (M2M) interaction
      • Support Human to Machine (H2M) interaction
      • Facilitate portable identity(s) for parties and humans
      • Facilitate flexible authorizations, applicable in any context
      • Enable data exchange based on delegations - even between unknown parties
      • Enable control over own data through management of consent
      • Provide a Trust Framework
    • Technical overview
    • Framework and roles
    • Legal provisions
    • Operational provisions
  • Use cases
    • Use case: M2M interaction (with fine-grained authorization)
    • Use case: H2M interaction (with coarse-grained authorization)
    • Use case: portable identity
    • Use case: delegation (and management of consent)
  • Detailed descriptions
    • Functional
      • Primary use cases
        • 1. M2M service provision
          • 1b. M2M service provision with the EP as the delegation info PIP
          • 1c. M2M service provision with the AR as the delegation info PIP
          • M2M service provision including an app
        • 2. H2M service provision with identity info at the IP
          • Without Identity Broker
          • With Identity Broker
      • Secondary use cases
      • Licenses
      • Delegation paths
      • Functional requirements per role
        • Party identification
        • User interface requirements
    • Technical
      • Technical standards
      • Structure of delegation evidence
        • Example cases
    • Operational
      • Operational processes
        • Admission
        • Withdrawal or Downgrade
        • Warnings, Suspension and Exclusion
        • Incident Management
        • Change Management
        • Management reporting
      • Service levels
        • Service levels for Adhering Parties
        • Service levels for Certified Parties
      • Communication
    • Legal
      • Legal context
        • Dutch Civil Code
        • Regulation on Electronic Identification and Trust Services (eIDAS)
        • Applicable competition law
        • General Data Protection Regulation (GDPR)
  • Glossary and legal notices
    • Glossary
    • Legal notices
    • Assumptions
Powered by GitBook
LogoLogo

  • Cookie Policy

  • Privacy Policy

  • Imprint

  • Contact Us

Copyright © 2024 iSHARE Foundation

On this page
  • Goal
  • Responsibilities
  • Sequence
  1. Detailed descriptions
  2. Operational
  3. Operational processes

Incident Management

PreviousWarnings, Suspension and ExclusionNextChange Management

Last updated 2 months ago

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, Data Space Governance Body, 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 .

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 or < 4 hours of a Certified Party or < 2 hours of the Participant Registry, 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 Participant Registry, 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 Participant Registry, and/or;

  • Political implications, and/or;

  • Fundamental legal or technical vulnerability.

Goal

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 data space/iSHARE network.

Responsibilities

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.

Non-compliant/Causing party (Incidents pertaining to:)

Reporting party

Steering (facilitating) party

Adhering party

Any

Data Space Governance Body

Certified party

Any

Data Space Governance Body

Participant Registry

Any

Scheme Owner

Sequence

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 Data Space/ Scheme owner as well.

  1. The reporting party reports an incident to the Steering party, including an estimation of the incident classification;

  2. The Steering party 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 Steering party registers the incident and initiates incident handling, as follows:

    1. If classified as a minor incident:

      1. 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);

      2. 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. 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);

      2. The Steering party sets up an action plan to minimise risks and damage.

    3. If classified as a crisis:

      1. 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 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;

      2. 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);

      3. The Steering party sets up an action plan to minimise risks and damage.

  4. 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);

  5. When the incident is handled and therefore solved, the Steering party 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 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.

Data security breach that needs to be reported in line with , and/or;

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 will also be initiated;

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 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 or other relevant regulations, the party(ies) responsible for handling the calamity, report the data security breach to the Autoriteit Persoonsgegevens (personal data authority) or other relevant national bodies and follow the authority's guidelines on the rest of the incident management process;

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 will also be initiated;

IF there is a data security breach that needs to be reported in line with , 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;

service levels
warnings, suspension and exclusion process
warnings, suspension and exclusion process
Data leaks reporting (meldplicht datalekken)
warnings, suspension and exclusion process
Data leaks reporting (meldplicht datalekken)
meldplicht datalekken