4 Basisnormen beheerprocessen

Transcriptie

1 4.1 Inrichting processen 1 Hoofddoelstelling De hoofddoelstelling van Inrichting processen is het stellen van algemene voorwaarden aan de procesgerichte uitvoering van beheer- en exploitatieactiviteiten en het weergeven van basisnormen die de onderscheiden processen overkoepelen of generiek zijn voor veel voorkomende subprocessen. 2 Belang voor beveiliging Het geheel van de onderscheiden beheer- en exploitatieprocessen wordt uitgevoerd in een organisatie, waaraan een aantal eisen gesteld moeten worden om te borgen dat deze processen aan hun doelstellingen en basisnormen kunnen blijven voldoen. Zonder een juiste inbedding van de processen in de organisatie en handhaving van een aantal basisvoorwaarden voor processen bestaat het risico dat afgeweken wordt van doelstellingen en basisnormen zonder dat een risicoafweging plaatsvindt en hieraan een onderbouwde managementbeslissing ten grondslag ligt. 3 Afbakening De basisnormen in dit hoofdstuk hebben uitsluitend tot doel randvoorwaarden te stellen aan de beheer- en exploitatieprocessen als basisniveau van algemene beheersing opdat de meer specifieke normen per proces tot hun recht kunnen komen. 4 Beheerdoelstellingen 1 het definiëren van verantwoordelijkheden en functiescheidingen; 2 het stellen van algemene normen voor het inrichten van processen; 53

2 Basisnormen Beveiliging en Beheer ICT-infrastructuur 54 3 het stellen van algemene normen voor het rapporteren over de werking van processen; 4 het stellen van algemene normen voor het bewaren van basisregistraties; 5 het stellen van algemene normen voor interne controle. 5 Normen Organisatie 1 Aan (alle componenten van) de ICT-infrastructuur is een eigenaar toegewezen, die verantwoordelijk is voor het handhaven van de juiste beveiligingsmaatregelen met betrekking tot (die component van) de ICT-infrastructuur (zie hoofdstuk 2). De verantwoordelijkheid voor het implementeren en monitoren van de beveiligingsmaatregelen mag worden gedelegeerd. 2 Er is een scheiding aangebracht tussen de volgende essentiële activiteiten in de ITIL-processen: a beschikkende functies en daarbinnen tussen: Service Level Management; de tactische Service Planning-processen; Change Management; Supply Management; b bewarende/operationeel beherende functies en daarbinnen tussen: het gegevensbeheer van identificerende en classificerende gegevens van alle beheerregistraties; het beheer van computerruimten en ICT-componenten bij Operations; het bewaken van de integriteit van de administratie van CI s bij Configuration Management; het beheer van de registraties voor Incident Management; het beheer van known errors bij Problem Management; het beheer van de registraties voor Change Management; c registrerende functies, zoals het registreren van: CI s door Configuration Management; opdrachten door Service Desk;

3 incidenten door Incident Management; changes door Change Management; programma s/releases door Release Management; d uitvoerende functies; e controlerende functies. 3 Bij vervangingsregelingen mogen de functiescheidingen niet worden doorbroken. 4 Bij nood- of escalatieregelingen mogen de functiescheidingen alleen worden doorbroken door de hogere managementlaag, waarbij dit onverwijld schriftelijk wordt vastgelegd. Na afloop van de calamiteit wordt onafhankelijk nagegaan of er geen compromitage heeft plaatsgevonden en of de functiescheiding (bijvoorbeeld wijzigen alle wachtwoorden) ten volle hersteld is. 5 Medewerkers van de exploitatieorganisatie hebben geen toegang tot gebruikersfuncties en productiegegevens van klanten, tenzij zij expliciet door de eigenaar van de informatiesystemen zijn geautoriseerd. 6 Er zijn waarborgen dat wijzigingen in de organisatie door Security Management worden getoetst aan het overeengekomen beveiligingsniveau. Procesinrichting 7 Taken, bevoegdheden en verantwoordelijkheden van functies/rollen zijn vastgelegd en bekend. 8 De verantwoordelijkheid voor de inrichting en werking van de processen (eventueel procesdelen) wordt expliciet toegewezen in de organisatie. 9 Per proces zijn er actuele procesbeschrijvingen, systeembeschrijvingen van ondersteunende beheersystemen en werkinstructies aanwezig. 10 Om de kwaliteit van beschrijvingen en voorschriften te waarborgen, worden eisen gesteld op het gebied van: a indeling en structuur; b het aantonen hoe rekening is gehouden met in- en/of externe richtlijnen, zoals de PI-normen (afwijkingen altijd motiveren); 55

4 Basisnormen Beveiliging en Beheer ICT-infrastructuur 56 c formele accordering door eigenaren van de ICT-Services, CI s of andere objecten respectievelijk processen; d controleerbaarheid; e versiebeheer. 11 Per proces zijn Key Performance Indicatoren (KPI s) gedefinieerd. 12 De logische samenhang tussen de identificerende en classificerende gegevens in de beheerregistraties voor de verschillende beheerprocessen wordt centraal bewaakt. 13 Er wordt (onder meer door opleiding, instructie en voorlichting) zorg gedragen voor voldoende bewustwording bij de leiding en medewerkers op het gebied van de procesinrichting, afbakening en samenhang van processen en beveiligingsaspecten van processen. 14 Binnen de beheerprocessen worden de bevoegdheden bij incidenten voor het tijdelijk onderbreken van de serviceverlening, het communiceren met anderen binnen de exploitatieorganisatie en met de klantorganisatie, alsmede het in gang zetten van nood- of escalatieprocedures éénduidig belegd. Deze bevoegdheden zijn niet strijdig met bevoegdheden van het lijn- en/of procesmanagement. Datzelfde geldt voor de bevoegdheden van overlegorganen (bijvoorbeeld Change Advisory Board). 15 Het tactische beveiligingsnormenkader wordt door de proceseigenaren vertaald naar operationele maatregelen. 16 Er zijn waarborgen dat wijzigingen in de processen door Security Management worden getoetst aan het overeengekomen beveiligingsniveau. 17 Brongegevens, zoals werkopdrachten, interne registraties en overige documenten, worden minimaal één jaar na afloop van het jaar waarin de opdrachten zijn afgesloten, bewaard ten behoeve van interne controledoeleinden. Procesevaluatie 18 Per proces wordt periodiek gerapporteerd over Key Performance Indicatoren (KPI s), over de naleving van de beheernormen, de voortgang van jaarplanning en procesverbeteringen.

5 19 Rapportage vindt plaats overeenkomstig de afspraken aan Service Level Management en het eigen ICT-management. 20 Naast de rapportage-items gedurende de rapportageperiode, wordt er bij voorkeur ook een trendmatig overzicht over de huidige en daaraan voorafgaande periodes weergegeven. 21 Bij gebruik van kengetallen is vermeld hoe deze zijn berekend en zijn gehanteerde begrippen eenduidig gedefinieerd. 22 Afwijkingen ten opzichte van de norm en/of trendbreuken worden verklaard, waarbij tevens wordt vermeld welke acties in gang zijn gezet om de dienstverlening naar het gewenste niveau terug te brengen. 23 De juistheid van de gerapporteerde cijfers is controleerbaar. 24 Per proces wordt door onafhankelijke, interne controleurs volgens een Intern Controle Programma controle op naleving van de procesnormen uitgeoefend. 25 Over de resultaten van de controlewerkzaamheden wordt periodiek gerapporteerd aan het verantwoordelijk lijn- en procesmanagement. 26 Over het tijdig oplossen van negatieve bevindingen worden afspraken gemaakt en verantwoording afgelegd. 6 Procesrelaties Dit proces levert normen op voor alle andere processen. Dit wordt verder niet als input bij de andere processen aangegeven Service Level Management 1 Hoofddoelstelling Service Level Management is verantwoordelijk voor het proces van het onderhandelen, definiëren, meten, beheersen en verbeteren van de kwaliteit van de ICT-dienstverlening. Dit proces is belast met het vinden van het evenwicht tussen vraag en aanbod van ICT-diensten en formaliseert dit door Service Level Agreements op te stellen, af te sluiten en te onderhouden. 2 Belang van het proces voor beveiliging Het proces Service Level Management zorgt ervoor dat formele, haalbare en meetbare afspraken worden vastgelegd over het door

6 Basisnormen Beveiliging en Beheer ICT-infrastructuur 58 de ICT organisatie te leveren beveiligingsniveau. Daarnaast zorgt dit proces ervoor dat afspraken en procedures worden vastgelegd voor operationele beveiligingsaangelegenheden als het melden van beveiligingsincidenten en het plaatsen van opdrachten. 3 Afbakening Tot het proces Service Level Management wordt niet gerekend het inregelen van dienstverlening tussen de ICT-organisatie en haar externe leveranciers (afsluiten underpinning contracts ) gerekend. Dit is om pragmatische reden, kijkend naar de praktijk in grotere organisaties binnen het proces Supply Management gepositioneerd. Er is voor gekozen om het inhoudelijk definiëren van het te leveren service level bij de andere processen onder te brengen, omdat die voor het feitelijke leveren van de prestaties verantwoordelijk zijn. In elk van de processen zijn daartoe onder het kopje Definiëren service level aparte basisnormen opgenomen. De ICT-Service Manager is eindverantwoordelijk voor de afspraken die met klanten worden gemaakt. 4 Beheerdoelstellingen 1 Zorgen dat de behoeften van de klantenorganisatie worden vertaald naar duidelijke, technisch uitvoerbare en economisch verantwoorde service levels. 2 Het afgesproken service level bewaken. Het signaleren van afwijkingen en het initiëren van verbeteracties wanneer onder het afgesproken niveau wordt gepresteerd. 3 De geleverde service evalueren. Zorgen dat het service level afgestemd blijft op de behoeften van de klantenorganisatie en de mogelijkheden van de ICT-organisatie. 5 Normen Algemene inhoud SLA s 1 Service Level Agreements (SLA s) en onderliggende documenten als een Dossier Afspraken en Procedures (DAP), worden schriftelijk vastgelegd, van versie/statusinformatie voorzien en door daartoe bevoegde vertegenwoordigers van de klantenorganisatie en de ICT-organisatie onderteken. 2 Voor wijzigingen op het SLA en onderliggende documenten geldt een formele wijzigingsprocedure die in het SLA is vastgelegd.

7 3 De taken en verantwoordelijkheden van klantenorganisatie en ICT-organisatie en de escalatieprocedures zijn duidelijk afgebakend en in het SLA vastgelegd. 4 In het SLA zijn per proces performance-indicatoren opgenomen aan de hand waarvan bepaald kan worden of de dienstverlening conform het overeengekomen kwaliteitsniveau is geleverd. 5 In het SLA is vastgelegd hoe over het voldoen aan deze performance-indicatoren periodiek, in voor de klantenorganisatie begrijpelijke termen, wordt gerapporteerd. 6 Als in de SLA s wordt verwezen naar standaard diensten (Standaard Service Levels of Service Catalog), gelden daarvoor de hiervoor genoemde normen. Contracteren 7 Alle, door de exploitatieorganisatie geleverde diensten dienen aan het proces voor SLM te zijn onderworpen, zowel diensten die extern worden geleverd (al dan niet direct) als diensten die intern worden geleverd. 8 De ICT-organisatie beheert de afgesloten SLA s (heeft daarvoor contractbeheer ingericht) en onderneemt tijdig stappen om SLA s aan wijzigingen in de ICT-dienstverlening aan te passen. Voor dit laatste geldt een formele wijzigingsprocedure die in het SLA is vastgelegd. 9 Uit de registratie ten behoeve van SLM dient te blijken dat voor afsluiting van een SLA, afstemming heeft plaatsgevonden met betrokkenen ten aanzien van de haalbaarheid van afgesproken dienstenniveaus. 8 Beëindigde en te beëindigen SLA s dienen herkenbaar te zijn in de registratie. 9 Het Service Level Management zorgt ervoor dat de voor levering van diensten verantwoordelijke beheerprocessen over actuele versies van de geldende Service Level Agreements en Standaard Service Levels kunnen beschikken. Monitoren 10 Het te leveren service level, de performance-indicatoren waarmee dit wordt gemeten en de wijze waarop hierover wordt gerapporteerd, is van tevoren afgestemd met de tacti- 59

8 Basisnormen Beveiliging en Beheer ICT-infrastructuur 60 sche en operationele beheerprocessen die voor levering verantwoordelijk zijn. Ditzelfde geldt voor wijzigingen. 11 De Service Level Manager bewaakt op grond van de Service Level Rapportage van de verschillende beheerprocessen de algehele kwaliteit van de afgesproken ICT-dienstverlening en zorgt ervoor dat de verschillende betrokken beheerprocessen zonodig verbeteracties initiëren en dat deze verbeteracties op elkaar worden afgestemd (via het Change Management-proces, of eventueel via afzonderlijke dienstgerichte overleggroepen). Rapporteren over de service levels 12 De Service Level Manager stelt periodiek een Service Niveau Rapportage op, waarin wijzigingen in de portefeuille, alsmede overschrijdingen van afgesproken dienstenniveaus, inclusief verklaringen zijn opgenomen. 13 Rapportages zijn niet alleen repressief, maar ook pro-actief van aard om toekomstige knelpunten te identificeren en gezamenlijk de prioriteit te kunnen formuleren ten aanzien van toekomstige wijzigingen. Evalueren 14 De Service Level Manager zorgt ervoor dat wijzigingen in de behoeften van de klantenorganisatie worden geïnventariseerd en tijdig (pro actief) naar wijzigingsvoorstellen voor de ICT-service worden vertaald. 15 De Service Level Manager zorgt ervoor dat de (perceptie van de) volgens de SLA geleverde kwaliteit bij de klantenorganisatie regelmatig wordt gemonitord en onderneemt tijdig stappen om de ICT-dienstverlening aan te passen (bij te lage eigen performance) dan wel om te overleggen met de klant (bij juiste SLA performance, maar verkeerde perceptie daarvan bij de afnemer(s)). 6 Procesrelaties De volgende procesrelaties worden als basisnorm ingevuld. Availability Management, Capacity Management, ICT Service Continuity Management, Security Management, Service Desk, Incident Management, Change Management en Operations.

9 Krijgen: verzoeken om onderdelen van service level agreements of standaard service levels uit te werken; verzoeken om de haalbaarheid van door de klantenorganisatie gewenste service levels te toetsen; afgesloten SLA s. Leveren: conceptteksten voor onderdelen van SLA s en standaard service levels; haalbaarheidstudies; onderdelen van de service level rapportage; voorstellen voor aanpassing van SLA s of standaard service levels. Release Management informatie over beschikbaarstelling programmatuur en apparatuur. niets Availability Management 1 Hoofddoelstelling Het beschikbaarstellen en beschikbaar houden van ICT-diensten overeenkomstig de daarvoor afgesproken Service Level Agreements (SLA s). Toelichting Availability Management richt zich op het registreren en rapporteren van de beschikbaarheid van de ICT-dienstverlening en het initiëren van technische aanpassingen in de ICT-infrastructuur om de beschikbaarheid op peil te houden of verder te verbeteren. 2 Belang van het proces voor beveiliging Binnen de ITIL-procesindeling is het Security Management-proces niet volledig verantwoordelijk voor het kwaliteitsaspect beschikbaarheid (availability), maar steunt het Security Management voor de borging van de beschikbaarheid van de ICT-dienstverlening op het proces Availability Management.

10 Basisnormen Beveiliging en Beheer ICT-infrastructuur 62 3 Afbakening Availability Management houdt zich niet bezig met het nietbeschikbaar zijn van ICT-services als gevolg van calamiteiten. Het beheersen van het calamiteitensituaties behoort tot het proces ICT Service Continuity Management. 4 Beheerdoelstellingen 1 Duidelijke en haalbare afspraken over het haalbare beschikbaarheidsniveau definiëren ten behoeve van het nakomen van de SLA s. 2 Gegevens over de gerealiseerde beschikbaarheid verzamelen, vastleggen en rapporteren. 3 Toetsen of het afgesproken beschikbaarheidsniveau is gerealiseerd en afwijkingen rapporteren. 4 Ontwikkelingen in de ICT-infrastructuur toetsen. 5 Voorstellen doen om de beschikbaarheid van de ICT-diensten op peil te houden of verder te verbeteren (opstellen en uitvoeren beschikbaarheidsplan). 5 Normen 5.1 Tactisch deel van het proces Definiëren service level 1 In de SLA s is een beschikbaarheidsparagraaf opgenomen waarin is vastgelegd: a op welke onderdelen van de dienst het afgesproken beschikbaarheidsniveau precies betrekking heeft (bijvoorbeeld in de vorm van een configuratieschema); b op welke tijdsperiode het afgesproken beschikbaarheidsniveau betrekking heeft (bijvoorbeeld alleen op werkdagen van 8.00 tot uur, niet in weekeinden, niet op algemene feestdagen of 7x24 uur); c welke periode voor gepland onderhoud beschikbaar is ( onderhoudswindow ) en of niet-beschikbaarheid vanwege gepland onderhoud wel of niet meetelt in het afgesproken beschikbaarheidspercentage; d wat de maximaal toelaatbare storingsduur is; e wat het maximaal toelaatbaar aantal storingen is; f wat het totaal te leveren beschikbaarheidspercentage is en hoe dit wordt berekend;

11 g met welke frequentie en welke vorm over de werkelijk geleverde beschikbaarheid wordt gerapporteerd. 2 De ICT-organisatie toetst van tevoren de in SLA s vast te leggen beschikbaarheidafspraken op uitvoerbaarheid en duidelijkheid. Indien een bepaald gewenst beschikbaarheidsniveau niet, of pas op termijn, leverbaar is, wordt de klantenorganisatie hier van tevoren over geïnformeerd. 3 Bij het vaststellen van het te leveren beschikbaarheidsniveau is rekening gehouden met alle betrokken ICT-componenten (ketenbenadering). Maken afspraken met leveranciers 4 Op grond van de in de SLA s vastgelegde beschikbaarheidverplichtingen is vastgesteld of er een onderhouds/servicecontract voor de bij de dienst gebruikte ICT-componenten afgesloten moet worden. 5 Aard en reikwijdte van de onderhoudsverplichting zijn duidelijk in het contract vastgelegd. Daarbij is expliciet bepaald of er ter attentie van het herstel van storingen/gebreken sprake is van een inspanningsverplichting (de leverancier verplicht zich binnen een zekere tijd te beginnen met de reparatie) of van een resultaatverplichting (de leverancier garandeert dat de storingen altijd binnen X-uur zijn verholpen). 6 Het nakomen van onderhoudsverplichtingen wordt bewaakt. Afwijkingen van de afgesproken termijn worden geregistreerd en met de leverancier besproken. Plannen van de beschikbaarheid 7 Availability Management beoordeelt de invloed van wijzigingen in de ICT-infrastructuur. 8 Het proces zorgt ervoor dat deze ontwikkelingen worden vertaald naar een beschikbaarheidsplan dat wijzigingsvoorstellen, investeringsvoorstellen en andere acties bevat om de beschikbaarheid op de langere termijn op niveau te houden of verder te verbeteren. 9 Availability Management bewaakt de uitvoering van dit plan en stelt het zonodig bij. Availability Management toetst voorstellen voor nieuwe diensten en andere wijzingen op beschikbaarheidsconsequenties en onderneemt acties als de 63

12 Basisnormen Beveiliging en Beheer ICT-infrastructuur 64 beschikbaarheidsrisico s van wijzigingen onvoldoende zijn beheerst. 5.2 Operationeel deel van het proces Meten en analyseren beschikbaarheid 10 Availability Management beschikt over overzichten van de technische componenten waaruit de diensten zijn opgebouwd en de relaties daartussen (bijvoorbeeld uit de CMDB). 11 Voor elke bij de dienst betrokken component zijn voorzieningen aanwezig om gegevens over de (niet-) beschikbaarheid te registreren en te verzamelen. Hierbij is per object vastgelegd hoe (niet-) beschikbaarheid wordt gemeten (bijvoorbeeld op grond van gemelde incidenten, op basis van logging of met behulp van systeemmanagementprogrammatuur). 12 Het verzamelen en aggregeren van beschikbaarheidsgegevens gebeurt bij voorkeur geautomatiseerd en zonder dat de beheerder van betroffen componenten deze gegevens op oneigenlijke wijze in zijn voordeel kan beïnvloeden. 13 De gemeten beschikbaarheid wordt periodiek vergeleken met de afgesproken beschikbaarheid. Afwijkingen worden geanalyseerd en verklaard, waarbij ook wordt geverifieerd of het meetsysteem betrouwbaar heeft gefunctioneerd. 6 Procesrelaties De volgende procesrelaties worden als basisnorm ingevuld: Service Level Management verzoeken door klanten voor toetsing gewenst beschikbaarheidsniveau (haalbaarheidsvragen voor afwijking op standaard leverbare niveaus); verzoeken voor opstellen beschikbaarheidsparagraaf in nieuwe SLA s of standaard service levels; SLA s (afgesproken beschikbaarheidsniveau) informatie over haalbaarheid gewenst niveau; tekst voor beschikbaarheidsparagraaf in SLA; rapportage over gerealiseerd beschikbaarheidsniveau.

13 Configuration Management informatie over CI s. niets. Incident Management informatie over optreden, aard en duur van niet-beschikbaarheidsincidenten. niets. Problem Management informatie over openstaande en opgeloste beschikbaarheidsproblemen. vaktechnische ondersteuning. Change Management request for changes ter beoordeling op beschikbaarheidsimpact. change requests voor wijzigingen ter verbetering van de beschikbaarheid. Operations Management informatie over beschikbaarheid resources (meetgegevens). niets. Supply Management verzoeken om onderdelen van offerteaanvragen uit te werken; verzoeken om het door de leverancier in het concept- Underpinning Contract (UC) vastgelegde serviceniveau te toetsen (toetsing of dit past binnen het afgesproken serviceniveau voor de eigen ICT-dienstverlening). 65

14 Basisnormen Beveiliging en Beheer ICT-infrastructuur Service Level Rapportage conceptteksten voor onderdelen van offerte-aanvragen; adviezen over bijstelling van concept-uc s; punten voor bespreking in het operationeel overleg met de leverancier of zaken ter escalatie; voorstellen voor aanpassing van afgesloten UC s. 4.4 Capacity Management 66 1 Hoofddoelstelling Capacity Management zorgt ervoor dat de benodigde resources voor het overeengekomen serviceniveau tijdig aanwezig zijn en blijven. Onder resources wordt verstaan: ruimte voor gegevensopslag, voldoende processorvermogen voor de afgesproken verwerkingen, bij online verwerking resulterend in het kunnen realiseren van afgesproken responsetijden. 2 Belang van het proces voor beveiliging Het proces Capacity Management draagt in belangrijke mate bij aan de beschikbaarheid van de geautomatiseerde gegevensverwerking. Indien de geautomatiseerde gegevensverwerking stagneert door onvoldoende resources, kan dat aanleiding geven tot slechte responsetijden, doorbreking van verwerkingscycli en te late aanlevering van gegevens aan opeenvolgende processen. Onvolledige verwerking kan de integriteit van de gegevensverwerking schaden. Stagnaties leiden tot herstelacties, die, omdat ze buiten de routine vallen, aanleiding kunnen geven tot integriteitsproblemen, bijvoorbeeld door het niet of in een verkeerde volgorde verwerken van (een deel van de) gegevens. Onacceptabele responsetijden kunnen irritaties bij gebruikers oproepen, die daardoor eerder fouten gaan maken of oneigenlijke oplossingen gaan verzinnen. 3 Afbakening Het proces Capacity Management heeft geen betrekking op de inzet van menskracht. Er wordt van uitgegaan dat de personele

15 capaciteit een afgeleide is van de prestatieafspraken in de serviceovereenkomsten. 4 Beheerdoelstellingen 1 Voor alle relevante ICT-middelen wordt het capaciteitsbeslag dusdanig gepland dat continu wordt voldaan aan de eisen gesteld in de SLA s; hierbij wordt tijdig ingespeeld op nieuwe ontwikkelingen. 2 De inschatting van de benodigde capaciteit voor de vereiste performance wordt in voldoende mate onderbouwd. 3 Op basis van het capaciteitsplan worden tijdig de vereiste acties ondernomen. De ontwikkelingen in de ICT-infrastructuur en toepassingen worden getoetst op capaciteitsaspecten. De beschikbare capaciteit van de ICT-middelen wordt adequaat beheerd en optimaal benut. 4 Performanceproblemen worden tijdig gesignaleerd en geanalyseerd op basis van betrouwbare informatie. 5 Op basis van de performanceanalyse worden tijdig de juiste maatregelen genomen om een optimale performance te waarborgen. 6 De systeembelasting wordt optimaal verdeeld. 7 De klantenvraag wordt optimaal uitgebalanceerd en afgestemd. 5 Normen 5.1 Tactisch deel van het proces Definiëren service level 1 In de SLA s is een Capacity Management-paragraaf opgenomen waarin is vastgelegd: a de te leveren performance, zonodig gesplitst per component van de onderkende dienst (bijvoorbeeld batch en online), gesplitst naar tijdsperiode, plaats en/of klant/afdeling; b de werklast waarop de gegarandeerde performance is gebaseerd, inclusief definitie van toelaatbare piekbelastingen; c de minimaal en maximaal te leveren capaciteit, in duidelijk omschreven leveringseenheden (bijvoorbeeld gigaby- 67

16 Basisnormen Beveiliging en Beheer ICT-infrastructuur 68 tes diskopslag, mbps netwerktransportcapaciteit); d de procedure voor het aanvragen van capaciteitsaanpassingen; e de minimale (en maximale) verwerkingsduur voor dergelijke aanpassingen; f met welke frequentie en in welke vorm over de geleverde performance en beschikbare capaciteit wordt gerapporteerd. Afspraken met leveranciers 2 In met leveranciers afgesloten Service Level Agreements zijn afspraken vastgelegd over de te leveren capaciteit en performance, de voorzieningen voor capaciteitsaanpassing (onder andere levertermijnen voor extra capaciteit) en de wijze waarop hierover door de leverancier wordt gerapporteerd. Werklastmanagement 3 De werklast van de verschillende diensten is geïnventariseerd, waarbij rekening is gehouden met mogelijke piekbelastingen. 4 Er zijn voorzieningen getroffen om de werklast evenwichtig over servers te kunnen verdelen, bij voorkeur wordt daarbij gebruikgemaakt van modellen waarmee de capaciteitsbelasting van nieuwe diensten en/of gewijzigde diensten kan worden gesimuleerd. Capaciteitsplanning 5 Capacity Management beoordeelt de invloed van wijzigingen in de ICT-infrastructuur. 6 Het proces zorgt ervoor dat deze ontwikkelingen worden vertaald naar een capaciteitsplan, dat capaciteitswijzigingsvoorstellen, investeringsvoorstellen, voorstellen voor aanpassing van de afgesproken service levels en andere acties bevat die nodig zijn om op langere termijn in een optimale performance en capaciteitsbenutting te kunnen blijven voorzien. 7 Het capaciteitsplan wordt bijgesteld op basis van analyses van het gemeten capaciteitsgebruik (zie 5.2) en eventuele wijzigingen in de besteltermijnen voor ICT-middelen.

17 8 Capacity Management toetst voorstellen voor nieuwe diensten en wijzigingen in de ICT-infrastructuur (RFC s) op consequenties voor de capaciteitsplanning. 5.2 Operationeel deel van het proces Meten en analyseren capaciteitsgebruik 9 Voor elk productiemiddel zijn capaciteits- en performancelimieten gedefinieerd (drempelwaarden). 10 Er zijn voorzieningen getroffen voor het geautomatiseerd meten van het capaciteitsgebruik en de performance en het geautomatiseerd genereren van events ten behoeve van het Incident Management-proces bij overschrijding van de gedefinieerde limieten. 11 De metingen worden geanalyseerd (trendanalyse). 12 Op grond van de geanalyseerde meetgegevens wordt het capaciteitsplan bijgesteld, worden adviezen gegeven voor aanpassing van applicaties (application sizing) en worden RFC s ingediend voor aanpassing van de technische infrastructuur of een andere verdeling van de werklast. 13 Er is vastgesteld welke parameters, binnen welke grenzen, door Operations aangepast mogen worden om capaciteits- en performanceproblemen op te lossen (instructies voor tuning). 6 Procesrelaties De volgende procesrelaties worden als basisnorm ingevuld: Service Level Management verzoeken door klanten voor toetsing gewenste capaciteit en performance (haalbaarheidsvragen voor afwijking op standaard leverbare niveaus). verzoeken voor opstellen Capaciteit Management-paragraaf in nieuwe-sla s of standaard service levels; SLA s (afgesproken te capaciteit en performance). informatie over haalbaarheid gewenste capaciteit en performance; tekst voor Capaciteit Management-paragraaf in SLA; rapportage over gerealiseerde performance en geleverde capaciteit. 69

18 Basisnormen Beveiliging en Beheer ICT-infrastructuur 70 ICT Service Continuity Management gegevens voor het bepalen van de capaciteit van de uitwijkconfiguratie. continuïteitstestplan en testrapporten. Configuration Management informatie over CI s. niets. Incident Management informatie over incidenten als gevolg van capaciteitsgebrek en slechte performance. Problem Management informatie over problemen als gevolg van capaciteitsgebrek en slechte performance. capacity plan; vaktechnische ondersteuning. Change Management changes ter goedkeuring voor realisatie en implementatie (verificatie); capaciteits- en performance-impact doorgevoerde changes ter evaluatie. RFC s voor aanpassingen in de technische infrastructuur ten behoeve van verbetering van het capaciteitsgebruik en de performance. Operations Management informatie over gebruik resources (meetgegevens). instructies voor optimalisatie inzet resources (tuningsinstructies).

19 Supply Management verzoeken om onderdelen van offerteaanvragen uit te werken; verzoeken om het door de leverancier in het concept- Underpinning; Contract vastgelegde serviceniveau te toetsen (toetsing of dit past binnen het afgesproken serviceniveau voor de eigen ICTdienstverlening); Service Level Rapportage. conceptteksten voor onderdelen van offerteaanvragen; adviezen over bijstelling van concept UC s; punten voor bespreking in het operationeel overleg met de leverancier of zaken ter escalatie; voorstellen voor aanpassing van afgesloten UC s. 4.5 ICT-Service Continuity Management 71 1 Hoofddoelstelling Zeker stellen dat de ICT-infrastructuur en de ICT-diensten na het optreden van een calamiteit zo snel mogelijk weer worden hersteld binnen de afspraken die hierover met de klanten zijn gemaakt. Hierbij wordt een calamiteit gedefinieerd als een ongeplande situatie waarbij verwacht wordt dat de duur van het niet-beschikbaar zijn van één of meer ICT-diensten afgesproken drempelwaarden zal overschrijden. 2 Belang van het proces voor beveiliging Binnen de ITIL-beheerprocesindeling is het Security Managementproces niet volledig verantwoordelijk voor het kwaliteitsaspect beschikbaarheid (continuïteit), maar steunt dit proces voor de borging van de beschikbaarheid na calamiteiten op het proces ICT Service Continuity Management. 3 Afbakening Het bepalen van de continuïteitsspecificaties (vaststellen uitwijk-/ herstelniveaus) wordt niet tot de scope van het proces gerekend

20 Basisnormen Beveiliging en Beheer ICT-infrastructuur 72 omdat dit buiten de verantwoordelijkheid van de exploitatieorganisatie valt. Het is de taak van de klantenorganisatie om op basis van een analyse van de bedrijfsprocessen (risicoanalyse, A&K-analyse) te bepalen in welke mate bescherming tegen de gevolgen van calamiteiten nodig is. Het is echter wel de taak van het proces ICT Service Continuity Management om het door de klantenorganisatie verlangde niveau op haalbaarheid te toetsen en ervoor te zorgen dat dit naar duidelijke afspraken in Service Level Agreements wordt vertaald. De uitvoering van het proces ICT Service Continuity Management is in principe onafhankelijk van de gekozen ICT-infrastructuur. Bij het beschrijven van de normen die aan het operationeel deel van het proces worden gesteld, is echter uitgegaan van de variant waarin de gevolgen van een calamiteit worden opgevangen door de gegevensverwerking naar een uitwijkcentrum (uitbesteed of in eigen beheer) te verplaatsen en aldaar te hervatten. 4 Beheerdoelstellingen 1 Het in Service Level Agreements vastleggen van duidelijke en haalbare afspraken over het na calamiteiten te leveren continuïteitsniveau. Ervoor zorgen dat infrastructurele voorzieningen beschikbaar zijn en blijven om herstel na een calamiteit mogelijk te maken (uitwijk, extra netwerkkoppelingen, off-site bewaarde back-ups enzovoort). 1 Het binnen de exploitatieorganisatie (laten) inrichten van een crisisorganisatie en zorgen voor afstemming met de crisisorganisatie van de klantenorganisatie(s). 2 Het opstellen en onderhouden van een continuïteitsplan waarin voor diverse situaties is vastgelegd wie wanneer welke acties na een calamiteit moet uitvoeren. 3 Het opstellen, uitvoeren en onderhouden van een testplan waarin is vastgelegd hoe geverifieerd wordt dat het continuïteitsplan uitvoerbaar is en tot het beoogde resultaat leidt. 4 Het toetsen van ontwikkelingen in de ICT-infrastructuur. 5 Normen 5.1 Tactisch deel van het proces Definiëren service level

21 1 In de SLA s is een calamiteitenparagraaf opgenomen waarin is vastgelegd: a wanneer er sprake is van een calamiteit; b hoe bij calamiteiten de communicatie tussen ICT-organisatie en klantenorganisatie verloopt; c binnen welke termijn de ICT-dienstverlening na het optreden van een calamiteit moet worden hervat; d wat het maximale gegevensverlies is bij het optreden van een calamiteit; e welk dienstenniveau na herstel in een calamiteitensituatie van toepassing is; f in welke mate en met welke frequentie de calamiteitenbeheersingsmaatregelen worden getest en hoe de klantenorganisatie over de testresultaten wordt geïnformeerd; g als voor het uitvoeren van testen medewerking van de klantenorganisatie nodig is, welke afspraken daarvoor gelden. 2 De ICT-organisatie toetst van tevoren de in de SLA s vast te leggen afspraken op uitvoerbaarheid en duidelijkheid. Indien een bepaald gewenst continuïteitsniveau niet of pas op termijn te leveren is, wordt de klantenorganisatie hierover geïnformeerd. 3 De procesmanager Continuity Management heeft geborgd dat passende technische en organisatorische maatregelen zijn getroffen om het in SLA s overeengekomen continuïteitsniveau te kunnen leveren. Maken afspraken met leveranciers 4 Bij uitbesteding wordt in de onderliggende contracten expliciet vastgelegd wat onder calamiteiten wordt verstaan en welke invloed het optreden van calamiteiten heeft op het aangeboden continuïteitsniveau. 5 Het hiervoor genoemde niveau afdoende is om de in SLA s vastgelegde verplichtingen te kunnen voldoen. 6 Met de leverancier worden procedures gemaakt voor het over en weer melden van calamiteiten en de beschikbaarheid en bereikbaarheid van de daarbij betrokken contactpersonen. 73

22 Basisnormen Beveiliging en Beheer ICT-infrastructuur 74 7 Er zijn afspraken gemaakt over het op elkaar afstemmen van uitwijkscenario s en uitwijktesten en de daarvoor door de leverancier te leveren inspanning. Hierbij wordt ervoor gezorgd dat uitbesteding niet ten koste gaat van de mogelijkheid om end-to-end uitwijktesten uit te voeren. Opstellen en onderhouden continuïteitsbeleid 8 De ICT-organisatie heeft een continuïteitsbeleid opgesteld waarin is vastgelegd: a welke continuïteitsniveaus worden aanboden en hoe daarover afspraken met de klantenorganisatie worden gemaakt; b welke continuïteitsniveau de ICT-organisatie voor zijn eigen ondersteunende processen (zoals doorbelasting/ facturering) nastreeft; c wie bepaalt of er sprake is van een calamiteit en wie bevoegd is het continuïteitsplan in werking te stellen; d wie verantwoordelijk is voor het opstellen, onderhouden en testen van het continuïteitsplan; e hoe er wordt zorggedragen voor een blijvend bewustzijn bij alle betrokkenen functionarissen. Opstellen en onderhouden continuïteitsplan 9 De ICT organisatie heeft een continuïteitsplan opgesteld waarin is vastgelegd: a hoe de crisisorganisatie is opgebouwd (welke teams worden er onderkend, hoe zijn deze bemand en welke taken, verantwoordelijkheden en bevoegdheden hebben ze); b welke scenario s/draaiboeken worden gevolgd in het geval zich een (bepaald type) calamiteit voordoet. In deze scenario s is per activiteit vastgelegd: welk team ze uitvoert, op welke locatie ze worden uitgevoerd en binnen welke tijd de activiteit afgerond moet zijn. De draaiboeken maken tevens duidelijk in welke volgorde TIS-componenten en toepassingen moeten worden hersteld en hoe wordt besloten of een TIS-component of toepassing voor gebruik kan worden vrijgegeven;

23 c hoe de in- en externe communicatie over de gevolgen van de calamiteit en de herstelacties plaatsvindt; d hoe na herstel de overgang na de normale toestand plaatsvindt (inwijk). 10 In het continuïteitsplan zijn procedures en instructies opgenomen voor het herstel van de gegevensverwerking in de uitwijklocatie. Deze procedures en instructies zijn in de uitwijklocatie beschikbaar. 11 In de procedures en instructies is aandacht besteed aan de onderlinge afhankelijkheid tussen onderdelen van ICT-infrastructuur (wat moet in welke volgorde worden hersteld). 12 De verantwoordelijkheid voor het onderhoud van het continuïteitsplan is belegd. Deze persoon of instantie zorgt ervoor dat de volgende zaken in het plan worden verwerkt: a personeelsmutaties en organisatiewijzigingen; b wijzigingen in de continuïteitsarchitectuur en de afgesproken dienstenniveaus; c de resultaten van continuïteitstesten. 13 Er zijn maatregelen genomen om het continuïteitsplan bij de betrokkenen bekend te maken. 14 Er zijn maatregelen genomen om ervoor te zorgen dat het continuïteitsplan bij calamiteiten beschikbaar is (externe bewaring). 15 Periodiek worden de uitgangspunten en invulling van het continuïteitsplan geëvalueerd. Opstellen en onderhouden continuïteitstestplan 16 Er is een testplan opgesteld waarin is beschreven hoe en met welke frequentie de continuïteitsmaatregelen worden getest. 17 Bij uitwijktesten wordt zoveel mogelijk de werkelijke gebruiksituatie gesimuleerd (het end-to-end testen van het toegangspad van eindgebruiker tot applicatiedata waarbij het functioneren van alle tussenliggende technische componenten impliciet wordt getest). 18 Voor elke test wordt een draaiboek opgesteld waarin aandacht is besteed aan: a de scope van de test; deze omvat onder andere: 75

24 Basisnormen Beveiliging en Beheer ICT-infrastructuur 76 a 1 droogtests van diverse scenario s (de herstelprocedures van de organisatie bespreken, aan de hand van mogelijke bedrijfsonderbrekingen); a 2 simulaties (speciaal bedoeld om mensen te trainen in hun rol na een ongeval en bij crisismanagement); a 3 testen van technische herstelprocedures (om te waarborgen dat informatiesystemen effectief kunnen worden hersteld); a 4 herstel op een andere locatie testen (waarbij de bedrijfsprocessen parallel worden gedraaid met hersteloperaties, op een andere plaats dan de hoofdlocatie); a 5 het testen van de voorzieningen en diensten van leveranciers, met name alternatieve communicatievoorzieningen (om te waarborgen dat externe diensten en producten de overeengekomen toezeggingen kunnen nakomen); a 6 complete rampenoefeningen (waarbij getest wordt of de organisatie, het personeel, de apparatuur, voorzieningen en processen de onderbreking het hoofd kunnen bieden); b de benodigde mensen en middelen, zowel van de verwerkingsorganisatie, als van de klantorganisatie; c de impact op de reguliere dienstverlening (voorkoming ongeplande onbeschikbaarheid); d het risico dat tijdens uitwijktesten oneigenlijke mutaties in productiegegevens aangebracht kunnen worden; e het herstel van de normale toestand, inclusief het verwijderen van productiegegevens van de uitwijkconfiguratie. 19 De verantwoordelijkheid voor het onderhoud van het testplan en het (doen) inplannen van continuïteitstesten is belegd. 20 Beoordelen wijzigingsverzoeken 21 De impact van wijzigingen op het afgesproken continuïteitsniveau wordt getoetst.

25 22 Als is vastgesteld dat wijziging van de uitwijkinfrastructuur nodig is, worden deze wijzigingen mee gepland, ontwikkeld, getest en in het continuïteitsplan verwerkt. Beheren uitwijkconfiguratie 23 De uitwijkconfiguratie is gedocumenteerd en overeenkomstig de door het proces Configuration Management opgestelde regels in de Configuratie Management Database opgenomen. 24 Er zijn regels opgesteld voor het sizen van de uitwijkconfiguratie. 25 Er zijn maatregelen getroffen om te borgen dat capaciteit van de uitwijkconfiguratie gelijke tred houdt met de ontwikkeling van de capaciteit van reguliere configuratie. 5.2 Operationeel deel van het proces Uitvoeren uitwijktesten 26 Op de geplande tijdstippen worden volgens het testplan de voorgeschreven testactiviteiten uitgevoerd. 27 Voor elke uitwijktest wordt een toezichthouder/coördinator aangewezen. Deze ziet erop toe dat de calamiteitenomstandigheden zo goed mogelijk worden nagebootst en maakt rapport op van het verloop van de test en de eventueel daarbij ontstane problemen en knelpunten. 28 Fouten in exploitatie of beheer, die via het uitwijktesten worden geconstateerd, worden als incident geregistreerd. Voor fouten in het uitwijkproces zelf worden verbeteracties gedefinieerd. 6 Procesrelaties De volgende procesrelaties worden als basisnorm ingevuld: Service Level Management verzoeken door klanten voor toetsing gewenst continuïteitsniveau bij calamiteiten (haalbaarheidsvragen voor afwijking op standaard leverbare niveaus); verzoeken voor opstellen calamiteitenparagraaf in nieuwe SLA s of standaard service levels; SLA s (afgesproken continuïteitsniveau bij calamiteiten). 77

26 Basisnormen Beveiliging en Beheer ICT-infrastructuur 78 informatie over haalbaarheid gewenst niveau; tekst voor calamiteitenparagraaf in SLA; rapportage over uitgevoerde uitwijktesten en afgehandelde calamiteiten. Capacity Management gegevens voor het bepalen van de capaciteit van de uitwijkconfiguratie. continuïteitstestplan en testrapporten. Configuration Management informatie over de uitwijkconfiguratie (vanuit de Configuratie Management Database). wijzigingen in de uitwijkconfiguratie (voor verwerking in de CMDB). Incident Management informatie over opgetreden incidenten die als (potentiële) calamiteit zijn aangemerkt; voortgangsbewaking en statusinformatie van tijdens uitwijktesten opgetreden incidenten. normen voor het classificeren van incidenten als een (potentiële) calamiteit incidentmeldingen van tijdens uitwijktesten geconstateerde verstoringen en knelpunten. Problem Management informatie over de structurele oorzaak van uitwijktestproblemen. vaktechnische ondersteuning.

27 Change Management verzoeken voor bepaling impact, goedkeuring, of evaluatie van changes. adviezen voor aanpassing of goedkeuring, evaluaties; RFC s voor aanpassing van de uitwijkinfrastructuur. Supply Management verzoeken om onderdelen van offerteaanvragen uit te werken; verzoeken om het door de leverancier in het concept- Underpinning; Contract vastgelegde serviceniveau te toetsen (toetsing of dit past binnen het afgesproken serviceniveau voor de eigen ICTdienstverlening); Service Level Rapportage. conceptteksten voor onderdelen van offerteaanvragen; adviezen over bijstelling van concept UC s; punten voor bespreking in het operationeel overleg met de leverancier of zaken ter escalatie; voorstellen voor aanpassing van afgesloten UC s Security Management 1 Hoofddoelstelling De hoofddoelstelling van het proces Security Management is: het stellen van kaders voor het inbedden in de exploitatieorganisatie van een overeengekomen niveau van informatiebeveiliging van gegevens en ICT-services; het tijdig doen treffen van op elkaar afgestemde beveiligingsmaatregelen in de verschillende object- en verantwoordelijkheidsgebieden; en het bewaken van de voortdurende werking van de maatregelen om het overeengekomen beveiligingsniveau te handhaven.

28 Basisnormen Beveiliging en Beheer ICT-infrastructuur 80 2 Belang van het proces voor beveiliging Zonder een procesmatige benadering van de beveiliging zoals die in dit hoofdstuk wordt weergegeven, wordt het risico gelopen dat beveiligingsmaatregelen niet juist, niet volledig en/of niet tijdig zijn en/of helemaal niet worden getroffen en/of niet worden nageleefd. Met andere woorden kan men stellen dat de beveiligingsmaatregelen niet meer op de feitelijke en actuele risico s zijn afgestemd en dat het verantwoordelijk management geen verantwoording kan afleggen over de mate waarin zij beveiligingsrisico s beheerst. 3 Afbakening Het treffen van beveiligingsmaatregelen is een operationele aangelegenheid die plaatsvindt overal in de organisatie, in techniek en processen, zowel in project-, lijn als procesorganisaties. Om die reden wordt er geen apart operationeel onderdeel van het proces Security Management in beschouwing genomen. Security Management schept als tactisch proces voorwaarden (kaders), adviseert, toetst en ziet toe op naleving van beveiligingnormen. Er wordt van uitgegaan dat er in het proces Security Management geen beveiligingsbeleid wordt ontwikkeld of vastgesteld. Het beveiligingsbeleid is randvoorwaarde voor het proces. Uiteraard kan wel vanuit het proces geadviseerd worden over beveiligingsbeleid. In het proces worden geen Configuratie Items die mede zorgdragen voor het realiseren van het afgesproken beveiligingsniveau ontwikkeld, aangeschaft of beheerd; dat is onderdeel van het primaire ICT-proces. 4 Beheerdoelstellingen 1 Het jaarlijks opstellen van een beveiligingsplan voor het verbeteren en onderhouden van beveiligingsnormen en -maatregelen. 2 Het vertalen van het beveiligingsbeleid naar een tactisch beveiligingsnormenkader en het onderhouden daarvan. 3 Het in SLA s vastleggen van het te leveren beveiligingsniveau. 4 Het adviseren van het lijn-, proces- en projectmanagement over het treffen van beveiligingsmaatregelen in organisatie, techniek en processen. 5 Het toezien op de implementatie van de beveiligingsmaatregelen.

29 6 Het (doen) evalueren van de opzet, het bestaan en de werking van de beveiligingsmaatregelen. 7 Het (doen) registreren en evalueren van beveiligingsincidenten. 8 Het toezien op tijdig onderhoud van beveiligingsmaatregelen bij gewijzigde omstandigheden. 9 Het rapporteren over het gerealiseerde beveiligingsniveau. 5 Normen Stellen kaders 1 Jaarlijks wordt er een door het management goedgekeurd beveiligingsplan opgesteld, waarin is vastgelegd welke verbeteracties er noodzakelijk zijn om het afgesproken beveiligingsniveau te kunnen bereiken en handhaven. Dit plan is gebaseerd op de uitkomsten van het evaluatieproces en de te verwachten ontwikkelingen in de verschillende object- en verantwoordelijkheidsgebieden. 2 Er worden in voldoende mate contacten onderhouden met de relevante omgeving om tijdig betrokken te zijn bij de totstandkoming van strategische beleidsstukken, architecturen en projectplannen met relevantie voor beveiliging. Dit kan bijvoorbeeld worden gerealiseerd in een Security Board met voldoende representatieve deelname uit de ICT-organisatie of door deelname aan een Technology Board. 3 Ter invulling van het te leveren beveiligingsniveau wordt een tactisch beveiligingsnormenkader gedefinieerd, dat: a gebaseerd is op deze PI-studie, waarbij aanvulling heeft plaatsgevonden volgens de kruisjes van de laatste kolom in de tabel van bijlage I; b is afgestemd met het gevraagde beveiligingsniveau vanuit de klantorganisatie; c is goedgekeurd door het management van de ICT-organisatie, mede in verband met haalbaarheid, kostenbaten en dergelijke. Definiëren service level 4 In de SLA s is een beveiligingsparagraaf opgenomen waarin is vastgelegd: 81

30 Basisnormen Beveiliging en Beheer ICT-infrastructuur 82 a welk beveiligingsniveau wordt aangeboden; b dat geheimhouding van klantgegevens is geborgd; c hoe rapportage over het halen van het beveiligingsniveau plaatsvindt, door middel van: c 1 een beheersverslag; c 2 een Third Party Mededeling door een onafhankelijke auditor; c 3 het optreden en afhandelen van beveiligingsincidenten betrekking hebbend op de ICT-services die aan de klant worden geleverd. Maken afspraken met leveranciers 5 In de leveranciersovereenkomsten bij uitbesteding van exploitatiediensten is een beveiligingsparagraaf opgenomen waarin is vastgelegd: a geheimhoudingsplicht van de medewerkers van de leverancier en eventueel door hem ingeschakelde medewerkers van de onderaannemers; b het recht van de ICT-organisatie als afnemer van de dienst om zelf audits uit te (laten) voeren naar de kwaliteit van de geboden diensten en/of om daarvoor van de leverancier een Third Party Mededeling (TPM) te krijgen. Als voor een TPM wordt gekozen, zijn aanvullende contractuele afspraken nodig over: b 1 het bij de TPM te hanteren normenkader (indien de exploitatieorganisatie zelf onderhevig is aan een TPM wordt hetzelfde beveiligingsniveau aangehouden); b 2 de reikwijdte van de TPM (opzet, bestaan en/of werking); b 3 het tijdstip waarop de TPM wordt verstrekt en de frequentie waarmee het TPM-onderzoek wordt herhaald; b 4 de wijze van opdrachtverstrekking (wie plaatst de opdracht, wie selecteert de auditor, wie bepaalt de eisen waaraan de auditor moet voldoen enzovoort);

31 b 5 of het TPM-onderzoek onderdeel van de dienst vormt, of afzonderlijk door de klant moet worden betaald. 6 In de leveranciersovereenkomsten voor onderhoudsdiensten is de geheimhoudingsplicht van medewerkers van de leverancier en eventueel door hem ingeschakelde medewerkers van de onderaannemers opgenomen. Implementeren beveiliging 7 Vanuit het Security Managementproces worden toetsingen verricht op wijzigingen in organisatie, techniek (CI s) en processen en worden zonodig adviezen gegeven. 8 Er wordt getoetst dat de interne controles op de uitvoering van processen mede gebaseerd zijn op de normenkaders voor beveiliging. Evalueren beveiliging 9 Er wordt op toegezien dat in voldoende mate controles op beveiligingsinstellingen van TIS-componenten, die deel uitmaken van de logische toegangspaden tot gegevens, interne procescontroles en procesevaluaties worden gehouden. 10 De uitkomsten van interne en technische controles met beveiligingsrelevantie worden beoordeeld op hun effecten voor de opzet, het bestaan en de werking van de beveiligingsmaatregelen. Er wordt toegezien op het tijdig, juist en volledig oplossen van bevindingen dan wel het verantwoord accepteren van risico s. 11 Er wordt voor gezorgd, dan wel op toegezien dat beveiligingsincidenten juist worden geanalyseerd en opgelost. 12 De Service Niveau Rapportage inzake beveiligingsincidenten, die aan klanten zijn gemeld, worden vanuit het Security Management-proces opgesteld. Hierover zijn afspraken gemaakt met het Incidentproces. Onderhouden beveiligingskaders 13 Beveiligingsplannen, -normen en -contractuele afspraken worden onderhouden op basis van de uitkomsten van het evaluatieproces en op basis van ontwikkelingen in en onderhoud van organisatie, techniek en processen. 83