Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

Het beheren van wijzigingsaanvragen omvat een aantal activiteiten die, afhankelijk van de klasse waartoe de getroffen informatie behoort, al dan niet verplicht uitgevoerd moeten worden. Deze activiteiten zijn (zie hoofdstuk: ‘De bouwstenen van wijzigingsbeheer’):

  • Registratie van de wijzigingsaanvraag;

  • Goedkeuring van de wijzigingsaanvraag;

  •  Impact van de wijziging bepalen;

  • Urgentie van de wijziging bepalen;

  • Inplannen van de wijziging;

  • Uitvoeren van de wijziging;

  • Validatie van de wijziging;

  • Evaluatie van de wijziging (lessons learned);

  • Afsluiten van de wijziging.

De minimale beschikbaarheid van het proces wijzigingsbeheer zelf is eveneens afhankelijk van het type en klasse van de getroffen informatie. We onderscheiden beschikbaarheid tijdens kantooruren (10ux5dagen) en permanente beschikbaarheid (24ux7dagen).

Registratie van de wijzigingsaanvraag

Elke wijzigingsaanvraag wordt geregistreerd. Minimaal wordt hiervoor een logboek aangelegd, dit kan eventueel een manueel onderhouden document zijn. Het is mogelijk dat er verschillende logboeken voor wijzigingen bestaan, bijvoorbeeld omdat er met verschillende leveranciers en verschillende CAB’s wordt gewerkt. Het logboek staat onder controle van de eigen organisatie maar het beheer ervan kan uitbesteed worden.

Voor meer informatie zie hoofdstuk: ‘De wijzigingsaanvraag’.

Goedkeuring van de wijzigingsaanvraag

De toepassingseigenaar is steeds betrokken bij de goedkeuring van wijzigingsaanvragen die impact hebben op de toepassing maar sommige wijzigingen moeten via de CAB goedgekeurd worden. Voor kleinere organisaties zonder formele CAB worden meerdere partijen bij de goedkeuring betrokken, bvb de veiligheidsconsulent of DPO.

Volgende scenario’s zijn mogelijk:

  • Goedkeuring door de toepassingseigenaar:

    • Dit is de individuele organisatie die zelf de toepassing beheert, bvb AGO, MOW;

    • De dienstenorganisator die de toepassing beheert en ter beschikking stelt van andere organisaties, bvb HFB/HB+ dienstverlening, AIV voor diensten rond MAGDA, AGO voor Vlimpers, FB voor ORAFIN).

  • Goedkeuring door de wijzigingsbeheerder van de dienstenleverancier:

    • Centrale dienstverlener (HB+);

    • Een door de organisatie toegewezen leverancier met een specifiek contract voor maatwerk, bvb Cronos, Realdolmen;

    • Bij directe dienstafname met een generiek contract en zonder maatwerk, bvb IaaS, SaaS, PaaS, enz.

Welke wijzigingen via de CAB goedgekeurd worden, hangt af van:

  • De prioriteit (P1 en P2),

  • De informatieklasse

Voor meer informatie zie hoofdstuk: ‘Goedkeuring van de wijzigingsaanvraag’

Bepalen van de prioriteit

De urgentie en de impact worden door de aanvrager gedefinieerd en gevalideerd door de toepassingseigenaar voor het bepalen van de prioriteit.
De hoogte prioriteit P1 wordt enkel toegepast voor wijzigingen ten gevolge van P1 incidenten en noodwijzigingen.
Voor meer informatie zie hoofdstuk: ‘Bepalen van de prioriteit van de wijzigingsaanvraag’. 

4.4.2.1. Minimale algemene maatregelen

Vertrouwelijkheid 

IC klasse  

Minimale maatregelen

Klasse 1 en Klasse 2 kennen dezelfde maatregelen:

  • Registratie van de wijzigingsaanvraag in een logboek;

  • De informatie in het logboek krijgt minimaal vertrouwelijkheidsklasse 2 toegewezen;

  • Impact van de wijziging bepalen;

  • Urgentie van de wijziging bepalen;

  • Minstens goedkeuring van de wijzigingsaanvraag door de toepassingseigenaar;

  • Inplannen van de wijziging;

  • Uitvoeren van de wijziging;

  • Validatie van de wijziging voorafgaand aan in productie name is verplicht voor architecturale en functionele wijzigingen;

  • Evaluatie van de wijziging (lessons learned) voor P1 wijzigingen (als gevolg van incidenten of noodwijzigingen);

  • Afsluiten van de wijziging.

Alle maatregelen van Klasse 1 / Klasse 2 +

  • Registratie van de wijzigingsaanvraag in een logboek onder beheer van een wijzigingsbeheerder;

  • Impact van de wijziging is minstens medium;

  • Goedkeuring van de wijzigingsaanvraag via CAB;

  • Validatie van de wijziging voorafgaand aan in productie name is altijd verplicht;

  • Evaluatie van de wijziging (lessons learned) vanaf P2 wijzigingen. 

Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 +

  • Impact van de wijziging is altijd hoog;

  • Validatie van de wijziging voorafgaand aan in productie name en post-validatie;

  • Altijd evaluatie van de wijziging (lessons learned).

Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 + Klasse 4 +

  • Registratie van de wijzigingsaanvraag in een centraal logboek onder beheer van een wijzigingsbeheerder;

  • De informatie in het logboek krijgt minimaal vertrouwelijkheidsklasse 3 toegewezen;

  • Goedkeuring van de wijzigingsaanvraag via CAB en DPO met in acht name van scheiding van functies en 4EYES validatie

Integriteit

IC klasse  

Minimale maatregelen

Klasse 1 en Klasse 2 kennen dezelfde maatregelen:

  • Registratie van de wijzigingsaanvraag in een logboek;

  • De informatie in het logboek krijgt minimaal vertrouwelijkheidsklasse 2 toegewezen;

  • Impact van de wijziging bepalen;

  • Urgentie van de wijziging bepalen;

  • Minstens goedkeuring van de wijzigingsaanvraag door de toepassingseigenaar;

  • Inplannen van de wijziging;

  • Uitvoeren van de wijziging;

  • Validatie van de wijziging voorafgaand aan in productie name is verplicht voor architecturale en functionele wijzigingen;

  • Evaluatie van de wijziging (lessons learned) voor P1 wijzigingen (als gevolg van incidenten of noodwijzigingen);

  • Afsluiten van de wijziging.

Alle maatregelen van Klasse 1 / Klasse 2 +

  • Registratie van de wijzigingsaanvraag in een logboek onder beheer van een wijzigingsbeheerder;

  • Impact van de wijziging is minstens medium;

  • Goedkeuring van de wijzigingsaanvraag via CAB;

  • Validatie van de wijziging voorafgaand aan in productie name is altijd verplicht;

  • Evaluatie van de wijziging (lessons learned) vanaf P2 wijzigingen. 

Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 + 

  • Impact van de wijziging is altijd hoog;

  • Validatie van de wijziging voorafgaand aan in productie name en post-validatie;

  • Altijd evaluatie van de wijziging (lessons learned).

Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 + Klasse 4 +

  • Registratie van de wijzigingsaanvraag in een centraal logboek onder beheer van een wijzigingsbeheerder;

  • De informatie in het logboek krijgt minimaal vertrouwelijkheidsklasse 3 toegewezen;

  • Goedkeuring van de wijzigingsaanvraag via CAB en DPO met in acht name van scheiding van functies en 4EYES validatie

Beschikbaarheid

IC klasse  

Minimale maatregelen

Klasse 1 en Klasse 2 kennen dezelfde maatregelen:

  • Beschikbaarheid van het proces wijzigingsbeheer is minimaal kantooruren (5d x 10u)

Klasse 3 + Klasse 4 en Klasse 5 kennen dezelfde maatregelen:

Alle maatregelen van Klasse 1 / Klasse 2 +

  •  Beschikbaarheid van het proces wijzigingsbeheer is minimaal kantooruren (24u x 7d)

4.4.2.2. Minimale specifieke (GDPR) maatregelen

De minimale algemene maatregelen voor wijzigingsbeheer moeten toegepast worden: per klasse zijn de overeenkomende maatregelen van toepassing (zie hoofdstuk 'minimale algemene maatregelen').

Vertrouwelijkheid

IC klasse  

Minimale maatregelen

Klasse 1, Klasse 2 en Klasse 3 kennen dezelfde maatregelen:

  • Goedkeuring van de wijzigingsaanvraag via CAB inclusief DPO;

  • Validatie van de wijziging voorafgaand aan in productie name en post-validatie altijd verplicht.

  • Altijd evaluatie van de wijziging (lessons learned)

Klasse 4 en Klasse 5 kennen dezelfde maatregelen:

Alle maatregelen van Klasse 1 / Klasse 2 / Klasse 3 + 

  • Goedkeuring van de wijzigingsaanvraag via CAB en DPO met in acht name van scheiding van functies en 4EYES validatie.

Integriteit

IC klasse  

Minimale maatregelen

Klasse 1, Klasse 2 en Klasse 3 kennen dezelfde maatregelen:

  • Goedkeuring van de wijzigingsaanvraag via CAB inclusief DPO;

  • Validatie van de wijziging voorafgaand aan in productie name en post-validatie altijd verplicht.

  • Altijd evaluatie van de wijziging (lessons learned)

Klasse 4 en Klasse 5 kennen dezelfde maatregelen:

Klasse 1 / Klasse 2 / Klasse 3 +

  • Goedkeuring van de wijzigingsaanvraag via CAB en DPO met in acht name van scheiding van functies en 4EYES validatie.

Beschikbaarheid

Er zijn geen GDPR specifieke maatregelen gedefinieerd in het kader van beschikbaarheid.

4.4.2.3. Minimale specifieke (NISII) maatregelen

In afwachting van de goedkeuringen omtrent NISII is er in dit document alvast de nodige ruimte voorzien voor toekomstige minimale specifieke NISII maatregelen.

4.4.2.4. Minimale specifieke (KSZ) maatregelen

Er zijn geen KSZ specifieke minimale normen rond wijzigingsbeheer.

  • No labels