SERVICE LEVEL AGREEMENT KIREMA • Personalize IT
SERVICE LEVEL AGREEMENT
KIREMA • Personalize IT
Versie 2.0 januari 2021
INHOUD
Deze Service Level Agreement (SLA) is onlosmakelijk verbonden met de tussen KIREMA en opdrachtgever gesloten overeenkomst, waarvan de algemene voorwaarden van KIREMA integraal onderdeel uitmaken.
Opdrachtgever en KIREMA zullen periodiek de SLA evalueren.
De in de SLA overeengekomen Service Levels kunnen alleen nagekomen worden indien de afspraken en procedures wederzijds worden nageleefd.
Beschrijving/definitie | |
Back-up | Het veiligstellen van data. |
Beschikbaarheid | Is het tegenovergestelde van Onbeschikbaarheid. |
Besturingssysteem | Het Besturingssysteem waarmee de Apparatuur is uitgevoerd. |
Call | Dit is een Melding aan de Contactpersoon van KIREMA. Het kan hier gaan om een Melding van een Incident, vraag, verzoek of klacht. |
Change | Een verzoek tot Wijziging. |
Contactpersoon | Door opdrachtgever en KIREMA aan te wijzen personen die dienen als Contactpersoon voor het melden van alle relevante kwesties aangaande de dagelijkse gang van zaken met betrekking tot hosting diensten. |
Database | Verzameling van onderling samenhangende door opdrachtgever aangeleverde gegevens die toegankelijk zijn vanuit de door opdrachtgever gebruikte applicaties. |
Hersteltijd | De tijd, door KIREMA gemeten en geregistreerd, tussen de Storingsmelding en het gereed melden door KIREMA van de Storing aan opdrachtgever (of het tijdstip waarop KIREMA tracht de Melding door te geven). |
Incident | Een gedetecteerde verstoring of dreigende verstoring van het overeengekomen serviceniveau van de dienstverlening. |
Kantooruren | Werkdagen tussen 09:00 en 17:00. |
Maand | Met een Maand wordt een kalendermaand bedoeld. |
Melding | Elk elektronisch verzoek van de opdrachtgever aan KIREMA eventueel gevolgd door een mondelinge toelichting. |
Noodnummer | Het storingsnummer dat buiten Kantooruren beschikbaar is voor het melden van Storingen. |
Onbeschikbaarheid | Er is sprake van Onbeschikbaarheid als een hosting dienst van KIREMA als gevolg van een niet geplande gebeurtenis voor geen enkele gebruiker bruikbaar is. |
Onderhoud | Het plegen van reparaties, het nemen van voorzorgsmaatregelen en regelmatige controle van de geïnstalleerde Apparatuur alsmede gepland Onderhoud. |
Prioriteit | De volgorde waarin Incidenten, problemen en Wijzigingen worden behandeld. |
Probleem | Een structurele verstoring of dreigende verstoring van het overeengekomen serviceniveau van de dienstverlening. |
Reactietijd | De tijdsduur tussen een correcte Melding door opdrachtgever van een Incident of de aanvraag van een Wijziging en de aanvang van de werkzaamheden verband houdende met de oplossing van een Incident of het uitvoeren van een Wijziging. |
RfC | Request for change, ingesteld door KIREMA of opdrachtgever. |
Service Window | Het tussen de opdrachtgever overeengekomen tijdsbestek waarin opdrachtgever gebruik kan maken van een dienst van KIREMA. |
SLA | Service Level Agreement |
Software | De door KIREMA geïnstalleerde en geconfigureerde programmatuur op de Apparatuur. |
Storing | Het onvoorzien tijdelijk of geheel uitvallen van de dienstverlening aan opdrachtgever. |
Systeemomgeving | Het totaal aan services waardoor opdrachtgever in staat wordt gesteld de applicaties te gebruiken. |
Werkdag | Maandag tot en met vrijdag met uitzondering van de volgens de Nederlandse kalender algemeen erkende aangewezen feestdagen. |
3.1 Rangorde Overeenkomsten
Rangorde | Overeenkomst |
01 | Overeenkomst |
02 | Algemene voorwaarden |
03 | Service Level Agreement |
04 | Overige schriftelijke communicatie tussen KIREMA en opdrachtgever |
In geval van tegenstrijdigheden of onduidelijkheden in de bovengenoemde overeenkomsten prevaleert een overeenkomst van hogere rangorde. De rangorde van de diverse overeenkomsten is in bovenstaand schema aangegeven.
3.2 Contactpersonen
Partijen wijzen elk een contractbeheerder en vast contactpersoon aan. Contactgegevens van de contractbeheerder en contactpersoon worden schriftelijk vastgelegd. Wijzigingen in contactgegevens van de contractbeheerder en contactpersoon worden eveneens schriftelijk vastgelegd.
De operationele communicatie betreffende het opvolgen van Meldingen van Storingen en wensen vindt zoveel mogelijk plaats tussen de contactpersonen van opdrachtgever en de Servicedesk van KIREMA.
3.3 Algemene beschrijving van de diensten
De SLA heeft betrekking op de diensten zoals beschreven in de overeenkomst.
KIREMA spant zich in dat de diensten te allen tijde probleemloos beschikbaar zijn. In het geval dat een Storing de Beschikbaarheid vermindert, verplicht KIREMA zich tot het oplossen van de Storing binnen de in deze SLA overeengekomen termijnen. KIREMA verplicht zich tot regelmatige controle en gedegen Onderhoud van de door haar in gebruik genomen Apparatuur en systemen en zorgt dat de capaciteit van deze Apparatuur en systemen zodanig is dat dit bij normaal gebruik niet leidt tot Storingen.
3.4 Duur van de SLA
De SLA gaat in op datum van oplevering van de diensten en heeft een looptijd gelijk aan die van de overeenkomst.
3.5 Overlegstructuur Overleg
Overleg zal steeds plaats vinden op verzoek van één van partijen door middel van de vaste contactpersonen (bepaling 3.2 SLA).
Tijdens het overleg wordt de dienstverlening, op operationeel niveau, inhoudelijk afgestemd en worden werkafspraken en procedures besproken en geëvalueerd. Ook wordt de kwaliteit van de dienstverlening van KIREMA regelmatig geëvalueerd.
Agendapunten
Agendapunten worden voornamelijk bepaald door lopende zaken, rapportages, projecten, Wijzigingen van procedures en de kwaliteit.
3.6 Service Window
Service Window zoals gedefinieerd binnen deze SLA
Window | Omschrijving |
Service Window | Op werkdagen, kantoortijden 8:00 – 17:30 uur (Central European Time) |
3.7 Prioriteitentabel
Aanduiding van Prioriteiten zoals gedefinieerd binnen deze SLA
Prioriteit | Betekenis |
1 | Uitval van de dienstverlening |
2 | Gedeeltelijk onderbroken / verminderde prestatie |
3 | Problemen met beperkte gevolgen voor opdrachtgever |
3.8 Maintenance Window
Maintenance Window zoals gedefinieerd binnen deze SLA
Window | Omschrijving |
Maintenance Window | Van 21:00 tot 6:00 uur |
3.9 Reactietijdentabel
Reactietijden zoals gedefinieerd binnen deze SLA
Prioriteit | Reactietijd | Oplostijd | Toelichting |
1 | 1 uur na melding | binnen 4 uur | De Call wordt, binnen het geldende Service Window, binnen de Reactietijd + Oplostijd na de Incident Melding, opgelost. |
2 | 4 uur na melding | binnen 16 uur | De Call wordt, binnen het geldende Service Window, binnen de Reactietijd + Oplostijd na de Incident-Melding, opgelost. |
3 | 8 uur na melding | binnen 48 uur | De Call wordt, binnen het geldende Service Window, binnen de Reactietijd + Oplostijd na de Incident Melding, opgelost. |
3.10 Back-up en recovery procedure
De Back-up en recovery van de gegevens is als volgt door KIREMA geregeld.
• Frequentie:
Dagelijks wordt een volledige Back-up gemaakt
• Medium:
Er wordt een Back-up gemaakt op de harde schijven van een fysiek andere server, die op een andere locatie staat.
● Bewaartermijn:
De Back-up wordt gedurende de navolgende termijn bewaard: 2 weken.
gezamenlijk overleg nadere afspraken maken over de te hanteren recovery procedure. Facturatie voor de recovery procedure door KIREMA geschiedt op basis van nacalculatie.
3.11 Onderhoud, Gepland Onderhoud en Nood Onderhoud
Voor alle vitale onderdelen van de centrale infrastructuur van KIREMA geldt dat preventief en gepland Onderhoud op tijden plaats zal vinden wanneer de gebruikers er zo weinig mogelijk last van hebben en wordt van tevoren gemeld aan de opdrachtgever.
Onderhoud
KIREMA beoogt om bij onderhoudswerkzaamheden aan haar netwerk, servers of andere relevante Apparatuur de merkbare invloed op de dienstverlening richting de klant tot het uiterste minimum te beperken door de volgende maatregelen te hanteren:
● belangrijke handelingen worden, voor zover mogelijk, buiten kantoortijden uitgevoerd;
● merkbare onderhoudswerkzaamheden worden tot een absoluut noodzakelijk minimum beperkt;
● onderhoudswerkzaamheden zullen zoveel mogelijk worden gecombineerd.
Tijdens het Onderhoud kan er merkbare invloed zijn op de dienstverlening (prioriteitsniveau 2 of 3), KIREMA spant zich in dat er geen uitval van de dienst zal plaatsvinden (prioriteitsniveau 1).
Gepland Onderhoud kan op elk moment plaatsvinden. De opdrachtgever wordt voorafgaand hieraan geïnformeerd. Het is mogelijk dat tijdens deze onderhoudsperiode de hosting dienst tijdelijk geheel of gedeeltelijk buiten gebruik is en daardoor niet beschikbaar is voor de opdrachtgever (Prioriteitsniveau 1: uitval van de dienst)..
Een bericht van gepland Onderhoud zal de volgende informatie bevatten:
● gegevens Contactpersoon;
● tijdskader waarin het gepland Onderhoud zal plaatsvinden;
● verwachte feitelijke duur van het gepland Onderhoud;
● de diensten waarop het geplande Onderhoud van invloed zal zijn;
● prioriteitstelling;
Gepland Onderhoud is uitgesloten van de Beschikbaarheidberekeningen tenzij de periode voor het geplande Onderhoud wordt overschreden en de hosting dienst daardoor voor de klant niet beschikbaar is.
Nood Onderhoud kan nodig zijn wanneer omstandigheden onmiddellijk ingrijpen vereisen. In een dergelijke situatie wordt de klant zo spoedig mogelijk geïnformeerd (zie: responsetijden).
Onbeschikbaarheid tijdens Nood Onderhoud telt mee in de beschikbaarheidberekening.
3.12 Beschikbaarheid
Voor de Beschikbaarheid van de hostingomgeving inclusief systeemsoftware geldt een garantie zoals is opgenomen in onderstaand tabel op maandbasis. De procedure voor het beschikbaar stellen van het
KIREMA garandeert niet dat er altijd communicatie over het internet mogelijk is of dat er altijd een verbinding tot stand kan worden gebracht met een
andere machine aangesloten op het internet. Er is sprake van Onbeschikbaarheid als een hosting dienst van KIREMA als gevolg van niet geplande gebeurtenis voor geen enkele gebruiker bruikbaar is. Als een dienst slechts voor bepaalde gebruikers onbruikbaar is, of niet correct functioneert, is er sprake van een Incident waarbij de dienst op zich als beschikbaar wordt aangemerkt.
De verantwoordelijkheid van KIREMA met betrekking tot Beschikbaarheid zoals geformuleerd in deze SLA zijn niet van toepassing op Storingen indien:
• geplande werkzaamheden worden uitgevoerd;
• de Storing optreedt als gevolg van Storing in de telecommunicatieinfrastructuur van derden;
• een uitval veroorzaakt wordt door een door de aangevraagde Xxxxxxxxx van opdrachtgever;
• een uitval veroorzaakt wordt door ongeautoriseerde Wijzigingen door personeel van de opdrachtgever in de Apparatuur van KIREMA;
• overmacht.
Voor diensten, op één locatie of meerdere locaties, wordt de Beschikbaarheid (A) als volgt berekend:
A = 100% * [1 – (t : T)]
t = het aantal minuten dat de Dienst gedurende de Maand niet beschikbaar was (Uitval van de Dienst)
T = totaal aantal minuten per Maand
Onderdeel | Beschikbaarheid |
KIREMA Cloud | 99,8% |
3.13 Veiligheid en betrouwbaarheid
KIREMA geeft geen garanties en aanvaardt geen aansprakelijkheid met betrekking tot de veiligheid van netwerkverbindingen en opgeslagen gegevens. KIREMA zal zich inspannen om fysieke en logische toegang tot gegevens door onbevoegden te voorkomen en om informatie van opdrachtgever geheim te houden.
4.1 Doel
Incident Management heeft tot doel (dreigende) verstoringen in de dienstverlening aan opdrachtgever zo snel mogelijk te verhelpen. De opdrachtgever moet zo min mogelijk hinder van Storingen ondervinden en zo snel mogelijk met de normale werkzaamheden door kunnen gaan.
Dit wordt gedaan door het aannemen, beoordelen, oplossen en afmelden van Meldingen van opdrachtgever.
4.2 Invoer
Melding van opdrachtgever. Deze gaat via de Contactpersoon van opdrachtgever naar de Contactpersoon van KIREMA.
De Melding moet de volgende onderdelen bevatten:
• naam melder;
• telefoonnummer en e-mailadres melder;
• de datum (evt. tijdstip) waarop het Incident ontstaan is;
• omschrijving van het Incident;
• module waar het Incident zich voordoet;
• een geschatte Prioriteit van opdrachtgever.
4.3 Uitvoer
Na het ontvangen van de Melding zal KIREMA een melding terug geven waarin de prognose van KIREMA vermeld staat. In de prognose moet de urgentie, Prioriteit en verwachte oplostijd vanuit KIREMA vermeld worden.
Na het afhandelen van het Incident zal er een terugkoppeling over het verholpen Incident naar de Incidentmelder gedaan worden.
4.4 Proces en uitvoerende Partijen
Processtap | Omschrijving | Resultaat | Uitvoerend |
Registreren & Classificeren | De opdrachtgever wordt gehoord, zijn Melding wordt geïnterpreteerd. | interpretati e Xxxxxxx | XXXXXX en Opdrachtgever |
Onderzoeken & Initiëren | De verantwoordelijke voor het bieden van de oplossing wordt bepaald. De opdrachtgever wordt geïnformeerd over de voorgenomen oplosactie. De verantwoordelijke kan zijn: 1. KIREMA zelf; 2. een andere partij; kan ook een partij zijn waarmee opdrachtgever een afspraak heeft. | oplosactie bepaald en uitgezet | KIREMA |
Oplossen & Herstellen | Verantwoordelijke KIREMA: de actie wordt uitgevoerd conform de bij KIREMA gebruikelijke wijze. Verantwoordelijke andere partijen: de actie valt verder niet onder deze SLA; KIREMA zal de Call doorgeleiden naar de derde die voor oplossing kan zorgdragen. | opgelost Incident | KIREMA, derde partijen |
Afsluiten | Indien het Incident is opgelost, wordt dit gemeld. | afgesloten Melding | KIREMA |
Norm | |
Service Window | Op werkdagen, kantoortijden 8:00 – 17:30 uur (Central European Time) |
Transferred Calls | KIREMA zal gedurende Service Window binnen de Reactietijden conform de gestelde Prioriteit, de Calls routeren naar de derde partij die verantwoordelijk is voor oplossing van het Incident. |
Reactietijd | Tijden worden bepaald door de Prioriteit (zie toelichting Prioriteiten tabel, bepaling 3.7 SLA). |
Workaround | Het Incident wordt zo opgelost dat de eindopdrachtgever binnen het primaire proces verder kan werken zonder significant tijdsverlies. Het achterliggende probleem wordt via het proces Probleem Management structureel opgelost. |
4.6 Contact
Het type contact bij Melding van een Incident is vastgelegd in onderstaande tabellen
Melden
Service window | |
Prioriteit 1 | Noodnummer |
Prioriteit 2 | Noodnummer |
Prioriteit 3 | Kantooruren |
Contact types
Type contact | Toelichting |
Normaal contact | Servicedesk van KIREMA (bepaling 3.2 SLA) |
Noodnummer | Dit nummer is bekend bij opdrachtgever centrale Contactpersoon voor KIREMA |
Servicedesk van KIREMA (bepaling 3.2 SLA) | |
N.v.t. | Meldingen met deze Prioriteit worden niet binnen dit service window in behandeling genomen |
Workaround
Het Incident wordt zo opgelost dat de eindopdrachtgever op acceptabele wijze verder kan werken. Het achterliggende probleem wordt via het proces Probleem Management structureel opgelost.
4.7 Voorwaarden en uitsluitingen
• KIREMA is niet bereikbaar op tijdstippen die buiten het Service Window vallen, tenzij anders overeengekomen of voor Meldingen met Prioriteit 1 en 2.
• Calls ingediend buiten de toepasselijke service window worden op de eerst volgende Werkdag in behandeling genomen.
• Alle Calls veroorzaakt door herhaald of stelselmatig onkundig gebruik van Apparatuur en/of programmatuur door medewerkers van opdrachtgever worden via de reguliere rapportages door KIREMA direct aan opdrachtgever geëscaleerd.
• Calls die, in overleg met opdrachtgever, op ‘on-hold’ zijn gezet vallen buiten de overeengekomen Service Levels.
• Indien een Incident leidt tot een Request for Change (RfC) dan gelden de afgesproken doorlooptijden van het Change Management proces.
• Opdrachtgever dient zorg te dragen in haar contracten met derde partijen dat KIREMA geïnformeerd wordt over status en voortgang van de naar die partijen doorverwezen Calls.
5.1 Doel
Het doel van probleem management is het verhogen van de kwaliteit van de ICT infrastructuur door Incidenten op hun oorzaak te onderzoeken en de oorzaken te laten wegnemen. Met andere woorden is het doel van het probleem management het structureel oplossen van Incidenten met de status “Workaround” en hier lering uit trekken om daarmee verbetervoorstellen uit te brengen.
5.2 Invoer
• Incident met de status “Workaround”
• Lijst van Incidenten per categorie.
5.3 Uitvoer
• Bij aanvang een Melding van aanvang richting Contactpersoon opdrachtgever
• Een opgelost probleem
• Eventueel verdere voortgang rapportages betreffende het probleem
5.4 Proces en uitvoerende partijen
Processtap | Omschrijving | Resultaat | Uitvoerend |
Registreren & Classificeren | De invoer (zie boven) wordt beoordeeld en geïnterpreteerd. Vervolgens wordt een ‘Probleem Record’ aangemaakt in het systeem met een prioriteitscode. | vastgelegd probleem | KIREMA en Opdrachtgever |
Organiseren & Initiëren | Voor het oplossen van het probleem wordt een voorstel bepaald en uitgezet. | voorstel bepaald en uitgezet | KIREMA |
Analyse | Probleem wordt volgens voorstel onderzocht en de oorzaak wordt, waar nodig in samenwerking met derden, achterhaald. Eventueel wordt gecommuniceerd met de opdrachtgever indien hij betrokken moet worden in de uitvoering. | oorzaak van probleem | KIREMA |
Afsluiten | Indien het probleem is op te lossen wordt op basis van Probleem Record een Wijziging: RfC aangemaakt. | RfC aangemaakt | KIREMA |
5.5 Formele afspraken tussen KIREMA en opdrachtgever
Service Level | Norm |
Service Window | Op werkdagen, kantoortijden 8:00 – 17:30 uur (Central European Time) |
Doorlooptijd | KIREMA garandeert dat 50% van het Maandelijkse totaal van de geregistreerde problemen binnen de waardes van de Reactietijden tabel Probleem Management is opgelost. |
6.1 Doel
Het doel van Change management is het planmatig doorvoeren van alle Wijzigingen in de ICT infrastructuur. Daarbij worden de risico’s op verstoring van de diensten en daarmee het verlagen van de kwaliteit van de geleverde diensten zo beperkt mogelijk gehouden.
6.2 Invoer
Request for Change (RfC) ingediend zijn door:
• geautoriseerde personen van opdrachtgever;
• KIREMA (probleem- en alle tactische processen die invloed hebben op de bedrijfsvoering van opdrachtgever).
Binnen het RfC moeten de volgende punten weergegeven worden:
• naam aanvrager;
• telefoonnummer aanvrager;
• e-mail adres aanvrager;
• bedrijfsonderdeel aanvrager;
• identificatie van de Prioriteit van het RfC;
• omschrijving RfC.
6.3 Uitvoer
• uitgevoerde Change, opgelost probleem;
• zonodige voortgangsrapportages.
6.4 Proces en uitvoerende partijen
Processtap | Omschrijving | Resultaat | Uitvoerend |
Registreren & Classificeren | Het verzoek om een Wijziging (Request for Change) door te voeren in de IT Infrastructuur wordt in het systeem geregistreerd. Tevens wordt het type Change bepaald door overeenstemming van aanvrager en ontvanger: Standard, Minor of Major Change (Zie voor definities bepaling 6.5 SLA). | geregistreerd verzoek | KIREMA en Opdrachtgever |
Beoordelen & plannen | • Minor Changes worden beoordeeld door KIREMA, of deze passen in het product, gepland en geïnitieerd. • Major Changes worden beoordeeld door KIREMA, of deze passen in het product en besproken in het Maandelijkse overleg. | implementatie plan voor de Change | KIREMA en Opdrachtgever |
Uitvoeren | • Standard Changes worden direct uitgevoerd en getest. • Minor Changes worden volgens afspraak uitgevoerd en getest. De kosten voor de Minor Change zijn op basis van nacalculatie . • Major Changes worden qua uitvoering voorgelegd en goedgekeurd door opdrachtgever. De kosten voor het uitvoeren van de Major Change zijn op basis van nacalculatie dan wel aparte offerte. | geïmplemente erde Change | KIREMA |
Afsluiten & evalueren | De Change wordt geëvalueerd en afgesloten als ‘compleet’ in het systeem. Het resultaat van de wijziging wordt gecontroleerd aan de hand van de RfC en het gemaakte plan. | afgesloten Change | KIREMA en Opdrachtgever |
Definitie | |
Standard Change | Standard Changes betreffen veranderingen waarvoor geen autorisatie van opdrachtgever noodzakelijk is en welke direct uitgevoerd worden. Deze veranderingen hebben geen impact op de hosting diensten, maar wel op de invulling daarvan (administratieve taken). |
Minor Change | Minor Changes zijn vooraf gedefinieerde Changes welke enkel door geautoriseerde personen aangemeld kunnen worden. Het betreft hier triviale en/of erg kleine Wijzigingen van de hosting diensten. |
Major Change | Major Changes worden qua uitvoering voorgelegd door KIREMA en goedgekeurd door opdrachtgever. Het betreft hier ingrijpende en/of grootschalige Wijzigingen in de hosting diensten. |
6.6 RFC Prioriteiten tabel
Bij de aanname van de RfC wordt volgens onderstaande tabel een Prioriteit toegekend aan de RfC. Voor die RfC’s welke worden ingediend voor implementatie van de oplossing van een Incident en waarvoor conform het Incidentproces een Prioriteit is toegekend, is de voor het Incident gestelde Prioriteit in principe bepalend voor de Prioriteit van de Change. Indien een Workaround beschikbaar is kan in afwachting van een structurele definitieve oplossing de Prioriteit van de Change afwijkend zijn.
Prioriteit | Betekenis |
1 | De RfC betreft een probleem dat bij de opdrachtgever aanzienlijke hinder veroorzaakt in het gebruik van essentiële diensten (het primaire proces is ernstig verstoord), of het betreft een dringend gewenste aanpassing ter voorkoming van een calamiteit. |
2 | Geen grote urgentie of hoge impact, maar implementatie van de Change mag niet worden uitgesteld tot een later tijdstip. |
6.7 Reactietijden
Prioriteit | Reactietijd | Betekenis |
1 | 1 uur na melding | De RfC wordt buiten de reguliere Change Management procedures om in behandeling genomen; binnen het geldende Service Window. Administratieve afhandeling volgt later. |
2 | 8 uur na melding | De RfC wordt, binnen het geldende Service Window, binnen de reactietijd in behandeling genomen. |
6.8 Formele afspraken tussen KIREMA en opdrachtgever
Service Level | Norm |
Service Window | Service Window is van toepassing. |
Aanleveren van RfCs. | Door opdrachtgever gewenste Changes kunnen op Werkdagen tijdens Kantooruren worden aangemeld. Is de aanvraag buiten deze window, dan zal de aanvraag de volgende dag in behandeling genomen worden. |
Aanvraag Standard, Minor en Major Changes | Minor en Major Changes worden aangevraagd via officiële zogeheten RfC formulieren door daartoe geautoriseerde personen binnen de organisatie van opdrachtgever en KIREMA. |
Reactietijd | KIREMA garandeert dat 50% van het Maandelijkse totaal van de Minor en Major Changes binnen de waardes van de Reactietijden tabel (tabel 6.7) in behandeling is genomen |
Infrastructuur die onder de verantwoordelijkheid valt van de opdrachtgever valt mag pas na schriftelijke toestemming van KIREMA worden doorgevoerd en dienen binnen 10 Werkdagen voor de Wijziging door middel van het officiële RfC formulier aan KIREMA te worden doorgegeven.
KIREMA erkent het belang van een zeer scherpe beveiliging van de omgeving van de afnemer. KIREMA houdt zich regelmatig op de hoogte van de laatste informatie omtrent beveiliging. Ten einde een optimale beveiliging te garanderen nemen KIREMA en opdrachtgever de onderstaande maatregelen:
● Opdrachtgever is verantwoordelijk voor de personen die zij door middel van het verlenen van autorisatie, toegang verschaft tot de Software die behoort tot de Systeemomgeving alsmede de applicaties. Opdrachtgever en KIREMA zullen in gezamenlijk overleg nadere afspraken maken over te hanteren regels en richtlijnen ten aanzien van het door opdrachtgever gewenste beveiligingsbeleid.
● KIREMA zal bijhouden, welke medewerkers authenticaties en autorisaties mogen aanpassen op de omgeving van de opdrachtgever.
● Indien een server is getroffen door een beveiligingsincident, zal KIREMA beraadslagen wat de te volgen stappen zijn, indien het nodig is zullen patches op korte termijn geïnstalleerd worden. Indien hierbij onderbreking van de service van KIREMA plaatsvindt dan wordt opdrachtgever onverwijld hiervan op de hoogte gesteld.
● In het geval van ernstige security problemen, in hardware of software, zal KIREMA beraadslagen wat de te volgen stappen zijn. Indien het nodig is, zullen patches op korte termijn geïnstalleerd worden. Wanneer dit niet toereikend blijkt te zijn zal KIREMA na overleg overgaan tot het opnieuw inrichten van de server. Indien hierbij onderbreking van de service van KIREMA plaatsvindt dan wordt opdrachtgever onverwijld hiervan op de hoogte gesteld.
● KIREMA verleent haar medewerking aan security audits en penetration tests, mits deze de beschikbaarheid van de dienstverlening van KIREMA niet in gevaar brengen; zulks ter beoordeling door KIREMA. De kosten van een security audit en penetration test zijn voor opdrachtgever. Verzoeken moeten minstens 2 maanden voorafgaande aan de geplande audit of penetration test schriftelijk worden ingediend.