# Service levels for Adhering Parties {% hint style="info" %} *This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.* {% endhint %} For Adhering Parties that provide system services, the following service levels apply * [Availability](#servicelevelsforadheringparties-availability) * [Performance](#servicelevelsforadheringparties-performance) * [Incidents](#servicelevelsforadheringparties-incidents) * [Support](#servicelevelsforadheringparties-support) For Adhering Parties that do not provide system services, only the following service levels apply: * [Incidents](#servicelevelsforadheringparties-incidents) * [Support](#servicelevelsforadheringparties-support) {% hint style="info" %} In the context of this Framework, the service levels for Availability and Performance mainly apply to [system service providers](https://framework.ishare.eu/glossary-and-legal-notices/glossary#system-services), irrespective of their role. Adhering parties like Service Consumers and Entitled Parties do not provide System Services (which are catered through the use of systems) and thereby may be exempt from the service levels of Availability and Performance. Incidents and Support service levels are still applicable. {% endhint %} ## Availability **Availability** is a measure of the time a service is in a functioning condition. It includes the availability window and the maintenance window. #### Availability window The **availability window** includes the times at which Adhering Parties guarantee the availability of their service. **No norm** is set for Adhering Parties' availability window, to leave Service Providers free to run their service whenever they deem appropriate (e.g. a trucking company does not need to leave its trucks' board computers on 24 hours \* all days of the year). **Minimum level required** at times deemed appropriate to run service\*\*:\*\* guideline of 95% availability\* per calendar month, from 00:00-23:59h \*Planned maintenance does NOT count as unavailability #### Maintenance window The **maintenance window** includes the times at which Adhering Parties can perform planned maintenance, that is likely to result in downtime, to their service. If no downtime is expected, maintenance can take place outside of the maintenance window. Planned maintenance does NOT include incident resolution, as this can take place outside the maintenance window as described under [incidents](#servicelevelsforadheringparties-incidents). **Norm:** * The maintenance window includes all times outside office hours. * **No norm** is set for communication about (different forms of) maintenance, as this is a matter between Adhering Parties. ## Performance **Performance** includes the time it takes for a service to respond when requested or called upon; i.e. the time an Adhering Party's service takes to respond to a received message. Before an Adhering Party knows whether it may respond to a request, however, it often needs to request (more) information from one or more certified parties; e.g. delegation info or authorisation info. It therefore needs to send out a new message itself, and wait for this message to be responded to by a certified party. While Certified Parties' response times are short, the process of sending out and receiving (sometimes several) new messages before the original request can be answered takes time. Consequently, **no norm** is set for Adhering Parties' total performance. The following **guidelines** are set: * 95% of Adhering Parties' messages SHOULD be responded to within 2 seconds of receiving all information needed from certified parties; * 99% of Adhering Parties' messages SHOULD be responded to within 5 seconds of receiving all information needed from certified parties; * Each Adhering Party SHOULD be able to process at least 100 simultaneous messages while meeting the above requirements. ## Incidents An **incident** is an event, not part of the standard service operation, that results in a potential impact or risk on the quality, availability, confidentiality and/or integrity of (data within) the iSHARE Trust Framework. This ONLY 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. Three classifications of incidents are recognised within iSHARE, as explained in the [incident management process](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes/incident-management): * Minor incident; * Calamity; * Crisis. **Norm:** * All incidents MUST be communicated by the Adhering Party(s)to the Scheme Owner directly after they are discovered; * Communication MUST include date, time, incident level as estimated by the Adhering Party(s), argumentation including impacted service(s), and a potential incident manager; * In case of a calamity or crisis, the Adhering Party MUST have an incident manager available during working days, and SHOULD have an incident manager available 24 \* 7; * An update on the incident MUST be communicated to the Scheme Owner\*: * For minor incidents, at the end of each working day; * For calamities, within 2 hours of every significant update and at the end of each working day. * For crises, within 2 hours of every significant update and every 4 hours. * All incidents SHOULD be handled by the Adhering Party (in cooperation with the Scheme Owner as per the [incident management process](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes/incident-management)) within 3 working days after being appointed as the responsible party - unless agreed otherwise. \*In line with the [incident management process](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes/incident-management), the Scheme Owner presents an overview of current calamities and crises on its website ## Support **Support** by Adhering Parties could include answering questions, requests, and complaints from other Adhering Parties. **No norm** is set for Adhering Parties as it is a matter between them (and other Adhering Parties). The following **guidelines** are set, however: * Adhering Parties are available for support via e-mail. * They SHOULD confirm receiving a question/request within 1 working day. They SHOULD send an underpinned reaction (with an answer/solution or, at the very least, a direction) within 5 working days.