<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>ZBC Kennisbank &#187; Calamiteitenplan, Business Continuity Management</title>
	<atom:link href="http://zbc.nu/ict/calamiteitenplan-business-continuity-management/feed/" rel="self" type="application/rss+xml" />
	<link>http://zbc.nu</link>
	<description>management kennisbank</description>
	<lastBuildDate>Tue, 14 May 2013 14:59:38 +0000</lastBuildDate>
	<language>nl-NL</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4.2</generator>
		<item>
		<title>Casestudies Business Continuity Plan</title>
		<link>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/casestudies-business-continuity-plan/</link>
		<comments>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/casestudies-business-continuity-plan/#comments</comments>
		<pubDate>Tue, 27 Mar 2012 11:03:28 +0000</pubDate>
		<dc:creator>Wiebe Zijlstra</dc:creator>
				<category><![CDATA[Bedrijfscontinuïteit of Business Continuity]]></category>
		<category><![CDATA[Business Continuïty - Bedrijfsrisico]]></category>
		<category><![CDATA[Calamiteitenplan, Business Continuity Management]]></category>
		<category><![CDATA[Risk management en Compliance]]></category>
		<category><![CDATA[BCP]]></category>
		<category><![CDATA[bedrijfscontinuiteit]]></category>
		<category><![CDATA[BHV-plan]]></category>
		<category><![CDATA[business continuity]]></category>
		<category><![CDATA[business continuity plan]]></category>
		<category><![CDATA[calamiteitenplan]]></category>
		<category><![CDATA[casestudies]]></category>
		<category><![CDATA[casestudy]]></category>
		<category><![CDATA[informatiebeveiliging]]></category>
		<category><![CDATA[lokale bank]]></category>
		<category><![CDATA[praktijkvoorbeeld]]></category>
		<category><![CDATA[productschap]]></category>
		<category><![CDATA[rechtbank]]></category>
		<category><![CDATA[voorbeeld]]></category>

		<guid isPermaLink="false">http://zbc.nu/?p=549</guid>
		<description><![CDATA[Business Continuity gaat over de business van bedrijven en organisaties en nauwelijks over security, ICT of BHV. De factoren die er echt toe doen, worden hierbij vaak over het hoofd gezien. In dit artikel een aantal casestudies voor zowel profit als non-profit organisaties, uitgewerkt op hoofdlijnen.]]></description>
			<content:encoded><![CDATA[<p><strong>Inhoudsopgave</strong></p>
<ol>
<li>Het management krijgt pukkeltjes</li>
<li>Vestiging van een lokale bank</li>
<li>Productschap</li>
<li>Producent van kinderzitjes etc.</li>
<li>Rechtbank</li>
<li>Bijlagen bij het Business Continuity Plan </li>
</ol>
<h2>1. Het management krijgt pukkeltjes</h2>
<p>Heel wat managers krijgen pukkeltjes van Business continuity als onderdeel van informatiebeveiliging.  En dat is geen wonder. Vaak krijgen ze te maken met  beveiligingstijgers die ervan overtuigd zijn dat alle ICT-ellende die je je maar kunt voorstellen, je ook werkelijk zal overkomen als je niet alle maatregelen treft die mogelijk zijn. Ze beginnen interviews af te nemen en met het rode potlood geven ze aan waar er  niet aan de regels wordt voldaan en waar dus aanvullende maatregelen genomen moeten worden, om te komen tot een sluitend Business Continuity Plan of een calamiteitenplan als onderdeel van de totale informatiebeveiliging. (Zie ook &#8216;Business continuity los je niet op met preventie&#8217;.)<br />
Deze exercitie resulteert dan meestal in een ICT-calamiteitenplan en een Business Continuity Plan. Het calamiteitenplan wordt veelal gedumpt op het bordje van de ICT-manager. Meestal aanvaardt die dat dankbaar. Hij krijgt hierdoor weer wat extra budget.  Het Business Continuity Plan komt bij de business terecht.  Daar wordt het in de bekende doofpot gestopt, met soms nog als tussenstap dat het op het intranet wordt geplaatst als aanvullende richtlijn, met de opmerking dat één en ander nog nader uitgewerkt moet worden. Omdat het intranet toch slechts geraadpleegd wordt door enkele overijverige stagiaires, kan dat geen kwaad.<br />
Het idee hierachter is, dat een calamiteiten iets is wat je in het journaal ziet en wat anderen overkomt, maar niet onszelf. Wij weten waar we mee bezig zijn. En bovendien kunnen we onze tijd en ons geld maar één keer kunt uitgeven. We investeren dan liever in de business. <br />
In dit artikel behandelen we een aantal cases vanuit de praktijk. Doel van deze cases is duidelijk te maken dat business continuity niet ingewikkeld hoeft te zijn, als het maar vanuit de business wordt benaderd. (Zie ook &#8216;Uw business continuity plan is een oplossing en geen managementsysteem&#8217;.) Natuurlijk dienen de business issues aangevuld te worden, maar dat gaat in feite om details. </p>
<h2>2. Vestiging van een lokale bank</h2>
<p>Key-issue van een lokale bank is dat de klant altijd bij zijn eigen centen moet kunnen komen. Aangezien de transacties van klanten meestal door centrale systemen worden afgehandeld, ontstaat in geval van een calamiteit op dit gebied geen probleem voor een lokale bank. Desgewenst kunnen klanten ook geld pinnen bij de concurrent. Dat betekent, ook al is een lokale bank volledig uitgebrand, de klant nog steeds bij zijn centen kan komen. In geval van een calamiteit  volstaat meestal een briefje op de deur, met een verwijzing naar de dichtstbijzijnde vestiging, eventueel aangevuld met een nummer van een call centre, dat klanten kan doorverbinden naar de mobiele nummers van de eigen account managers. De account managers kunnen dan klanten thuis bezoeken en de noodzakelijke programma&#8217;s op hun laptop gebruiken of deze via internet opvragen.<br />
Voor klanten die nog niet gewend zijn transacties via internet bankieren af te wikkelen, is een online cursus beschikbaar, ondersteund door een helpdesk, die hen hierbij kan helpen.<br />
En als een brand uitbreekt onder kantoortijden, dan voorziet het BHV-plan al in het in veiligheid brengen van de klanten en het personeel.<br />
Resteert nog het grootste risico: account managers die aansprakelijk worden gesteld voor de adviezen die ze aan klanten hebben gegeven. Het traceren van deze gevallen is een zaak van het hoofdkantoor. De lokale bank is er slechts verantwoordelijk voor dat kennisoverdracht vanuit het hoofdkantoor daadwerkelijk plaats vindt en dat er interne controle is op de afspraken van account managers. </p>
<h2>3. Productschap</h2>
<p>Productschappen hebben als taak hun sector als geheel te ondersteunen met onderzoek en marketing. Dit betekent dat de heffing die de bedrijven in de branche wordt opgelegd, meestal voor 90 procent ten goede komt aan de branche, waarbij de prioriteiten worden vastgesteld door een bestuur dat bestaat uit vertegenwoordigers van belangenverenigingen.<br />
Het enige echte business continuity risico is dat de bedrijven in de sector weigeren om de heffing te betalen. Hierbij zijn een aantal aspecten van belang:</p>
<ul>
<li>Het productschap moet duidelijk communiceren hoe de gelden uit de heffingen inderdaad weer ten goede komen aan de sector (zie ook &#8216;Imagoschade bij calamiteiten veroorzaak je meestal zelf&#8217;).</li>
<li>Het productschap moet kunnen aantonen dat projecten die het productschap heeft geïnitieerd, daadwerkelijk beheerst worden in termen van resultaat en efficiency.</li>
</ul>
<p>Het eerste punt maakt een helder communicatieplan noodzakelijk, met als controlemiddel klanttevredenheidsonderzoeken. Het tweede punt vereist  transparantie in de aanvragen van de sector aan het productschap en in de prioriteitsstelling van het bestuur.<br />
Daarnaast moet het productschap voldoen aan geldende regelgeving om zijn taken goed te kunnen uitvoeren, zoals aan ISO 27002 (=17799) (code voor informatiebeveiliging) en de Archiefwet. (Zie ook &#8216;Code voor Informatiebeveiliging weer up to date&#8217;.)<br />
Deze regelgeving moet natuurlijk nageleefd worden en op grond van het Tabaksblat principe: &#8216;Pas toe of leg uit&#8217; moet er veel uitgelegd worden, want het spreekt voor de sector niet vanzelf dat hierdoor de interne kosten van het productschap stijgen en het percentage dat aan de sector ten goede komt daalt. </p>
<h2>4. Producent van kinderzitjes etc.</h2>
<p>De producent van kinderzitjes in deze case heeft een beursgenoteerde Noord-Amerikaanse moeder en op grond van SOX is men verplicht een business continuity plan te hebben.<br />
Aangezien de kinderzitjes uitsluitend in deze dochtervestiging gemaakt worden, is het productieproces uiteraard de kritieke factor.<br />
Navraag leerde het volgende:</p>
<ul>
<li>Bij retailers is een voorraad aanwezig voor 5-6 weken, voordat er &#8216;nee&#8217; verkocht moet worden.</li>
<li>Het is mogelijk om de productiestraat bij totale vernieling binnen een maand weer op te bouwen.</li>
</ul>
<p>Het business continuity plan kon daarom beperkt worden tot:</p>
<ul>
<li>een communicatieplan voor de retail;</li>
<li>een kooplijst, om de productiestraat inderdaad binnen een maand weer &#8216;up and running&#8217; te hebben. </li>
</ul>
<h2>5. Rechtbank</h2>
<p>In principe is de continuïteit van een rechtbank gewaarborgd in de grondwet. Er is echter één situatie waarin een rechtbank het opsporingsapparaat volledig kan frustreren, namelijk als de georganiseerde misdaad structureel toegang heeft tot de zaakgegevens van het Openbaar Ministerie. Het gaat dan niet primair om situaties waarin de systemen gehackt worden (dat is niet structureel), maar om situaties waarin gebruik gemaakt wordt van accounts van medewerkers, door omkoping of chantage. Dergelijke problemen kunnen alleen worden opgelost door het systematisch uitvoeren van waarschijnlijkheidscontroles, zelfs als er gekozen is voor een harde authenticatie.<br />
Dat je daarnaast je laptop zonder encryptie niet moet laten jatten, geen USB-sticks moet laten slingeren en geen PC&#8217;s vol met gegevens aan de weg moet zetten, is evident. Maar dat verschaft de georganiseerde misdaad nog steeds geen structurele toegang tot gegevens en de schade is meestal groter voor de veroorzaker dan voor de rechtbank. </p>
<h2>6. Bijlagen bij het Business Continuity Plan</h2>
<p>Natuurlijk zijn er een bij Business Continuity Plan nog een aantal bijlagen nodig, waarin zijn vastgelegd:</p>
<ul>
<li>het draaiboek in geval van een calamiteit (zie ook &#8216;Keuzes en aanpak voor uw Business Continuity Plan BCP of calamiteitenplan&#8217;);</li>
<li>de classificatie van de bedrijfsgegevens;</li>
<li>de kooplijst;</li>
<li>de samenstelling van het crisisteam;</li>
<li>de scenario&#8217;s waarin een incident daadwerkelijk een calamiteit wordt;</li>
<li>de scenario&#8217;s voor niet te managen calamiteiten zoals een uitbraak van een pandemie of de uitval van een cruciale stakeholder.</li>
</ul>
<p>Voor al deze aspecten zijn echter sjablonen beschikbaar, die in feite eenvoudige invuloefeningen zijn.<br />
In het op te stellen implementatieplan kan worden vastgelegd welke acties nodig zijn om ervoor te zorgen dat het draaiboek in het geval van een calamiteit daadwerkelijk werkend wordt en blijft.<br />
De crux zit hem echter in de bedrijfscontinuïteit en juist die zaken die er echt toe doen, zijn vaak niet terug te vinden in een checklist of een baseline. Het gaat om de vraag: “Wat is er erg voor onze organisatie?”. Het antwoord is bekend bij de directie.  Maar om het antwoord te weten, moet de vraag eerst wel bij de directie op tafel komen. (Zie ook ‘Hoe u een business continuity plan op de agenda krijgt bij directies’.) Als u zich in deze vrag echt wilt verdiepen, nodigen we u graag uit voor onze ‘Cursus Business Continuity Management’</p>
<h6>oorspronkelijke versie: 1 juli 2006. Herziene versie: 22 april 2010</h6>
]]></content:encoded>
			<wfw:commentRss>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/casestudies-business-continuity-plan/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Voorbeeld plan van aanpak fase 2 van uw Business Continuity Plan BCP of calamiteitenplan</title>
		<link>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/voorbeeld-plan-van-aanpak-fase-2-van-uw-business-continuity-plan-bcp-of-calamiteitenplan/</link>
		<comments>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/voorbeeld-plan-van-aanpak-fase-2-van-uw-business-continuity-plan-bcp-of-calamiteitenplan/#comments</comments>
		<pubDate>Wed, 12 Oct 2011 13:14:14 +0000</pubDate>
		<dc:creator>Wiebe Zijlstra</dc:creator>
				<category><![CDATA[Calamiteitenplan - BCP]]></category>
		<category><![CDATA[Calamiteitenplan, Business Continuity Management]]></category>
		<category><![CDATA[ICT, Security en calamiteitenplan]]></category>
		<category><![CDATA[aanpak]]></category>
		<category><![CDATA[Activiteitenplan]]></category>
		<category><![CDATA[bedrijfsvoering]]></category>
		<category><![CDATA[beschrijving]]></category>
		<category><![CDATA[business continuity plan]]></category>
		<category><![CDATA[calamiteit]]></category>
		<category><![CDATA[calamiteitenplan]]></category>
		<category><![CDATA[draaiboek]]></category>
		<category><![CDATA[fasering]]></category>
		<category><![CDATA[implementatieplan]]></category>
		<category><![CDATA[informatievoorziening]]></category>
		<category><![CDATA[plan van aanpak]]></category>
		<category><![CDATA[risico]]></category>
		<category><![CDATA[stappenplan]]></category>
		<category><![CDATA[uitwijk]]></category>
		<category><![CDATA[uitwijkplan]]></category>
		<category><![CDATA[zbc]]></category>

		<guid isPermaLink="false">http://zbc.nu/?p=599</guid>
		<description><![CDATA[Een voorbeeld uit de praktijk van een Plan van Aanpak voor het opstellen van een Business Continuity Plan (of calamiteitenplan) voor een middelgrote organisatie. Dit plan betreft de tweede fase, als de scope van het BCP al bepaald is. Uitgangspunt voor dit projectplan is dat het aantal preventieve maatregelen zoveel mogelijk beperkt wordt, omdat deze, gelukkig, in de meeste gevallen weggegooid geld blijken te zijn.]]></description>
			<content:encoded><![CDATA[<p><strong>Inhoudsopgave</strong>    </p>
<ol>
<li>Inleiding</li>
<li>Inleiding Plan Business Continuity Plan</li>
<li>Doelstelling, aanpak en succesfactoren</li>
<li>Organisatie</li>
<li>Activiteitenplan</li>
<li>Nawoord </li>
</ol>
<h2>1. Inleiding</h2>
<p>Veel bedrijven hikken aan tegen het opstellen van een Business Continuity plan, vaak omdat ze niet weten waar ze moeten beginnen of omdat ze denken, dat dit grote investeringen met zich meebrengt. In de praktijk blijkt het echter meestal mee te vallen, als men gebruik kan maken van een aantal werkbare sjablonen. In het artikel &#8216;Keuzes en aanpak voor uw Business Continuity Plan BCP of calamiteitenplan&#8217; gaan we in op zo&#8217;n aanpak met behulp van sjablonen en geven we aan welke keuzes er gemaakt moeten worden. In het artikel &#8216;Inventarisatie diensten, dreigingen en processen in uw Business Continuity Plan BCP&#8217; reiken we u de sjablonen aan, waarmee u de globale risico-inventarisatie kunt uitvoeren om vervolgens in fase 2 gericht te kunnen focussen op de geïnventariseerde risico&#8217;s.<br />
In dit artikel geven we u een praktijkvoorbeeld van zo&#8217;n Business Continuity Plan (fase 2), waarbij is ingebed, dat het plan actueel blijft nadat het eenmaal is opgesteld. De organisatie in het voorbeeld noemen we PPPP.     </p>
<h2>2. Inleiding Plan Business Continuity Plan</h2>
<h3>2.1 Aanleiding en probleemstelling *</h3>
<p>De stuurgroep &#8216;Informatievoorziening&#8217; heeft vastgesteld, dat de huidige plannen een onvoldoende beschrijving geven van wat er gedaan moet worden in geval van een calamiteit en met name van wat er moet gebeuren om in geval van een calamiteit, de schade zoveel mogelijk te beperken en de bedrijfsvoering zo snel mogelijk weer op te starten. Een belangrijke oorzaak hiervan is een gebrek aan bewustzijn van de risico&#8217;s, die beveiligingsincidenten in het algemeen met zich meebrengen.    </p>
<p>Bestaande producten, waarop het Business Continuity Plan (BCP) dient aan te sluiten zijn:    </p>
<ul>
<li>het bedrijfsnoodplan, waarin beschreven staat wat er gedaan moet worden bij fysieke calamiteiten om de schade zoveel mogelijk te beperken en het gevaar voor de medewerkers te reduceren;</li>
<li>het uitwijkplan, waarin beschreven staat hoe de uitwijk van de centrale sever plaats zal vinden in geval van een calamiteit.</li>
</ul>
<h3>2.2 Inhoud van dit plan van aanpak</h3>
<p>Dit plan beoogt zicht te geven op:    </p>
<ul>
<li>wat er gedaan moet worden (hoofdstuk 2);</li>
<li>de organisatie van het project (hoofdstuk 3);</li>
<li>de globale inspanning, de kosten en de planning van de uit te voeren activiteiten (hoofdstuk 4).</li>
</ul>
<h2>3. Doelstelling, aanpak en succesfactoren</h2>
<h3>3.1 Doelstelling project</h3>
<p>De doelstellingen van dit project zijn:    </p>
<ul>
<li>de continuïteit van de primaire bedrijfsvoering van het PPPP in het geval van calamiteiten te garanderen door:
<ul>
<li>het definiëren van preventieve maatregelen;</li>
<li>het opstellen van een draaiboek in geval van een calamiteit;</li>
<li>het verhogen van het beveiligingsbewustzijn van afdelingshoofden en functioneel applicatiebeheerders binnen PPPP.</li>
</ul>
</li>
</ul>
<h2>3.2 Aanpak</h2>
<p>De projectaanpak wordt beschreven aan de hand van de volgende afbeelding:</p>
<p><a href="http://zbc.nu/wp-content/uploads/2009/10/plan_bcp11.gif"><img title="Projectaanpak " src="http://zbc.nu/wp-content/uploads/2009/10/plan_bcp11.gif" alt="plan_bcp1" width="479" height="359" /></a></p>
<p>Er wordt gestart met een inventarisatieronde over de afdelingen. Doel hiervan is, de risico&#8217;s en aandachtspunten in kaart brengen m.b.t. de beveiliging in het algemeen en het geval van een calamiteit in het bijzonder.</p>
<p>Op grond van deze inventarisatie worden de totale risico&#8217;s voor het PPPP geanalyseerd en worden maatregelen gedefinieerd. Deze kunnen betrekking hebben op:    </p>
<ul>
<li>aanpassing van de uitwijkvoorziening;</li>
<li>het op te stellen draaiboek (reactief);</li>
<li>preventieve maatregelen.</li>
</ul>
<p>Vervolgens worden deze maatregelen nader uitgewerkt en vastgelegd.    </p>
<p>In de aanpak wordt ervan uitgegaan, dat PPPP zelf in staat is om invulling te geven aan het opstellen van dit Business Continuity Plan (BCP).    </p>
<p>De inspanning van ZBC zal zich met name richten op:    </p>
<ul>
<li>het opstellen van plannen;</li>
<li>het uitvoeren van een inventarisatieronde, om het bewustzijn te verhogen en vervolgens maatregelen te definiëren;</li>
<li>het aanmaken sjablonen, waarmee PPPP aan de slag kan;</li>
<li>begeleiding en review.</li>
</ul>
<h3>3.3 Kritische Succesfactoren</h3>
<p>Gezien de cultuur van PPPP, is het risico zeer aanzienlijk, dat het gecreëerde bewustzijn snel zal verdampen en het Business Continuity Plan (BCP) spoedig verouderd zal zijn.    </p>
<ul>
<li>Er zal daadwerkelijke besluitvorming moeten plaatsvinden door de stuurgroep en de directie omtrent nieuwe projecten en wijzigingsvoorstellen, waarbij de beveiligingsrisico&#8217;s expliciet een criterium vormen, dat getoetst dient te worden op de vastgestelde beleidsuitgangspunten in het informatiebeveiligingsbeleid.</li>
<li>Jaarlijks wordt door de IAD een audit georganiseerd, waarbij getoetst wordt of het vastgestelde beleid gehandhaafd is en het beveiligingsniveau niet is teruggelopen.</li>
</ul>
<p>Belangrijke succesfactoren voor het project zijn:    </p>
<ul>
<li>beschikbaarheid en aandacht van afdelingsmanagers en functioneel applicatiebeheerders;</li>
<li>het nakomen van afgesproken acties.<br />
 </li>
</ul>
<h2>4. Organisatie</h2>
<p>De projectorganisatie heeft de volgende structuur:</p>
<p><a href="http://zbc.nu/wp-content/uploads/2009/10/plan_bcp2.gif"><img title="Structuur projectorganisatie" src="http://zbc.nu/wp-content/uploads/2009/10/plan_bcp2.gif" alt="plan_bcp2" width="479" height="359" /></a></p>
<p>Opdrachtgever is de stuurgroep &#8216;Informatievoorziening&#8217;.    </p>
<p>De stuurgroep is verantwoordelijk voor de vaststelling van het Business Continuity Plan (BCP). De stuurgroep is bevoegd om namens  PPPP te bepalen, welke risico&#8217;s acceptabel zijn en wat een acceptabele kritische tijdsduur is voor continuering van bedrijfsprocessen in het geval van een calamiteit.    </p>
<p>Actiehouder is xxxx. Hij is de eigenaar van dit plan en verantwoordelijk voor het doen uitvoeren van dit plan. Hij is bevoegd om beslissingen te nemen over wijzigingen op dit plan, waarover hij achteraf verantwoording dient af te leggen aan de stuurgroep.    </p>
<p>Externe begeleiding wordt gegeven door ZBC. ZBC is verantwoordelijk voor het geven van inzicht in beveiligingsrisico&#8217;s bij de betrokkenen, het voorstellen van een samenhangend pakket aan maatregelen en het aanleveren van sjablonen, waarmee de producten van dit project gerealiseerd kunnen worden. ZBC is bevoegd om wijzigingen voor te stellen en probleemrapportages te geven aan de actiehouder.    </p>
<p>De afdelingshoofden zijn verantwoordelijk voor de inventarisatie van alle kritische componenten in geval van een calamiteit en het (doen) uitvoeren van overeengekomen maatregelen. Voorts zijn zij in het kader van het informatiebeveiligingsbeleid verantwoordelijk voor de naleving van de beleidsuitgangspunten.    </p>
<p>Hoofd ICT is verantwoordelijk voor de realisatie van een up-to-date uitwijkplan, waarin de uitwijk van alle noodzakelijke centrale ICT-voorzieningen geregeld is. Tevens is hij verantwoordelijk voor de daadwerkelijke invulling van de sjablonen. De uitvoering gebeurt door medewerkers van de ICT-afdeling.    </p>
<p>Hoofd AZ is verantwoordelijk voor de realisatie van de fysieke en infrastructurele maatregelen, welke tijdens dit project vastgesteld worden.     </p>
<h2>5. Activiteitenplan</h2>
<h3>5.1 Hoofdactiviteiten</h3>
<table border="1" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td width="52" valign="top"><strong>1</strong></td>
<td width="473" valign="top"><strong>Planvorming  </strong></td>
</tr>
<tr>
<td width="52" valign="top"><strong>2</strong></td>
<td width="473" valign="top"><strong>Inventarisatie risico&#8217;s, behoeften en mogelijkheden</strong></td>
</tr>
<tr>
<td width="52" valign="top">2.1</td>
<td width="473" valign="top">    Afstemming risico&#8217;s en behoeften gebruikersafdelingen</td>
</tr>
<tr>
<td width="52" valign="top">2.2</td>
<td width="473" valign="top">    Bepalen uitwijkmogelijkheden voor de rest van de technische infrastructuur</td>
</tr>
<tr>
<td width="52" valign="top">2.3</td>
<td width="473" valign="top">    Definitie maatregelen</td>
</tr>
<tr>
<td width="52" valign="top">2.4</td>
<td width="473" valign="top">    Opstellen oplossingsvoorstel en actieplan</td>
</tr>
<tr>
<td width="52" valign="top">2.5</td>
<td width="473" valign="top">    Accorderen oplossingsvoorstel en actieplan</td>
</tr>
<tr>
<td width="52" valign="top"><strong>3</strong></td>
<td width="473" valign="top"><strong>Opstellen BCP </strong></td>
</tr>
<tr>
<td width="52" valign="top">3.1</td>
<td width="473" valign="top">    Opstellen basissjablonen</td>
</tr>
<tr>
<td width="52" valign="top">3.2</td>
<td width="473" valign="top">    Bepalen uitwijkscenario en uitwijkplannen per platform</td>
</tr>
<tr>
<td width="52" valign="top">3.3</td>
<td width="473" valign="top">    Ontwikkelen minimaal draaiboek</td>
</tr>
<tr>
<td width="52" valign="top">3.4</td>
<td width="473" valign="top">    Realiseren preventieve maatregelen</td>
</tr>
<tr>
<td width="52" valign="top">3.5</td>
<td width="473" valign="top">    Beleggen en vastleggen structurele verantwoordelijkheden</td>
</tr>
<tr>
<td width="52" valign="top">3.6</td>
<td width="473" valign="top">    Accorderen Business Continuity Plan (BCP)</td>
</tr>
<tr>
<td width="52" valign="top"><strong>4</strong></td>
<td width="473" valign="top"><strong>Testen BCP </strong></td>
</tr>
<tr>
<td width="52" valign="top">4.1</td>
<td width="473" valign="top">    Opstellen testplan</td>
</tr>
<tr>
<td width="52" valign="top">4.2</td>
<td width="473" valign="top">    Uitvoeren test volgens het Business Continuity Plan (BCP)</td>
</tr>
<tr>
<td width="52" valign="top">4.3</td>
<td width="473" valign="top">    Zonodig bijstellen van het Business Continuity Plan (BCP)</td>
</tr>
</tbody>
</table>
<h3>5.2 Fase 2: Onderzoeken risico&#8217;s, behoeften en mogelijkheden</h3>
<table border="1" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td width="33" valign="top"><strong>2</strong></td>
<td width="265" valign="top"><strong>Onderzoeken risico&#8217;s, behoeften en mogelijkheden </strong></td>
<td width="123" valign="top"><strong>Uitvoering</strong></td>
<td width="57" valign="top"><strong>Effort</strong><strong> (uur)</strong></td>
<td width="47" valign="top"><strong>Week#</strong></td>
</tr>
<tr>
<td width="33" valign="top">2.1</td>
<td width="265" valign="top">Afstemming risico&#8217;s en behoeften gebruikersafdelingen</td>
<td width="123" valign="top">Afd. hoofden, FAB, ZBC</td>
<td width="57" valign="top">N*348 </td>
<td width="47" valign="top">28-37</td>
</tr>
<tr>
<td width="33" valign="top">2.2</td>
<td width="265" valign="top">Bepalen uitwijkmogelijkheden voor de rest van de technische infrastructuur</td>
<td width="123" valign="top">Netwerkbeheerder<br />
Hoofd ICT</td>
<td width="57" valign="top">728 </td>
<td width="47" valign="top">28-37</td>
</tr>
<tr>
<td width="33" valign="top">2.3</td>
<td width="265" valign="top">Definitie maatregelen</td>
<td width="123" valign="top">Afd. hoofden, FAB, ZBC</td>
<td width="57" valign="top">N*148 </td>
<td width="47" valign="top">29-39</td>
</tr>
<tr>
<td width="33" valign="top">2.4</td>
<td width="265" valign="top">Opstellen oplossingsvoorstel en actieplan</td>
<td width="123" valign="top">ZBC</td>
<td width="57" valign="top">16</td>
<td width="47" valign="top">39-40</td>
</tr>
<tr>
<td width="33" valign="top">2.5</td>
<td width="265" valign="top">Accorderen oplossingsvoorstel en actieplan</td>
<td width="123" valign="top">Stuurgroep</td>
<td width="57" valign="top">1</td>
<td width="47" valign="top">41</td>
</tr>
<tr>
<td width="33" valign="top">2.6</td>
<td width="265" valign="top">Communicatietijd/regelwerk</td>
<td width="123" valign="top">Hoofd  ICT<br />
ActiehouderZBC</td>
<td width="57" valign="top">88 12  </td>
<td width="47" valign="top">28-41</td>
</tr>
</tbody>
</table>
<p><br class="spacer_" /></p>
<p>In activiteit 2.1 krijgen de afdelingshoofden van tevoren een vragenlijst toegestuurd om deze gedeeltelijk in te vullen. Vervolgens worden gesprekken gepland met elk afdelingshoofd en de FAB om met name dieper in te gaan op de risico&#8217;s en bedreigingen en de wijze waarop deze afgedekt kunnen worden.    </p>
<p>De intussen gestarte actie binnen de ICT-afdeling om de uitwijkmogelijkheden van de rest van de infrastructuur te bepalen, wordt ondergebracht in activiteit 2.2.    </p>
<p>In activiteit 2.3 worden de verzamelde gegevens uit act 2.1 vastgelegd en geanalyseerd en worden maatregelen gedefinieerd, welke vervolgens weer worden afgestemd met de betrokkenen.    </p>
<p>De resultaten uit 2.3 worden in activiteit 2.4 uitgewerkt tot een oplossingsvoorstel, waarin ook wordt aangegeven, welke risico&#8217;s niet worden afgedekt. Tevens wordt een actieplan uitgewerkt.    </p>
<p>In activiteit 2.5 accordeert de stuurgroep het oplossingsvoorstel en het actieplan en accepteert de niet afgedekte risico&#8217;s.    </p>
<h3>5.3 Fase 3: Opstellen BCP</h3>
<table border="1" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td width="42" valign="top"><strong>3</strong></td>
<td width="265" valign="top"><strong>Opstellen BCP </strong></td>
<td width="132" valign="top"><strong>Uitvoering</strong></td>
<td width="85" valign="top"><strong>Effort (uur)</strong></td>
<td width="57" valign="top"><strong>Week#</strong></td>
</tr>
<tr>
<td width="42" valign="top">3.1</td>
<td width="265" valign="top">Opstellen basis-sjablonen</td>
<td width="132" valign="top">Hoofd ICT <br />
Actiehouder ZBC</td>
<td width="85" valign="top">33 16  </td>
<td width="57" valign="top">42-43</td>
</tr>
<tr>
<td width="42" valign="top">3.2</td>
<td width="265" valign="top">Bepalen uitwijkscenario en uitwijkplannen per platform</td>
<td width="132" valign="top">Netwerkbeheerder?Hoofd ICT</td>
<td width="85" valign="top">488 </td>
<td width="57" valign="top">40-46</td>
</tr>
<tr>
<td width="42" valign="top">3.3</td>
<td width="265" valign="top">Ontwikkelen minimaal draaiboek</td>
<td width="132" valign="top">Div. betrokkenen<br />
Coördinator *1ZBC</td>
<td width="85" valign="top">4040 8  </td>
<td width="57" valign="top">43-47</td>
</tr>
<tr>
<td width="42" valign="top">3.4</td>
<td width="265" valign="top">Realiseren preventieve maatregelen</td>
<td width="132" valign="top">Div. betrokkenen<br />
Coördinator ZBC</td>
<td width="85" valign="top">4024 4  </td>
<td width="57" valign="top">43-47</td>
</tr>
<tr>
<td width="42" valign="top">3.5</td>
<td width="265" valign="top">Beleggen en vastleggen structurele verantwoordelijkheden</td>
<td width="132" valign="top">Div. betrokkenen<br />
Coördinator ZBC</td>
<td width="85" valign="top">2424 12  </td>
<td width="57" valign="top">43-47</td>
</tr>
<tr>
<td width="42" valign="top">3.6</td>
<td width="265" valign="top">Accorderen Business Continuity Plan (BCP)</td>
<td width="132" valign="top">Stuurgroep</td>
<td width="85" valign="top">1</td>
<td width="57" valign="top">28-41</td>
</tr>
<tr>
<td width="42" valign="top">3 .7</td>
<td width="265" valign="top">Communicatietijd/ regelwerk</td>
<td width="132" valign="top">Hoofd ICT<br />
Actiehouder ZBC</td>
<td width="85" valign="top">88 12  </td>
<td width="57" valign="top">28-41</td>
</tr>
</tbody>
</table>
<table border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td width="26" valign="top">
<h6>*</h6>
</td>
<td width="588" valign="top">
<h6>Er zal iemand aangewezen moeten worden, die ervoor zorgt, dat de taken uitgezet en weer gebundeld worden en die zelf ook een stuk invulling geeft aan het PPPP-brede stuk. Dit geldt ook voor de volgende twee activiteiten. Als deze rol door ZBC ingevuld wordt, vervallen de andere voor ZBC gespecificeerde uren in act. 3.3-3.5.</h6>
</td>
</tr>
</tbody>
</table>
<p><br class="spacer_" /></p>
<p>In activiteit 3.1 worden de basissjablonen opgesteld conform de behoeften van het PPPP. Op basis van bestaande sjablonen wordt hierbij een selectie gemaakt voor de onderdelen, die de PPPP-sjablonen moeten bevatten.    </p>
<p>In activiteit 3.2 wordt per platform het uitwijkplan gedefinieerd en worden de onderlinge afhankelijkheden bepaald en vastgelegd in het uitwijkscenario.    </p>
<p>In activiteit 3.3 wordt invulling gegeven aan het draaiboek, zoals dat geldt tijdens een evt. optredende calamiteit. Hierbij is het van belang, dat m.n. verantwoordelijkheden en bevoegdheden eenduidig worden toegekend.    </p>
<p>In activiteit 3.4 worden alle zaken gerealiseerd, die nu geregeld moeten worden om in het geval van een calamiteit ook daadwerkelijk uit te kunnen wijken. Dit varieert van de calamiteitenschakeling van KPN, afspraken met leveranciers m.b.t. de kooplijst tot en met de bemanning van de telefooncentrale in geval van uitwijk.    </p>
<p>In activiteit 3.5 worden de zaken geregeld die nodig zijn om in geval van een uitwijk direct te kunnen beschikken over actuele lijsten van medewerkers en relaties en om kritische niet geautomatiseerd opgeslagen gegevens weer beschikbaar te kunnen krijgen.    </p>
<p>In 3.4 worden de uitkomsten van 3.2 en 3.3 vertaald in concrete acties, die vervolgens uitgezet dienen te worden bij leveranciers en intern. De inspanning die deze activiteit met zich meebrengt, is sterk afhankelijk van de gekozen oplossing.    </p>
<p>De resultaten uit act 3.4 zullen in act 3.5 veelal bekrachtigd moeten worden in de vorm van contracten.    </p>
<p>Voorts zullen in act 3.6 plannen gemaakt moeten worden voor de deeltests en de integrale test.    </p>
<p>Tenslotte wordt de voorziening zoals deze  is uitgewerkt beoordeeld in act 3.7.    </p>
<h3>5.4 Fase 4: Test</h3>
<p>De uitvoering van de test is de verantwoordelijkheid van de lijnorganisatie van PPPP. De uitvoering dient plaats te vinden zoals is vastgelegd in het Business Continuity Plan (BCP). Op dit moment is hierover geen planning af te geven.    </p>
<h3>5.5 Inzet per medewerker</h3>
<table border="1" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td width="203" valign="top"><strong>Betrokkene</strong></td>
<td width="115" valign="top"><strong>Uren</strong></td>
</tr>
<tr>
<td width="203" valign="top">Actiehouder</td>
<td width="115" valign="top">19</td>
</tr>
<tr>
<td width="203" valign="top">Hoofd ICT</td>
<td width="115" valign="top">35</td>
</tr>
<tr>
<td width="203" valign="top">Netwerkbeheerder?</td>
<td width="115" valign="top">104</td>
</tr>
<tr>
<td width="203" valign="top">Afdelingshoofden en FAB-ers</td>
<td width="115" valign="top">96</td>
</tr>
<tr>
<td width="203" valign="top">Diverse betrokkenen</td>
<td width="115" valign="top">136</td>
</tr>
<tr>
<td width="203" valign="top">Coördinator</td>
<td width="115" valign="top">88</td>
</tr>
<tr>
<td width="203" valign="top">Stuurgroep</td>
<td width="115" valign="top">2</td>
</tr>
<tr>
<td width="203" valign="top">ZBC</td>
<td width="115" valign="top">176</td>
</tr>
</tbody>
</table>
<h2>6.  Nawoord</h2>
<p>Wij hebben u in dit artikel een beeld gegeven van wat er ongeveer moet gebeuren om uw BCP weer up-to-date te maken. De rol van ZBC kan uiteraard ook ingevuld worden door een van uw eigen Door de ‘Cursus Business Continuity Management’ te volgen kunt u behoed worden voor de belangrijkste valkuilen en kunt u ook beschikken over de sjablonen en voorbeelden. Want kunt u zich in deze tijd van recessie nog een strop riskeren van onverzekerde schade bij calamiteit? Het Business Continuity Plan zorgt ervoor, dat u de schade van zo’n tegenvaller minimaliseert.</p>
<h6>Oorspronkelijke versie: 18 november 2007</h6>
<table border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td width="26" valign="top">
<h6>*</h6>
</td>
<td width="588" valign="top">
<h6>PPPP heeft de uitwijk voor de centrale servers geregeld bij een uitwijkcentrum, maar de uitwijk voor het netwerk en de externe verbindingen moeten nog geregeld worden.</h6>
</td>
</tr>
</tbody>
</table>
]]></content:encoded>
			<wfw:commentRss>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/voorbeeld-plan-van-aanpak-fase-2-van-uw-business-continuity-plan-bcp-of-calamiteitenplan/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Outsourcing contracten dekken zelden de business continuity van de klant af</title>
		<link>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/outsourcing-contracten-dekken-zelden-de-business-continuity-van-de-klant-af/</link>
		<comments>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/outsourcing-contracten-dekken-zelden-de-business-continuity-van-de-klant-af/#comments</comments>
		<pubDate>Mon, 09 Feb 2009 07:55:17 +0000</pubDate>
		<dc:creator>Wiebe Zijlstra</dc:creator>
				<category><![CDATA[Calamiteitenplan - BCP]]></category>
		<category><![CDATA[Calamiteitenplan, Business Continuity Management]]></category>
		<category><![CDATA[ICT, Security en calamiteitenplan]]></category>
		<category><![CDATA[applicaties]]></category>
		<category><![CDATA[back-up]]></category>
		<category><![CDATA[backup]]></category>
		<category><![CDATA[beheer]]></category>
		<category><![CDATA[business continuity]]></category>
		<category><![CDATA[continuiteit]]></category>
		<category><![CDATA[contract]]></category>
		<category><![CDATA[dekking]]></category>
		<category><![CDATA[efficiency]]></category>
		<category><![CDATA[eigendom]]></category>
		<category><![CDATA[ICT]]></category>
		<category><![CDATA[outsourcing]]></category>
		<category><![CDATA[risico]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[SLA]]></category>
		<category><![CDATA[software]]></category>
		<category><![CDATA[website]]></category>

		<guid isPermaLink="false">http://zbc.nu/?p=692</guid>
		<description><![CDATA[Outsourcing draagt vaak bij aan de beschikbaarheid van uw ICT, maar ligt u wel eens wakker van de niet eens onwaarschijnlijke horrorscenario's die ook kunnen optreden? Lees en huiver!

]]></description>
			<content:encoded><![CDATA[<p><strong>Inhoudsopgave</strong></p>
<ol>
<li>Efficiency en business continuity zijn vijanden</li>
<li>Business Continuity draait om gevolgschade</li>
<li>Outsourcing gaat ook om efficiency</li>
<li>Heeft u een dubbele breedbandverbinding?</li>
<li>Outsourcing van bedrijfsapplicaties en websites</li>
<li>Hoe groot is het risico? </li>
</ol>
<h2>1. Efficiency en business continuity zijn vijanden</h2>
<p>De afgelopen jaren hebben veel bedrijven zich ingespannen om hun efficiency te verbeteren. En met succes. Al het vet werd van de botten gesneden. Dubbel werk was taboe. Elke speling of voorraadvorming werd indachtig het just-in-time principe geëlimineerd.<br />
Als er echter in geval van een calamiteit een processtap of een productiemiddel uitvalt, dan moet er een uitwijkscenario zijn om toch aan de leveringsverplichting te kunnen voldoen. Want daarop is immers business continuity gebaseerd; single points of failure moeten worden uitgesloten. Om niet het risico te lopen op een onbeheersbare calamiteit zijn dus buffers nodig.<br />
Vroeger ging men zover, dat er zelfs een tweede computerruimte werd ingericht, voor het geval de eerste langdurig zou uitvallen door een calamiteit. Dat is natuurlijk een wel heel dure oplossing voor een situatie die zich waarschijnlijk nooit zal voordoen. Dergelijke oplossingen zijn tegenwoordig steeds minder nodig, want een ICT-crisis weet men intussen wel te bezweren. (Zie ook &#8216;ICT steeds minder het probleem bij een calamiteitenplan&#8217;.) In 2008 is uit een risicoanalyse van de overheid duidelijk geworden dat momenteel een overstroming en het uitbreken van een pandemie de belangrijkste dreigingen zijn. Aangezien bestuurders er echter geen enkele invloed op kunnen uitoefenen of zulke rampen zich wel of niet zullen voordoen, en er ook geen betrouwbaar scenario beschikbaar is voor wat de invloed van die calamiteiten zal zijn op de business continuity, is men maar weer gewoon overgegaan tot de orde van de dag, nadat dit bekend was gemaakt. De kans dat eerder een andersoortige calamiteit plaatsvindt, is tenslotte aanzienlijk, zoals we in de afgelopen periode wel hebben gezien.<br />
Er is geen bestuurder die zich nu, tijdens de huidige recessie voor het hoofd slaat, omdat hij de dreiging van die recessie niet heeft onderkend. Iedere bestuurder weet, dat als hij zich in de afgelopen jaren via buffers en reserveringen zou hebben gewapend tegen die dreiging, hij de aandeelhouders over zich heen zou hebben gekregen, omdat hij onvoldoende winst maakte. Oorzaak van de kredietcrisis is desalniettemin het gebrek aan buffers: kredieten die werden verstrekt zonder deugdelijk onderpand terwijl de risico&#8217;s werden verspreid over bancaire partijen en financiële instellingen die zelf ook geen vet op de botten hadden. </p>
<h2>2. Business Continuity draait om gevolgschade</h2>
<p>Toen banken begonnen om te vallen waren de gevolgen groot. De directe schade kon nog wel afgewenteld worden op de aandeelhouders. De indirecte schade was echter veel groter. Banken verloren het vertrouwen in elkaars kredietwaardigheid en stopten met het verstrekken van kredieten. Aan elkaar en aan bedrijven. Ze realiseerden zich dat het potje met vertrouwen leeg was en dat ze geen buffers hadden om weer vertrouwen te kopen.<br />
In feite is geld niet meer dan een schuldbekentenis dat de andere partij recht heeft op waarde. Maar de relatie tussen waarde en geld is zoekgeraakt. (Zie ook &#8216;MVO is ondernemen met een ander doel dan alleen geld verdienen&#8217;.) Geld verdienen was  de laatste jaren &#8216;hot&#8217; en werd veel belangrijker gevonden dan onderliggende waarde te creëren. Het bancaire systeem moest zo wel crashen. Kortom, de huidige recessie als gevolg van die crash was in feite al jaren aan te zien komen. </p>
<h2>3. Outsourcing gaat ook om efficiency</h2>
<p>Een ander voorbeeld van een sluipend gevaar dat veel organisaties bedreigt, is de trend van uitbesteding of outsourcing. Ook hier zien we, dat ogenschijnlijk de individuele risico&#8217;s per bedrijf worden ondergebracht in het systeem. Simpel gezegd kiezen bedrijven ervoor om hun informatiesystemen uit te besteden en onder te brengen in een datacenter. Dus de (meestal standaard)software draait op (standaard)servers van het datacenter en de data worden uiteraard ook in het datacenter opgeslagen. Dit biedt op het eerste gezicht door schaalgrootte belangrijke voordelen voor de klant als lagere kosten, maar ook een betere security (vooral de fysieke beveiliging is veel beter en alles is dubbel uitgevoerd) en uitwijk is simpel te regelen naar een willekeurig ander datacenter. Door server- en datavirtualisatie naar een tweede productiecentrum, kan zelfs een beschikbaarheid van nagenoeg 100% gerealiseerd worden. (Zie ook &#8216;ICT steeds minder het probleem bij een calamiteitenplan&#8217;.)<br />
Onder de aanname dat het datacenter niet failliet gaat en de leverancier van snelle internetdiensten nooit een ernstige storing heeft, klopt het dat de situatie vanuit het perspectief van beveiliging aanzienlijk is verbeterd. Helaas zijn juist op deze punten bij outsourcing &#8216;single points of failure&#8217; ontstaan. We laten een paar mogelijke calamiteiten de revue passeren. En we hoeven u niet uit te leggen, dat het zeker niet onwaarschijnlijk is dat deze calamiteiten zich zullen voordoen. </p>
<h2>4. Heeft u een dubbele breedbandverbinding?</h2>
<p>Uw breedbandinternetverbinding heeft u hoogstwaarschijnlijk al sinds jaar en dag uitbesteed. Vroeger ging het vaak om huurlijnen, maar tegenwoordig in veel gevallen om een DSL-verbinding. Dat deze verbinding er een aantal dagen uit kan liggen, heeft afgelopen najaar een fors aantal bedrijven gemerkt. Een storing in het KPN-netwerk maakte toegang tot internet onmogelijk, waarbij dus ook de extern draaiende bedrijfsapplicaties inclusief de mail niet gebruikt konden worden.<br />
De oplossing voor zo&#8217;n probleem is niet zo ingewikkeld. Vrijwel ieder pand in Nederland heeft ook een kabelaansluiting. De kosten van een internetaansluiting over de kabel als uitwijk zijn verwaarloosbaar, zeker als je ze afzet tegen de schade die ontstaat als gedurende een aantal dagen niet gebruiken kan worden gemaakt van de extern draaiende applicaties. Het is hierbij wel van wezenlijk belang het snel overschakelen van de DSL-lijn naar de kabel en andersom grondig te testen. Zelf hebben we ervaren, dat met name de mail voor de nodige problemen kan zorgen. </p>
<h2>5. Outsourcing van bedrijfsapplicaties en websites</h2>
<p>Complexer ligt het vaak als het gaat om de outsourcing van bedrijfsapplicaties. Als deze buiten de deur draaien, zien we meestal dat de beschikbaarheid van deze applicaties hoger wordt. Gevaar is echter, dat hier diverse partijen bij betrokken zijn en er diverse single points of failure zijn. We zullen dit toelichten aan de hand van de volgende afbeelding:</p>
<div id="attachment_717" class="wp-caption alignnone" style="width: 370px"><a href="http://zbc.nu/wp-content/uploads/2009/10/outsourcing_continuity11.gif"><img class="size-full wp-image-717  " title="Outsourcing en single points of faillure" src="http://zbc.nu/wp-content/uploads/2009/10/outsourcing_continuity11.gif" alt="Outsourcing en single points of faillure" width="360" height="269" /></a><p class="wp-caption-text">Figuur1: Outsourcing en single points of faillure</p></div>
<p>De klant koopt of huurt de bedrijfssoftware van de leverancier. Deze bedrijfssoftware wordt ondergebracht in een datacenter (meestal een derde partij), waar ook de data opgeslagen worden. De softwareleverancier is doorgaans verantwoordelijk voor het onderhoud van de software. Hij stelt nieuwe versies of patches beschikbaar aan het data center, dat ze installeert. Het data center is verantwoordelijk voor het technisch beheer van de data.  Belangrijkste topics voor de business continuity zijn hierbij:</p>
<ul>
<li>back-up en recovery van het &#8216;systeem&#8217;;</li>
<li>beschikbaarheid van het &#8216;systeem&#8217;.</li>
</ul>
<p>In het woordje &#8216;systeem&#8217; zit echter vaak het probleem. Voor de klant is het systeem alles wat niet op de werkplek draait. Dat de leverancier van de verbinding (de ISP) een vierde partij is, daar kan hij zich nog wat bij voorstellen, maar dat achter deze ISP ook nog een partij zit, die voor de fysieke verbinding verantwoordelijk is, dat wordt doorgaans over het hoofd gezien.<br />
Een ander struikelblok is de kwestie: &#8216;wie is nu de eigenaar van wat?&#8217;. De rechten van de software liggen bij de softwareleverancier. Als deze stopt met het onderhoud van de software, dan heeft de klant niet per definitie het recht om de software zelf in beheer te nemen en te onderhouden, tenzij er een escrow-overeenkomst van toepassing is. Gelukkig is bij een standaardsoftwarepakket de software voor de softwareleverancier een belangrijk asset, dat zelfs bij een faillissement van de softwareleverancier door de curator te gelde zal worden gemaakt. Meestal is echter niet contractueel vastgelegd, dat de softwareleverancier hier zijn medewerking aan moet verlenen.<br />
De data zijn vaak een nog groter probleem. Deze zijn natuurlijk eigendom van de klant. Maar hoe kan hij hierover beschikken? Als het datacenter afbrandt, dan is er natuurlijk altijd nog de back-up, waarop deze data zijn vastgelegd. Deze back-up kan teruggezet worden in een ander datacenter met een vergelijkbare configuratie. Dit kan zeker als ook de bedrijfssoftware met alle instellingen op de back-up beschikbaar is. Helaas wordt dat nooit contractueel vastgelegd. Nog erger is het, als het datacenter stopt en nog wat geld wil verdienen. Het medium van de back-up is van het data center en dit kan dreigen het medium te vernietigen, tenzij de klant bereid is het te kopen. Als hij dat niet doet, is hij zijn data kwijt. Doorgaans betekent dat een forse kostenpost. En ik moet zeggen, dat ik nog nooit heb gezien, dat dit contractueel geregeld is. </p>
<h2>6. Hoe groot is het risico?</h2>
<p>In de afgelopen 10 jaar hebben u en ik meer totaal onverwachte calamiteiten langs zien komen, dan we ooit voor mogelijk gehouden hebben:</p>
<ul>
<li>11 september;</li>
<li>het faillissement van de bancaire sector;</li>
<li>de wetgever (Den Haag, Brussel) als belangrijkste dreiging voor de business continuity van complete bedrijfstakken;</li>
<li>de tsunami;</li>
<li>de klimaatcrisis?</li>
</ul>
<p>Amerikanen zeggen &#8216;Shit happens&#8217;. Ik denk, dat we hier inderdaad rekening mee moeten houden. Het is vooral de mens, die een onzekere factor vormt in de systemen die we gecreëerd hebben. Daardoor zullen calamiteiten ons blijven verrassen. Zeker nu we uit efficiency overwegingen steeds meer &#8216;single points of failure&#8217; creëren. Voorkomen van dergelijke calamiteiten is onmogelijk. (Zie ook &#8216;Minister BZK volhardt in denkfout bescherming vitale infrastructuur&#8217;.)<br />
De vooruitgang is niet te stoppen. We kunnen er moeilijk naar gaan streven om maar weer in grotten te gaan wonen.. Efficiency moet om concurrerend te blijven. Ondernemen is meer dan ooit risico nemen. Laat dit echter niet verworden tot een onbewust risico lopen. Het gaat erom dat we risico&#8217;s bewust nemen. We moeten er echter wel voor zorgen, dat we adequaat kunnen reageren als een calamiteit zich voordoet, door vooraf na te denken over de risico&#8217;s en de voorwaarden om adequaat te kunnen reageren.<br />
Ook outsourcing hebben we nodig. (Zie &#8216;Outsourcing van werkplekbeheer is meer dan kostenbesparing alleen&#8217;.) U zult zich alleen wel bewust moeten zijn van de risico&#8217;s die dit met zich meebrengt. En dat betekent niet dat u vooraf draconische maatregelen moet treffen of moet eisen van de leverancier. Het betekent dat u goede contractafspraken moet maken, zodat u in elk geval voorkomt dat u gedwongen kunt worden om uw eigen bezittingen (data) terug te kopen. ICT wordt steeds meer een zaak van goed inkopen en steeds minder van techniek en beheer. (Zie ook &#8216;Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens&#8217;.)<br />
Misschien bent u ervan overtuigd dat dit niet voor u geldt. Maar hebt u er wel eens over nagedacht hoe het precies zit met uw website?</p>
]]></content:encoded>
			<wfw:commentRss>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/outsourcing-contracten-dekken-zelden-de-business-continuity-van-de-klant-af/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>ICT steeds minder het probleem bij een calamiteitenplan</title>
		<link>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/ict-steeds-minder-het-probleem-bij-een-calamiteitenplan/</link>
		<comments>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/ict-steeds-minder-het-probleem-bij-een-calamiteitenplan/#comments</comments>
		<pubDate>Tue, 01 Jul 2008 14:40:01 +0000</pubDate>
		<dc:creator>Wiebe Zijlstra</dc:creator>
				<category><![CDATA[Calamiteitenplan - BCP]]></category>
		<category><![CDATA[Calamiteitenplan, Business Continuity Management]]></category>
		<category><![CDATA[ICT en Facility Management]]></category>
		<category><![CDATA[ICT, Security en calamiteitenplan]]></category>
		<category><![CDATA[aanpak]]></category>
		<category><![CDATA[applicaties]]></category>
		<category><![CDATA[bedrijfscontinuiteit]]></category>
		<category><![CDATA[bedrijfsrisico]]></category>
		<category><![CDATA[business continuity]]></category>
		<category><![CDATA[calamiteitenplan]]></category>
		<category><![CDATA[ICT]]></category>
		<category><![CDATA[ketenafhankelijkheid]]></category>
		<category><![CDATA[scope]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[telewerken]]></category>
		<category><![CDATA[valkuilen]]></category>
		<category><![CDATA[virtualisatie]]></category>
		<category><![CDATA[webbased]]></category>

		<guid isPermaLink="false">http://zbc.nu/?p=648</guid>
		<description><![CDATA[Door webbased applicaties en servervirtualisatie wordt de beschikbaarheid van ICT steeds minder een issue voor bedrijfscontinuïteit. De aandacht verschuift naar ketenafhankelijkheid en communicatie. Toch is in de afgelopen tien jaar de aanpak voor het opzetten van een calamiteitenplan in veel bedrijven nauwelijks gewijzigd.]]></description>
			<content:encoded><![CDATA[<p><strong>Inhoudsopgave</strong></p>
<ol>
<li>Herinnert u zich de eeuwwisseling nog?</li>
<li>Weer aandacht voor het calamiteitenplan</li>
<li>Valkuilen in de aanpak</li>
<li>ICT geen issue door virtualisatie en webbased software</li>
<li>De scope van het calamiteitenplan</li>
<li>Keuzes maken op basis van bedrijfsrisico&#8217;s </li>
</ol>
<h2>1. Herinnert u zich de eeuwwisseling nog?</h2>
<p>Voor de ICT is continuïteit nauwelijks nog een issue. Dankzij  virtualisatie en webbased standaardapplicaties is de uitval van beschikbaarheid terug te brengen tot hooguit enkele uren. In het kader van bedrijfscontinuïteit speelt ICT dan ook een steeds minder belangrijke rol. Daarentegen neemt de ketenafhankelijkheid toe. <br />
Toch worden calamiteitenplannen nog steeds opgezet met ICT als centraal aandachtspunt, zoals dat bijvoorbeeld werd gedaan toen het jaar 2000 in aantocht was en men verwachtte dat alle ICT-systemen op tilt zouden slaan. U herinnert het zich vast nog wel, tegen de eeuwwisseling ontstond paniek in veel bedrijven. Verloven werden ingetrokken en hulptroepen gemobiliseerd. Vele miljarden werden uitgegeven aan het omzetten van ddmmjj naar ddmmjjjj en voor het maken van calamiteitenplannen. En dan ging het niet om algemene calamiteitenplannen, maar om calamiteitenplannen die vrijwel volledig gericht waren op de ICT-applicaties en de ICT-infrastructuur en met de ICT-manager als probleemeigenaar en opdrachtgever. U weet natuurlijk ook nog wel hoe dit afgelopen is. Afgezien van een aantal kleine incidenten bleef de wereld doordraaien. Pessimisten voorzagen rampen, maar dat viel alleszins mee. Twee jaar later werd de euro ingevoerd. En ook toen ontstonden er geen problemen. Toen daarna ook nog eens de internet zeepbel uiteenspatte, daalde de invloed van ICT-managers in rap tempo en daarmee eveneens de omvang van hun budgetten.<br />
Gevolg van de kleinere budgetten was dat de aandacht voor calamiteitenplannen eveneens in hoog tempo daalde.  Een ICT-manager kan zijn budget tenslotte maar eenmaal uitgeven. En de bestaande calamiteitenplannen waren uiteindelijk nog maar een paar jaar oud en hadden bewezen up-to-date te zijn. Dat dat laatste onzin was, viel maar weinigen op. Er had helemaal geen calamiteit plaatsgevonden. Het calamiteitenplan was dus ook niet getoetst. (Zie ook &#8216;Uw Business Continuity Plan nog de basis voor uw continuïteit?&#8217;.) </p>
<h2>2. Weer aandacht voor het calamiteitenplan</h2>
<p>Enkele jaren later werd de beheersing van calamiteiten opnieuw op de agenda gezet, nu in het kader van Tabaksblat en SOX. Na een serie beursschandalen die zelfs leidden tot het einde van een aantal gerenommeerde bedrijven, moest in het belang van de aandeelhouders de bedrijfscontinuïteit geborgd worden en moesten beursgenoteerde bedrijven in het kader van hun riskmanagement een business continuity plan ofwel een calamiteitenplan kunnen overleggen.<br />
Er werd weer bij de ICT-manager aangeklopt. Hij had hier immers ervaring met zo&#8217;n plan. Vaak ook trok de ICT-manager zelf dit probleem naar zich toe. Blij, dat er een probleemeigenaar gevonden was voor business continuity ging men vervolgens weer over tot de orde van de dag.<br />
De nadruk bij de aanpak van business continuity kwam hierdoor echter weer op de ICT te liggen. Dus weer alsof de ICT de belangrijkste factor is voor de bedrijfscontinuïteit. (Zie ook &#8216;Is bedrijfscontinuïteit een zaak van de ICT-manager?&#8217;) En zo er iets  mocht zijn dat niet onder de ICT valt, zo veronderstelden de ICT-managers, dat  zou dan wel onder het BHV-plan vallen. Maar dat is natuurlijk een misverstand. Immers,  als iedereen bij een calamiteit in veiligheid is gebracht, dan is men klaar met het BHV-plan. Dat betekent echter niet dat iedereen dan weer gewoon aan het werk kan gaan. Het uitgangspunt van business continuity, dat aandeelhouderswaarde veilig gesteld moet worden, kreeg te weinig aandacht. (Zie ook &#8216;Business Continuity steeds meer aandachtspunt voor controllers&#8217;.) </p>
<h2>3. Valkuilen in de aanpak</h2>
<p>Dat de ICT-manager zich verantwoordelijk voelt voor business continuity, is van hem uit gezien niet vreemd. Binnen ITIL is calamiteitenplanning een tactisch proces met als proceseigenaar de ICT-afdeling. Calamiteitenplanning is echter ook onderdeel van veel andere bedrijfsprocessen. En dat bleef onderbelicht. In feite verzaakten hier dus de andere managers.<br />
Nog erger is het, wanneer business continuity wordt benaderd vanuit de normen voor informatiebeveiliging, dat traditioneel ook vaak bij de ICT-manager is belegd. Eén van de elf aspectgebieden van de ISO-norm is &#8216;bedrijfscontinuïteitsbeheer&#8217;. De doelstelling van de ISO-norm die hierop betrekking heeft is als volgt: &#8216;Onderbreken van bedrijfsactiviteiten tegengaan en kritische bedrijfsprocessen beschermen tegen de gevolgen van omvangrijke storingen in informatiesystemen of rampen en tijdig herstel bewerkstelligen&#8217;. Maar het is natuurlijk ondenkbaar dat bedrijfscontinuïteit slechts een deelaspect is van het aandachtsgebied van een ICT-manager of een IBF. De beschikbaarheid van informatie is immers slechts één van de vele voorwaarden voor de continuïteit van de bedrijfsprocessen. </p>
<h2>4. ICT geen issue door virtualisatie en webbased software</h2>
<p>Natuurlijk zijn er gegevensverwerkende industrieën, zoals bijvoorbeeld banken, verzekeraars en overheden, die vrijwel niet anders doen dan informatie verwerken. Maar zelfs voor deze bedrijven geldt steeds meer, dat de nadruk niet ligt op de gegevensverwerking, maar op de dienstverlening aan de klant en het managen van zijn financiering en risico&#8217;s. Natuurlijk is een foutloze gegevensverwerking wel een voorwaarde voor het leveren van service aan de klant. Maar een bank zal niet  aan zijn einde komen, enkel door fouten in deze gegevensverwerking.<br />
De geautomatiseerde gegevensverwerking wordt steeds minder een probleem. En veelal is het zeker geen probleem meer van de bedrijven zelf. Steeds meer software is standaard en grote teams van ontwikkelaars houden zich bezig met het foutloos en veilig maken en houden van de software. Zelf deze investeringen doen in maatwerk is voor bedrijven vrijwel niet op te brengen. Verder is steeds meer software webbased. Dat betekent, dat waar er vroeger een fysieke afhankelijkheid bestond van de plaats waar de software draaide (mainframe applicaties of client/server software), er tegenwoordig slechts een internetverbinding en een browser nodig zijn om overal met de software te kunnen werken, onafhankelijk van de plek waar de server en de clients zich bevinden. Waar dus vroeger een fysieke en dedicated uitwijk nodig was voor een serverruimte, volstaat met webbased applicaties nu een willekeurig datacenter.<br />
Uitwijk is soms zelfs volstrekt overbodig, nu bovendien via servervirtualisatie het bestaan van twee productiecentra steeds meer gemeengoed wordt. Men is daardoor in staat storingen in de ICT binnen enkele minuten op te vangen en vrijwel alle gebruikers te bedienen uit het nog werkende productiecentrum. Het enige wat daarvoor hoeft te gebeuren, is dat de helft van de gebruikers opnieuw inlogt, omdat zij toevallig ingelogd waren op het productiecentrum dat onderuit is gegaan. Verder zullen er waarschijnlijk een aantal niet-kritische applicaties uit de lucht gehaald worden, omdat ieder productiecentrum maar 75% van de totale capaciteit kan leveren. De beschikbaarheid van de ICT als single point of failure is dan ook nauwelijks nog een issue voor de bedrijfscontinuïteit. Dat is het zelfs niet als het pand waarin het productiecentrum gehuisvest is, tot de grond toe afbrandt. </p>
<h2>5. De scope van het calamiteitenplan</h2>
<p>Bij het opzetten van een calamiteitenplan wordt het steeds belangrijker in ketens te denken. Ons richtend op de ICT, zien we dat het productiecentrum geen kritische factor meer vormt, wanneer dit via virtualisatie volledig dubbel is uitgevoerd. Als het om bedrijfscontinuïteit gaat, moeten we echter verder kijken. Vooral de gevolgen die de uitval van een productiecentrum heeft voor de dienstverlening is van belang. Vaak gaat het dan niet over de informatievoorziening, maar over de communicatie en dus over vragen als:</p>
<ul>
<li>Zijn er nog aanvullende werkplekken beschikbaar voor medewerkers?</li>
<li>Is er een locatie waar de frontoffice gevestigd kan worden?</li>
<li>Kunnen de medewerkers op die nieuwe werkplek verbinding maken met internet?</li>
<li>Is er ook uitwijk voor applicaties die niet zijn gevirtualiseerd?</li>
<li>Kan de telefooncentrale doorgeschakeld worden, als er fysiek geen toegang tot de centrale is?</li>
<li>Kan het call centre beschikken over zijn applicaties, als er uitgeweken wordt naar een extern call centre? (Zie ook &#8216;Uitwijk telefooncentrale haalt communicatieplan bij calamiteit vaak onderuit&#8217;.)</li>
</ul>
<p>Deze vragen maken ook de afhankelijkheid duidelijk van de service door toeleveranciers. In alle gevallen zijn stroomvoorziening, een internetverbinding en beschikbaar personeel noodzakelijk. In hoeverre zijn hiervoor garanties te krijgen van de toeleveranciers?<br />
Het elektriciteitsbedrijf biedt geen garantie. Dat is enkele jaren geleden wel duidelijk geworden door het ongeval met een helikopter in de Bommelerwaard. Er moet dus een afweging gemaakt worden of voor de elektriciteit  een voorziening getroffen moet worden. Een ISP is vaak afhankelijk van één toeleverancier van het landelijke netwerk. Als deze uitvalt, ligt de ISP plat. Ook hier moet een afweging gemaakt worden, of dit risico wordt genomen of dat er een voorziening wordt getroffen.<br />
Kortom, het gaat er bij een calamiteitenplan niet om, alle rampen te kunnen hanteren. De vraag is vooral of bepaalde risico&#8217;s al dan niet afgedekt moeten worden en dan niet alleen via interne procedures, maar ook via de inkoopvoorwaarden en de verplichtingen die worden aangegaan. (Zie ook &#8216;Keuzes en aanpak voor uw Business Continuity Plan BCP of calamiteitenplan&#8217;.) </p>
<h2>6. Keuzes maken op basis van bedrijfsrisico&#8217;s</h2>
<p>Het betekent dat er doordachte keuzes gemaakt moeten worden over risico&#8217;s, en niet alleen over statistisch kwantificeerbare risico&#8217;s, maar ook over risico&#8217;s als:</p>
<ul>
<li>imagoschade;</li>
<li>uitval van toeleveranciers en ketenpartners;</li>
<li>regelgeving en toezichthouders;</li>
<li>uitbreken van een oliecrisis (één van de grootste risico&#8217;s in de risicoanalyse van 2008 uitgevoerd door de overheid).</li>
</ul>
<p>Dit zijn stuk voor stuk gebeurtenissen in de omgeving met een hogere waarschijnlijkheid dat zij zich zullen voordoen, dan de klassiekers als brand, overstroming enzovoort. Het zijn ook stuk voor stuk zaken die niet zijn te voorkomen. Het is dus noodzakelijk adequaaat op deze calamiteiten te kunnen reageren.<br />
Uiteraard betreft dit zaken, die veel verder gaan dan de scope van de ICT-manager of de informatiebeveiliger. Het is aan het management keuzes te maken over de risico&#8217;s die het wil accepteren. (Zie ook &#8216;Inventarisatie diensten, dreigingen en processen in uw Business Continuity Plan BCP&#8217;.)</p>
<h6>Herziene versie: 3 mei 2011</h6>
]]></content:encoded>
			<wfw:commentRss>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/ict-steeds-minder-het-probleem-bij-een-calamiteitenplan/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Is bedrijfscontinuïteit een zaak van de ICT-manager</title>
		<link>http://zbc.nu/ict/is-bedrijfscontinuiteit-een-zaak-van-de-ict-manager/</link>
		<comments>http://zbc.nu/ict/is-bedrijfscontinuiteit-een-zaak-van-de-ict-manager/#comments</comments>
		<pubDate>Fri, 09 Mar 2007 07:45:28 +0000</pubDate>
		<dc:creator>Wiebe Zijlstra</dc:creator>
				<category><![CDATA[Calamiteitenplan - BCP]]></category>
		<category><![CDATA[Calamiteitenplan, Business Continuity Management]]></category>
		<category><![CDATA[Functioneel beheer - BiSL]]></category>
		<category><![CDATA[ICT]]></category>
		<category><![CDATA[ICT en Facility Management]]></category>
		<category><![CDATA[ICT, Security en calamiteitenplan]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[BCP]]></category>
		<category><![CDATA[bedrijfscontinuiteit]]></category>
		<category><![CDATA[beleggen]]></category>
		<category><![CDATA[business continuity plan]]></category>
		<category><![CDATA[calamiteiten]]></category>
		<category><![CDATA[calamiteitenplan]]></category>
		<category><![CDATA[continuity]]></category>
		<category><![CDATA[draaiboek]]></category>
		<category><![CDATA[eisen]]></category>
		<category><![CDATA[ICT-manager]]></category>
		<category><![CDATA[imago]]></category>
		<category><![CDATA[plan]]></category>
		<category><![CDATA[praktijk]]></category>
		<category><![CDATA[risico]]></category>
		<category><![CDATA[schade]]></category>
		<category><![CDATA[uitwijkplan]]></category>

		<guid isPermaLink="false">http://zbc.nu/?p=686</guid>
		<description><![CDATA[Business Continuity Management wordt nog steeds vaak bij de ICT-manager neergelegd, terwijl de risico's juist meer en meer verschuiven naar toezichthouders, aansprakelijkheid, overheidsmaatregelen en imagoschade. Wordt het niet eens tijd om BCM en het BCP goed te adresseren?]]></description>
			<content:encoded><![CDATA[<p><strong>Inhoudsopgave</strong></p>
<ol>
<li>Bedrijfscontinuïteit is meer dan ICT</li>
<li>Business Continuity Management</li>
<li>Verschuivingen</li>
<li>Spanningsvelden</li>
<li>Eisen Business Continuity Management</li>
<li>Bedrijfscontinuïteit in de praktijk </li>
</ol>
<h2>1. Bedrijfscontinuïteit is meer dan ICT</h2>
<p>Bedrijfscontinuïteit wordt  vaak gekoppeld aan ICT en daarmee aan de ICT-dienstverlening. Er is echter nog vrijwel nooit een bedrijf kapot gegaan door moeilijkheden met de ICT. (Zie ook &#8216;Business continuity steeds meer aandachtspunt voor controllers&#8217;.) Vaak  overschatten ICT&#8217;ers het belang van de ICT.<br />
Het issue bedrijfscontinuïteit komt voor in de methodiek ITIL voor ICT-beheer. Veel ICT-managers voelen zich daarom geroepen om dit issue op te pakken. Meestal doet ook niemand anders dit en daarom is het op zich een goede zaak. Het moet echter wel duidelijk zijn dat de ICT in veel bedrijven niet het verschil uitmaakt tussen het al dan niet overleven van calamiteiten. (Zie ook &#8216;Business continuity in de industrie, groothandel en distributie&#8217;.) Soms richt de ICT-afdeling meer schade aan met haar bestrijding van calamiteiten dan dat ze goed doet. Niet de ICT-manager moet de belangrijkste stem hebben bij een calamiteit, maar de directie.<br />
Laten we eerst een paar zaken op een rijtje zetten. Een calamiteit is niets meer en niets minder dan een incident dat de bedrijfsvoering dreigt te belemmeren. Als het gaat om een uitslaande brand, om een vliegtuig dat op uw pand landt, om een terroristische aanslag of om een overstroming, dan is het evident dat er sprake is van een calamiteit. Als het echter gaat om gevelplaten die van uw pand vallen of van dat van uw buurman, dan moet u maar afwachten waar de politie de bekende rood-witte linten spant en of er nog iemand uw pand in of uit kan, dus wat de gevolgen zullen zijn voor uw bedrijfsvoering. En bij bijvoorbeeld een stroomstoring of een bommelding zult u zelf moeten bepalen of er alleen maar sprake is van een incident of dat u misschien bent getroffen door een calamiteit.<br />
In veel gevallen treedt bij een calamiteit eerst het BHV-plan in werking. Als dan iedereen na een kwartier op veilige afstand staat, wordt doorgaans overgegaan op het Business Continuity Plan (BCP). Die overgang kan soms heel groot zijn. Het BHV-plan en de BHV&#8217;ers zijn namelijk mensgericht en het BCP en de ICT&#8217;ers veel meer zaakgericht. Daarbij komt dat een BCP binnen de ICT vaak wordt gezien als onderdeel van de informatiebeveiliging. Dat is uiteraard geen goede afbakening. Een goed crisisteam dat zijn verantwoordelijkheden neemt  is cruciaal. (Zie ook &#8216;Inpassing business continuity BCP in BHV-plan, ICT en algemeen beleid veiligheid&#8217;.) </p>
<h2>2. Business Continuity Management</h2>
<p>We zien dat verantwoordelijkheden verschuiven. Het businessmanagement gaat zich steeds actiever bezighouden met de continuïteit van de IT-systemen  en de IT-manager wordt opdrachtnemer voor het uitvoeren van bedrijfscontinuïteitsmaatregelen. De werkzaamheden van de IT-managers komen hiermee onder druk te staan. Daarnaast stelt het businessmanagement ook steeds hogere eisen aan de continuïteit van de operationele bedrijfsprocessen. Hierbij gaat het aan de ene kant om het nemen van preventieve maatregelen om een calamiteit te voorkomen en aan de andere kant om correctieve maatregelen, inclusief het bijbehorende crisismanagement, om het effect van een calamiteit te minimaliseren.<br />
Met name bij grotere organisaties pakt het businessmanagement deze verantwoordelijkheid op en gaat het de operationele continuïteit directer aansturen. Als de ICT-manager hierbij opdrachtnemer is, is dat een risico. Hij is al verantwoordelijk voor de ICT-service. Deze nieuwe verantwoordelijkheid krijgt hij er dan maar even bij, terwijl hij doorgaans maar een deel van de puzzel kan overzien, zoals duidelijk wordt uit onderstaande beschrijving van wat nu eigenlijk de hoofdzaken zijn van Business Continuity Management :</p>
<ul>
<li>In veel gevallen zijn preventieve maatregelen weggegooid geld, omdat de meeste calamiteiten zelden of nooit zullen voorkomen.  (Zie ook &#8216;Business continuity los je niet op met preventie&#8217;.)</li>
<li>Er moet een draaiboek zijn voor het geval er een calamiteit optreedt. Er moet tevens een implementatieplan zijn, dat er voor zorgt dat dat draaiboek daadwerkelijk gaat werken. (Zie ook &#8216;Keuzes en aanpak voor uw Business Continuity Plan BCP of calamiteitenplan&#8217;.)</li>
<li>Voor veel bedrijven is imagoschade een groot risico. Imagoschade echter is veel meer de verantwoordelijkheid van de afdeling communicatie dan van de ICT-afdeling. (Zie ook &#8216;Imagoschade bij calamiteiten veroorzaak je meestal zelf&#8217;.)</li>
<li>Het risico dat een bedrijfspand voor klanten en medewerkers wordt afgesloten, neemt  door de wildgroei van preventieve acties door de politie en allerlei toezichthouders en door terreurdreigingen steeds meer toe. De oplossing voor dit probleem is echter niet het specialisme van de ICT-manager. (Zie ook &#8216;Casestudies Business Continuity Plan&#8217;.)</li>
</ul>
<p>Traditioneel ligt de focus van Business Continuity Management op: hoe herstellen we onze informatiesystemen op systeemniveau? Tegenwoordig ligt dit minder voor de hand  en komen de drivers niet alleen meer vanuit het ICT-domein, maar uit meerdere hoeken tegelijk. Interne en externe risico&#8217;s nemen toe. De klant wil steeds meer en beter en organisaties die hun eigen operationele processen beter willen waarborgen vragen om hogere continuïteitsgaranties van hun leveranciers. En ook neemt de concurrentie toe. De media hebben steeds meer aandacht voor calamiteiten en crises en daardoor treedt imagoschade steeds eerder op. Wet- en regelgeving dwingen tot het verkleinen van de operationele risico&#8217;s en toezichthouders worden kritischer en eisen een bedrijfscontinuïteitsplan.  Bovendien nemen de dreigingen op zich toe en daarmee de continuïteitsrisico&#8217;s. Denk bijvoorbeeld aan terreurdreigingen en toenemende digitale aanvallen op systemen en netwerken. Al deze factoren met elkaar leiden tot een toenemend bewustzijn van de noodzaak van BCM in het algemeen en van crisismanagement in het bijzonder. Ook het businessmanagement zelf is zich bewust geworden van het feit dat het leveren van kwaliteit gepaard moet gaan met continuïteitsgaranties.<br />
Om overzicht te houden, zullen we in de volgende hoofdstukken de verschillende aspecten van een BCP bekijken vanuit de optiek van de ICT-manager. We gaan daarbij tevens in op de risico&#8217;s die een organisatie loopt, wanneer de ICT-manager de eerst verantwoordelijke is en bij de inrichting van het continuïteitsmanagement niet wordt voldaan aan de eisen van het businessmanagement . </p>
<h2>3. Verschuivingen</h2>
<p>In het verleden heeft de ICT-manager zich vaak alleen op technisch niveau beziggehouden met continuïteit, waarbij we kunnen denken aan back-up, recovery en systeemuitwijk. Nu gaat zoals gezegd het businessmanagement een actieve rol spelen in de aansturing van de operationele continuïteit, inclusief de ICT-componenten daarin. De focus verschuift daarmee van systeemuitwijk en -herstel naar procesuitwijk en -herstel. Uiteraard heeft dit ook verschuivingen tot gevolg van verantwoordelijkheden en rollen tussen de businessmanager en de ICT-manager. Bij een calamiteit is voortaan de verantwoordelijke businessmanager leidend in de afhandeling. De uitwijk- en herstelwerkzaamheden bij een calamiteit worden vanuit de business gestuurd. Voorbeelden hiervan zijn dat het herstel van het afhandelen van orders, de afhandeling van klantvragen of het herstel van lijnafdelingen de hoofdprioriteit krijgt. Herstel van ICT-middelen staat in dienst van het herstel van de bedrijfprocessen.<br />
ICT-uitwijk is dus niet meer leidend maar volgend. De IT-manager wordt opdrachtnemer voor het uitvoeren van bedrijfscontinuïteitsmaatregelen. Met de leidende rol van de businessmanagers wordt de IT-manager ook opdrachtnemer om te zorgen voor de noodzakelijke redundante ICT-voorzieningen en ICT-noodvoorzieningen, inclusief het beheer hiervan. Het behoeft geen betoog dat hiermee spanningsvelden voor de IT-manager worden gecreëerd. Hieronder noemen we een zestal. </p>
<h2>4. Spanningsvelden</h2>
<p>Ten eerste zijn de ICT-systemen slechts een onderdeel van de totale uitwijk, naast bijvoorbeeld mensen, gebouwen, overige apparatuur, werkplekken, organisatie en informatie. De mate waarin de operationele processen afhankelijk zijn van de ICT-systemen versus de afhankelijkheid van de andere bedrijfsmiddelen is bepalend voor de rol van de IT-manager in het uitwijk- en herstelproces. Deze rol zal er in veel gevallen toe leiden dat het door de IT-manager opgezette uitwijk- en herstelplan (ICT Services Continuity) op een aantal punten strijdig is met het vanuit de business opgestelde uitwijk- en herstelplan (Business Continuity Plan). Een voorbeeld is dat binnen ICT Services Continuity datacommunicatie als verantwoordelijkheidsgebied is uitgewerkt en in het Business Continuity Plan het call-center (spraakcommunicatie). Er ontbreekt een geïntegreerde calamiteitenaanpak.<br />
In de tweede plaats moeten architecturen en onderliggende systemen en infrastructuren resilient (veerkrachtig) worden ingericht. Dat wil zeggen: zowel bestand tegen relevante bedreigingen (robuust) als flexibel om aan de verscheidenheid aan continuïteitseisen vanuit de business te kunnen voldoen. Businessmanagers kunnen voor hun systemen bijvoorbeeld kiezen tussen drie verschillende infrastructuren, die ieder een eigen niveau van continuïteit bieden, maar natuurlijk ook een eigen prijskaartje hebben. De IT-manager heeft uiteraard de kennis om alternatieven te vergelijken, maar als daarvan geen gebruik wordt gemaakt door de businessmanagers is een tweede spanningsveld geschapen. Daarnaast krijgt de IT-manager van verschillende businessmanagers verschillende continuïteitseisen aangeleverd. De IT-manager wordt dan geconfronteerd met het probleem: voor welke continuïteitseisen ga ik standaardvoorzieningen treffen en waar liggen de specials.<br />
Ten derde moet de IT-manager middelen beschikbaar hebben om te sturen op crisismanagement en het zo veel mogelijk beperken van schade. Concreet betekent dit dat er bijvoorbeeld redundante netwerkvoorzieningen (preventie) en no-breakinstallaties moeten worden ingericht, maar ook extra werkplekken beschikbaar moeten zijn op verschillende gescheiden locaties. Hierdoor wordt een situatie van &#8216;overal werken&#8217; geschapen, waarmee de basis aanwezig is om bij uitvallen van reguliere werkplekken de werkzaamheden elders te kunnen continueren. Een spanningsveld ontstaat, als men vanuit de operationele processen denkt, dat hiermee tegelijk uitwijkwerkplekken beschikbaar zijn, inclusief toegang tot de centrale systemen. Deze toegang is echter niet per definitie verzekerd en vereist ook continuïteitsmaatregelen voor de informatiesystemen met specifieke eisen aan gebruikersprofielen en autorisaties.<br />
In de vierde plaats is het ook de taak van de IT-manager om afspraken met systeem- en telecommunicatieleveranciers te maken voor het geval er bijvoorbeeld verbindingen uitvallen en er herrouteringsafspraken moeten worden gemaakt. Een spanningsveld is aanwezig als de IT-manager dit te veel op eigen houtje doet zonder afstemming met de proceseigenaar.<br />
Beide vorige punten betekenen dat de bij ICT berustende continuïteitsmaatregelen op gespannen voet kunnen komen te staan met ICT-activiteiten gericht op het verbeteren van de functionaliteit van de ICT-dienstverlening.<br />
In de vijfde plaats zullen sommige businessmanagers aan de IT-manager de opdracht geven tot kwaliteitsverbeteringen van systemen (meer of betere functionaliteit), terwijl andere businessmanagers de betrouwbaarheid of continuïteit van de systemen willen laten verbeteren. Als niet van hogerhand prioriteiten worden gesteld komt de IT-manager tussen twee vuren te zitten, omdat zijn middelen beperkt zijn. De relevante vraag is dus: kies je voor extra continuïteit of voor extra functionaliteit en op basis waarvan bepaal je de juiste keuze?<br />
De integrale aanpak die grotere organisaties nu kiezen voor het beheersen van hun operationele continuïteit leidt tot de noodzaak van een scherpere afbakening van de verantwoordelijkheidsgebieden van alle toeleveranciers van de operationele bedrijfsprocessen: interne ICT, externe ICT, facilitair bedrijf, externe toeleveranciers.<br />
Het zesde en laatste spanningsveld voor de IT-manager is dat hij zorg moet dragen voor de juiste afspraken met alle partijen. De eisen vanuit de bedrijfsprocessen moeten worden opgelijnd met de mogelijkheden die interne en externe leveranciers van diensten bieden. Alle afspraken moeten vooraf zijn gemaakt zodat in geval van een calamiteit geen tijd wordt verspild met wachten op elkaar of tijdrovende overleggen. </p>
<h2>5. Eisen Business Continuity Management</h2>
<p>Deze zes spanningsvelden kunnen ervoor zorgen, dat de inrichting van het continuïteitsmanagement binnen een organisatie niet aan de eisen voldoet die het businessmanagement hieraan stelt. De IT-manager zal dus maatregelen moeten treffen om ervoor te zorgen dat hij kan (blijven) voldoen aan de continuïteitseisen die aan zijn systemen en processen worden gesteld.<br />
In de eerste plaats zal de IT-manager zich meer de opdrachtnemersrol moeten toemeten dan de opdrachtgeversrol. Hij zal businessmanagers moeten begeleiden in het op zich nemen van de opdrachtgeversrol door hen bijvoorbeeld te begeleiden bij het vaststellen van de continuïteitsnormen van de bedrijfprocessen en het definiëren van de hieruit volgende continuïteitstrategieën. In dergelijke strategieën definieert het businessmanagement de maximale tijd dat informatiesystemen niet beschikbaar mogen zijn, het maximaal toelaatbare gegevensverlies en de volgorde waarin informatiesystemen moeten worden hersteld na het optreden van een calamiteit. Dit soort normen kan alleen door de eigenaren van de bedrijfsprocessen, oftewel het businessmanagement, worden gesteld, omdat zij het beste de impact kunnen inschatten van het niet beschikbaar zijn van informatiesystemen. Wanneer continuïteitstrategieën eenmaal zijn vastgesteld zal de IT-manager er samen met het businessmanagement voor moeten zorgen dat de strategieën worden vertaald in concrete afspraken die in SLA&#8217;s worden vastgelegd. Afspraken over beschikbaarheid worden standaard in SLA&#8217;s vastgelegd. Deze afspraken moeten worden uitgebreid met afspraken met betrekking tot continuïteit.<br />
Om de implementatie van alle verschillende continuïteitseisen beheersbaar te houden zal de IT-manager een aantal standaardcontinuïteitsoplossingen bieden, waaruit businessmanagers kunnen kiezen en die in de SLA&#8217;s kunnen worden opgenomen. De diverse oplossingen kunnen worden ontwikkeld in de vorm van verschillende flexibele architecturen die bestand zijn tegen verstoringen (robuust) en die zowel procedureel als technisch meerdere niveaus van continuïteit kunnen bieden. Op procedureel niveau kan worden gedacht aan verschillende niveaus van reactietijden, verschillende niveaus van menselijke of geautomatiseerde monitoring en alarmering en verschillen in eisen aan piketdiensten. Op technisch niveau kunnen infrastructuren robuust worden gemaakt door bijvoorbeeld het inbouwen van redundantie in netwerkverbindingen of in servers. Ook kan gebruik worden gemaakt van technologieën zoals geautomatiseerde fall-back, clustering en server based computing. <br />
Om de continuïteit van de bedrijfsprocessen te waarborgen zal de IT-manager moeten leren integraal te denken. Hij moet de betekenis en het belang van de ICT-dienstverlening voor de operationele bedrijfprocessen herkennen en businessmanagers adviseren bij het inschatten van hun continuïteitsrisico&#8217;s en over de continuïteitsmaatregelen die zij moeten treffen. Wanneer hij vervolgens ook de juiste architecturen invoert en de afspraken met de business goed beheert is de organisatie een heel eind op weg naar continuïteit. Het is evident dat hiermee de taak van de ICT-manager aanzienlijk complexer is geworden en dat zijn werkzaamheden behoorlijk onder druk zijn komen te staan.</p>
<h2>6. Bedrijfscontinuïteit in de praktijk</h2>
<p>In de praktijk komt Business Continuity Management (BCM) samengevat neer op het volgende:</p>
<ul>
<li>De doelstelling van Business Continuity Management (BCM) is, het voorkomen van ernstige onderbrekingen in de bedrijfsvoering en het beschermen van kritieke bedrijfsprocessen tegen gevolgen van omvangrijke (ver)storingen of calamiteiten.</li>
<li>Het definiëren van de continuïteitsnormen voor bedrijfsprocessen en informatiesystemen is de verantwoordelijkheid van het businessmanagement.</li>
<li>Het ligt niet langer voor de hand Business Continuity te beleggen bij de ICT-afdeling en de ICT-manager de eerst verantwoordelijke te maken. Van oudsher werd dit wel gedaan. Gezien echter enerzijds de betrouwbaarheid van de ICT-infrastructuur en anderzijds de opkomende andere risico&#8217;s, waarvan met name imagoschade voor veel bedrijven een steeds groter risico wordt, is dit niet meer een voor de hand liggende keuze. De enige reden is vaak nog, dat de ICT-afdeling voldoende ervaring heeft met projectmatig werken, zodat zij gemakkelijk in staat is zo&#8217;n project, dat uitbesteed wordt, aan te sturen namens de organisatie.</li>
<li>Als u als organisatie goed om wilt gaan met bedrijfscontinuïteit, zult u projectmatig moeten komen tot een Business Continuity Plan (BCP), maar zal het beheer hiervan in de organisatie belegd moeten worden, opdat het draaiboek ook daadwerkelijk werkt in geval van een calamiteit.</li>
<li>Uit onderzoek blijkt dat drie op de vier organisaties die aandacht besteden aan BCM, hiervoor een directe aanleiding (incident of druk van een toezichthouder) nodig hebben gehad. Slechts één op de drie ondernemingen heeft een beheerproces ingericht voor haar continuïteitsplannen. En de meeste ondernemingen ten slotte voeren geen enkele controle uit op de afspraken die zij maken met derde partijen op het gebied van continuïteit.</li>
<li>Cruciaal is de rol van het crisisteam; in veel gevallen geldt, dat een calamiteit pas een calamiteit is als het crisisteam hier het stempel van calamiteit op zet. Zo geldt voor de meeste echecs in de afgelopen jaren met een voor een bedrijf dodelijke afloop, dat de belangrijkste oorzaak was, dat niet tijdig werd onderkend dat een incident een calamiteit was. Zorgt u er daarom vooral ook voor dat, onafhankelijk van waar leden van het crisisteam zich bevinden, crisisberaad altijd kan plaatsvinden. (Zie ook &#8216;Het virtuele crisiscentrum voor uw crisisteam&#8217;.)</li>
<li>Wees bedacht op calamiteiten die u niet hebt voorzien, maar die uw bedrijf wel te gronde helpen richten. Het gaat daarbij meestal niet om directe schade, maar om indirecte schade. (Zie ook &#8216;Business Continuity Plan: uw dekking voor onverzekerde schade.)</li>
</ul>
<h6>Herziene versie: 18 maart 2011<br />
 </h6>
<h6>Delen van dit artikel zijn overgenomen uit: Steven Debets en Dick Leegwater,&#8217;Continuïteitseisen veranderen verantwoordelijkheid IT-manager&#8217;. In: Automatisering Gids. 31 maart 2006.</h6>
]]></content:encoded>
			<wfw:commentRss>http://zbc.nu/ict/is-bedrijfscontinuiteit-een-zaak-van-de-ict-manager/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Business continuity in de industrie, groothandel en distributie</title>
		<link>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/business-continuity-in-de-industrie-groothandel-en-distributie/</link>
		<comments>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/business-continuity-in-de-industrie-groothandel-en-distributie/#comments</comments>
		<pubDate>Sat, 01 Jul 2006 10:59:04 +0000</pubDate>
		<dc:creator>Wiebe Zijlstra</dc:creator>
				<category><![CDATA[Bedrijfscontinuïteit of Business Continuity]]></category>
		<category><![CDATA[Business Continuïty - Bedrijfsrisico]]></category>
		<category><![CDATA[Calamiteitenplan, Business Continuity Management]]></category>
		<category><![CDATA[Risk management en Compliance]]></category>
		<category><![CDATA[afnemers]]></category>
		<category><![CDATA[BCP]]></category>
		<category><![CDATA[bedrijfscontinuiteit]]></category>
		<category><![CDATA[bedrijfsrisico]]></category>
		<category><![CDATA[business continuity management]]></category>
		<category><![CDATA[business continuity plan]]></category>
		<category><![CDATA[calamiteit]]></category>
		<category><![CDATA[calamiteitenplan]]></category>
		<category><![CDATA[crisiscentrum]]></category>
		<category><![CDATA[crisisteam]]></category>
		<category><![CDATA[distributie]]></category>
		<category><![CDATA[draaiboek]]></category>
		<category><![CDATA[groothandel]]></category>
		<category><![CDATA[industrie]]></category>
		<category><![CDATA[keten]]></category>
		<category><![CDATA[ketenpartners]]></category>
		<category><![CDATA[levering]]></category>
		<category><![CDATA[logistiek]]></category>
		<category><![CDATA[productie]]></category>
		<category><![CDATA[resilience]]></category>
		<category><![CDATA[supply chain]]></category>
		<category><![CDATA[toeleveranciers]]></category>

		<guid isPermaLink="false">http://zbc.nu/?p=546</guid>
		<description><![CDATA[Bij ketenleveranciers zoals de industrie, de roothandel en de distributie is bedrijfscontinuïteit door resilience natuurlijk van belang, maar het Business Continuity Plan kent in vergelijking met andere branches veel meer speling. Daarom is een pragmatische en realistische aanpak gewenst. In dit artikel meer over aandachtspunten, tips en trucs voor uw resilience plan.]]></description>
			<content:encoded><![CDATA[<p><strong>Inhoudsopgave</strong></p>
<ol>
<li>Wat is eigenlijk het probleem?</li>
<li>Best practices in geval van een calamiteit</li>
<li>Belangrijke rol crisisteam en draaiboek</li>
<li>Business continuity: nut of noodzaak? </li>
</ol>
<h2>1. Wat is eigenlijk het probleem?</h2>
<p>Bedrijfscontinuïteit of business continuity is een hot item. Overheid, toezichthouders en grote afnemers eisen van organisaties, dat ze hun bedrijfscontinuïteit garanderen. In elk vakblad dat u openslaat, staat wel iets te lezen over de gevaren voor uw bedrijfscontinuïteit of business continuity. Allerlei mogelijke incidenten worden opgevoerd en zodanig aangezet, dat u het als een wonder mag beschouwen, dat uw bedrijf nog bestaat.  Gelukkig nemen de meeste bedrijven dergelijke informatie met een korreltje zout. Bedrijfscontinuïteit moet ook niet benaderd worden vanuit de bedreigingen die mogelijke incidenten opleveren, maar vanuit de daadwerkelijke risico&#8217;s. Dit geldt zeker voor bedrijven die onderdeel uitmaken van een keten. (Zie ook &#8216;Business Continuity of plan bedrijfscontinuïteit: Doe effe normaal&#8217;.) Bottomline komt het erop neer, dat er sprake is van een calamiteit, als er iets gebeurt waardoor de eindklant (de consument) niet meer bediend kan worden en die eindklant daarom besluit elders producten of diensten af te nemen.</p>
<h3>1.1 Omloopsnelheid bij de consument</h3>
<p>Een belangrijk aspect is de omloopsnelheid bij de klant. Als er sprake is van een incident, waardoor de klant tijdelijk niet bediend kan worden, dan komt de klant voor zijn volgende aankoop waarschijnlijk wel weer terug. Als het gaat om iets wat voortduurt gedurende een periode waarin die klant voor het bewuste product herhalingsaankopen doet, dan zal het marktaandeel in razend tempo zakken en raakt het bedrijf mogelijk out of business. Herstel is dan alleen mogelijk via grootschalige advertising. Maar daardoor wordt in veel gevallen de marge zo onder druk gezet, dat ook dit de bedrijfscontinuïteit weer in gevaar brengt. Om vast te stellen of er sprake is van een calamiteit is dus allereerst de omloopsnelheid van een product bij de eindklant van belang.</p>
<h3>1.2 Voorraad in de keten</h3>
<p>Een tweede aspect dat van belang is, is uiteraard de voorraad die in de keten voor handen is. Hierbij gaat het niet alleen om de voorraad die beschikbaar is bij de distributeur, maar ook om die bij de retail. De huidige JIT-uitgangspunten hebben de speling verminderd, maar vaak zijn ze wel ingegeven door economische principes.</p>
<p><em>Een voorbeeld:<br />
</em>Laatst werden we gevraagd om voor een leverancier van kinderzitjes een analyse te maken. Het bleek dat er gemiddeld voor zes weken voorraad in de keten zit, terwijl herbouw van de productielijn ongeveer één maand kost. In zo&#8217;n geval is te volstaan met een calamiteitenplan van 2 A4-tjes en een bijlage met een kooplijst, waarin staat vermeld wat er ingekocht moet worden om de productielijn weer op te bouwen.</p>
<h3>1.3 De 80-20 regel</h3>
<p>Verder moet er natuurlijk altijd rekening worden gehouden met de bekende 80-20 regel. Tachtig procent van de omzet wordt doorgaans bepaald door twintig procent van de afnemers met twintig procent van de producten.</p>
<h3>1.4 Handmatige procedures</h3>
<p>Als er sprake is van een storing in de automatisering is het, om de keten toch te bedienen, mogelijk volledig over te stappen op handmatige procedures. Dat brengt echter wel het risico met zich mee, dat er achteraf zoveel handmatige invoer gedaan moet worden, dat dit, om dit naast de dagelijkse workload te doen, al snel weken kost. In die periode zal de leverbetrouwbaarheid sterk minder zijn. De verstoring die wordt aangericht bij overschakeling op handmatige procedures kost dan ook vaak een veelvoud van één of twee dagen niet leveren. Dit geldt natuurlijk primair voor groothandels en distributiecentra. </p>
<h2>2. Best practices in geval van een calamiteit</h2>
<p>Hieronder reiken we u een aantal best practices aan, in geval van een calamiteit. Bij een storing in de ICT geldt in de industrie, de groothandel en de distributie, in tegenstelling tot wat geldt voor financials en overheden, dat de eerste stap moet zijn: &#8216;Niets doen&#8217;!</p>
<h3>2.1 Calamiteit in productielocatie</h3>
<p>Als er sprake is van een megacalamiteit in een productielocatie, dan wordt de vraag interessant of de productiecapaciteit in Nederland überhaupt hersteld moet worden. Ook outsourcing is dan een mogelijkheid. Vaak is zo&#8217;n megacalamiteit meer een kans dan een bedreiging, omdat een productielocatie meestal goed verzekerd is. Het vinden van een alternatief levert zelfs vaak een positief saldo op. Het is wel verstandig om voorzieningen te treffen voor de uitval van nutsvoorzieningen.</p>
<h3>2.2 Standaard levering op basis historie</h3>
<p>Voor producten met een hoge omloopsnelheid is het handig  om voor het productiecentrum contractueel een &#8216;frozen period&#8217; vast te leggen. Dat wil zeggen dat zolang de calamiteit duurt, dat geleverd wordt wat over de afgelopen periode het gemiddelde was. Bijsturing door de afnemer is dan weliswaar niet mogelijk, maar het betekent wel dat de afnemer de garantie heeft, dat hij bevoorraad wordt.</p>
<h3>2.3 Calamiteit in distributiecentrum of bij transporteur</h3>
<p>In geval van een calamiteit bij het distributiecentrum of de transporteur, is er in Nederland altijd wel snel een alternatief te vinden. In de contracten met toeleveranciers moet opgenomen zijn, dat in geval van calamiteiten spoedorders gehonoreerd worden als de voorraad aangetast wordt.</p>
<h3>2.4 Calamiteit administratief centrum</h3>
<p>Betreft een calamiteit alleen het administratieve centrum, dan kunnen binnen 24 uur gemakkelijk containers met werkplekken geleverd worden, zodat de tijdkritische processen met een lichte vertraging doorgang kunnen vinden.</p>
<h3>2.5 Calamiteit toeleveranciers</h3>
<p>Het is natuurlijk ook mogelijk dat er een calamiteit optreedt bij een belangrijke toeleverancier. Het oplossen hiervan is uiteraard de verantwoordelijkheid van die toeleverancier. Maar niettemin hebt u een probleem, als u niet meer kunt leveren aan uw afnemers. Zorg daarom voor een kooplijst, zodat, als u zelf niet meer geleverd krijgt, u minstens één alternatief hebt.</p>
<h3>2.6 Calamiteit bij afnemers</h3>
<p>Calamiteiten bij afnemers kunnen variëren van glas in babyvoeding, ondeugdelijke bijsluiters tot mogelijk ontploffende batterijen in laptops. Uiteraard moet er in voorkomende gevallen een actie gestart worden om het probleem te communiceren (in een positieve vorm, waarin de zorg voor de klant centraal staat) en moeten de producten die het betreft teruggehaald worden voor reparatie of vervanging. </p>
<h2>3. Belangrijke rol crisisteam en draaiboek</h2>
<p>De kans dat megacalamiteiten plaatsvinden is beperkt. Investeren in preventieve maatregelen is dan ook meestal weggegooid geld. (Zie ook &#8216;Business continuity los je niet op met preventie&#8217;.) Als zich echter toch een dergelijke calamiteit voordoet, dan is het van belang dat er snel beslissingen genomen kunnen worden (crisisteam) en dat de betrokkenen weten hoe te handelen (draaiboek).</p>
<h3>3.1 Crisisteam en crisiscentrum</h3>
<p>Bij beperkte investeringen in business continuity is de rol van het crisisteam essentieel. De meeste calamiteiten zijn niet tijdkritisch en het is vaak beter om eerst te kijken of het probleem niet (eventueel alternatief) opgelost kan worden, dan om direct in actie te komen. Timing bij calamiteiten is van groot belang. Daarom is de eerste stelregel, dat er geen calamiteit is, tot het crisisteam beslist dat er wel sprake is van een calamiteit. Dat kan zelfs betekenen, dat ontruiming conform het BHV-plan wordt uitgevoerd (bijvoorbeeld vanwege een bommelding), zonder dat het draaiboek uit het BCP gebruikt wordt. Bij het BHV-plan staan de mensen centraal; bij business continuity (BCP) staat de continuïteit van de business centraal.<br />
Als er bepaald is, dat er sprake is van een calamiteit, dan is vervolgens het crisisteam verantwoordelijk voor de timing van de maatregelen. Als er kans is op een oplossing binnen de geaccepteerde tijd, wordt meestal afgewacht, uiteraard tot er geen weg terug meer is. Dat is wanneer de eindklant in de keten last gaat krijgen van de calamiteit en het risico bestaat, dat er marktaandeel verloren gaat.<br />
Omdat er in een keten meestal sprake is van meerdere locaties en afhankelijk van het type calamiteit ook van steeds andere specialisten die een sleutelrol vervullen, is het verstandig eveneens een virtueel crisiscentrum in te richten. De leden van dit team kunnen dan mee praten als dit gewenst is, maar tegelijkertijd op hun plek leiding geven om problemen op te lossen. (Zie ook &#8216;Het virtuele crisiscentrum voor uw crisisteam&#8217;.)</p>
<h3>3.2 Draaiboek business continuity</h3>
<p>Cruciaal in het crisismanagement is het Draaiboek Business Continuity. Zelfs voor leden van een crisisteam is een calamiteit geen dagelijkse kost. Daarom staat in het draaiboek beschreven welke stappen er gezet moeten worden, welke beslissingen er genomen moeten worden hoe de communicatie moet verlopen.<br />
Daartoe worden scenario&#8217;s beschreven met elk hun specifieke aandachtspunten om te voorkomen dat het crisisteam gaat zwemmen. (Zie ook &#8216;Keuzes en aanpak voor uw Business Continuity Plan BCP of calamiteitenplan&#8217;.) Zeker voor productiebedrijven is het van belang, dat de afdeling communicatie onderdeel uitmaakt van het crisisteam en dat er sjablonen klaar liggen voor de communicatie naar de pers, de afnemers en andere stakeholders. (Zie ook &#8216;Imagoschade bij calamiteiten veroorzaak je meestal zelf&#8217;.) Als tijdens een crisis nog verzonnen moet worden hoe dit moet gebeuren, is de kans op onzorgvuldige communicatie en dus imagoschade zeer groot.<br />
Naast het draaiboek is er natuurlijk een implementatieplan, waarin de acties worden uitgezet, die ervoor moeten zorgen, dat het draaiboek kan werken. </p>
<h2>4. Business continuity: nut of noodzaak?</h2>
<p>In productiebedrijven, distributiecentra en groothandels is business continuity een soep die niet zo heet gegeten moet worden als hij vaak opgediend wordt. Door de voorraden in de keten is er de tijd om eerst de goede dingen te doen en dan pas de dingen goed te doen. Maar het is struisvogelpolitiek te denken, dat calamiteiten uw bedrijf wel nooit zullen treffen. Dan speelt u Russische roulette.<br />
In dit artikel hebben we getracht een beeld te schetsen hoe u business continuity als ketenpartner pragmatisch, oplossingsgericht en kostenbewust kunt invullen. Natuurlijk heeft ook uw bedrijf te maken met specifieke risico&#8217;s. We zijn daar bewust niet uitgebreid op ingegaan, om de hoofdlijn niet te verstoren. U moet daarvoor in uw eigen bedrijf zijn en met mensen praten. De basis voor een business continuity plan kan een standaardplan zijn, de invulling is altijd specifiek. (Zie ook ‘Uw business continuity plan is een oplossing en geen managementsysteem’.)<br />
De primaire boodschap is: kijk eerst naar de risico&#8217;s en niet naar de 784 richtlijnen en maatregelen voor het opstellen van een business continuity plan of een calamiteitenplan, die vaak ook nog gericht zijn op het voorkomen van calamiteiten. (Zie ook ‘Maak business continuity toch niet zo complex’.) Gezien de bestaande wetgeving is dat laatste voor uw bedrijf waarschijnlijk allang geregeld.<br />
De meeste draaiboeken zijn dermate generiek, dat alleen de poppetjes en locaties nog ingevuld moeten worden en natuurlijk bijlagen als de kooplijst en de bereikbaarheidslijst. Verder is de beschrijving van scenario&#8217;s van belang om het crisisteam snel op het goede spoor te zetten en om ondoordachte acties te voorkomen.<br />
Het implementatieplan is per definitie maatwerk. Want  juist dat zorgt ervoor dat het generieke draaiboek ook in uw organisatie zal werken.</p>
<h6>Herziene versie: 4 februari 2011</h6>
]]></content:encoded>
			<wfw:commentRss>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/business-continuity-in-de-industrie-groothandel-en-distributie/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Inpassing Business Continuity BCP in BHV-plan, ICT en algemeen beleid veiligheid</title>
		<link>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/inpassing-business-continuity-bcp-in-bhv-plan-ict-en-algemeen-beleid-veiligheid/</link>
		<comments>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/inpassing-business-continuity-bcp-in-bhv-plan-ict-en-algemeen-beleid-veiligheid/#comments</comments>
		<pubDate>Sat, 10 Dec 2005 14:48:03 +0000</pubDate>
		<dc:creator>Wiebe Zijlstra</dc:creator>
				<category><![CDATA[Bedrijfscontinuïteit of Business Continuity]]></category>
		<category><![CDATA[BHV-plan, Arbo, RI&E en beveiliging]]></category>
		<category><![CDATA[Calamiteitenplan - BCP]]></category>
		<category><![CDATA[Calamiteitenplan, Business Continuity Management]]></category>
		<category><![CDATA[Inrichting bedrijfscontinuïteit]]></category>
		<category><![CDATA[audit]]></category>
		<category><![CDATA[BCP]]></category>
		<category><![CDATA[bedrijfscontinuiteit]]></category>
		<category><![CDATA[bedrijfshulpverlening]]></category>
		<category><![CDATA[beleid]]></category>
		<category><![CDATA[BHV-plan]]></category>
		<category><![CDATA[business continuity plan]]></category>
		<category><![CDATA[calamiteitenplan]]></category>
		<category><![CDATA[ICT]]></category>
		<category><![CDATA[integraal management]]></category>
		<category><![CDATA[integratie]]></category>
		<category><![CDATA[operationele risks]]></category>
		<category><![CDATA[plan]]></category>
		<category><![CDATA[risico]]></category>
		<category><![CDATA[risk management]]></category>
		<category><![CDATA[tabaksblat]]></category>
		<category><![CDATA[veiligheid]]></category>

		<guid isPermaLink="false">http://zbc.nu/?p=654</guid>
		<description><![CDATA[Business Continuity heeft vaak veel overlap met reeds bestaande plannen op het gebied van BHV, ICT en beveiliging. In dit artikel meer over de inbedding van een BCP en de raakvlakken met de andere plannen.]]></description>
			<content:encoded><![CDATA[<p><strong>Inhoudsopgave</strong></p>
<ol>
<li>Inpassen business continuity</li>
<li>Integrale risico analyse cruciaal voor bedrijfscontinuïteit</li>
<li>Relatie tussen BCP en BHV-plan</li>
<li>Relatie business continuity met ICT-beleid en beveiligingsbeleid</li>
<li>Relatie BCP en operationele audit en risk management</li>
<li>Business Continuity Plan: bewust risico&#8217;s nemen </li>
</ol>
<h2>1. Inpassen business continuity</h2>
<p>Voor steeds meer organisaties wordt een business continuity plan verplicht gesteld en veel organisaties worstelen met de inpassing van dit plan. Veelal beschikken zij al over:</p>
<ul>
<li>een bedrijfshulpverleningsplan (BHV-plan), dat beschrijft wat te doen bij een calamiteit;</li>
<li>beveiligingsplannen met ook maatregelen in geval van calamiteiten;</li>
<li>een fysiek beveiligingplan met richtlijnen hoe om te gaan met calamiteiten;</li>
<li>programma&#8217;s voor operational riskmanagement, waar ook maatregelen voor bedrijfscontinuïteit bij calamiteiten staan beschreven;</li>
<li>een calamiteitenplan of uitwijkplan voor de ICT.</li>
</ul>
<p>De vraag is dus vaak af of er dan nog een business continuity plan nodig is; het risico is groot dat er meer van hetzelfde gecreëerd wordt en dat uiteindelijk iedereen door de bomen het bos niet meer ziet.<br />
Natuurlijk is het mogelijk het BCP tussen de andere plannen, maatregelen en richtlijnen in te frommelen, maar daarmee ontstaat meestal een gedrocht dat in de praktijk niet werkt. Het is daarom goed business continuity niet te benaderen vanuit de kant van de beveiliging maar vanuit de kant van de business. Het is dus niet zo dat  het BHV-plan of het beveiligingsplan een calamiteitenparagraaf moet bevatten, maar er moet een business continuity plan zijn , dat het uitgangspunt vormt voor continuering van de business. Wel moeten natuurlijk de bestaande plannen, als zij goed functioneren, zoveel mogelijk intact blijven. Slechts als uit de risico-inventarisatie blijkt dat er ernstige tekortkomingen zijn, dan kan overgegaan worden tot aanpassing van de betrokken plannen. </p>
<h2>2. Integrale risico analyse cruciaal voor bedrijfscontinuïteit</h2>
<p>Risico analyses worden binnen veel bedrijven vanuit een aspectgebied gedaan. Zo wordt er gekeken naar:</p>
<ul>
<li>het financiële risico;</li>
<li>de informatiebeveiliging;</li>
<li>de bedrijfshulpverlening;</li>
<li>enzovoort.</li>
</ul>
<p>Vaak wordt dit gedaan door specialisten op dat gebied. Dat betekent dat slechts de risico&#8217;s van het aspectgebied in kaart worden gebracht en niet de risico&#8217;s voor de totale bedrijfscontinuïteit. Ervaringen uit het recente verleden hebben dat bewezen:</p>
<ul>
<li>Enron, hoewel het volledig voldeed aan de eisen van de Amerikaanse toezichthouder; oorzaak: fraude van het management;</li>
<li>het Productschap Tuinbouw dat te maken kreeg met een blokkade door boze tuinders, die het opgelegde heffingsbedrag te hoog vonden; oorzaak: slechte communicatie;</li>
<li>diverse verzelfstandigde overheidsinstanties die door de politiek mogelijk worden opgeheven; oorzaak: politieke spelletjes;</li>
<li>publieke omroepen die een groot deel van hun budget kwijtraakten (en daardoor ook een deel van hun reclame-inkomsten) door ingrijpen van de overheid; oorzaak: geldgebrek bij de overheid;</li>
<li>oudejaarsconference van Youp van het Hek, die leidde tot de ondergang van Buckler;</li>
<li>Twin Towers in New York;</li>
<li>afvallende gevelplaten bij een Achmea-gebouw, waardoor de omgeving van het gebouw werd afgezet;</li>
<li>Nick Leeson die Barings naar de afgrond bracht.</li>
</ul>
<p>Natuurlijk is niet alles te voorzien. Door echter te kijken naar het soort calamiteiten welke een organisatie in de problemen kan brengen, kunnen de continuïteitsrisico&#8217;s in kaart gebracht worden. Meestal gaat het om bedreigingen van buitenaf. Maar bedreigingen kunnen ook van binnenuit komen. <br />
Helaas werken de meeste bedrijven met een sterk verouderd calamiteitenplan of business continuity plan (BCP). Vaak is het plan geïnitieerd door een crisis als Y2K of Twin Towers, waarna vervolgens de aandacht voor business continuity weer is verslapt. En dat terwijl vanwege de doorgevoerde efficiencyslagen de meeste bedrijven op dit punt kwetsbaar zijn geworden. (Zie ook ‘Business Continuity Plan: uw dekking voor onverzekerde schade’.)</p>
<h2>3. Relatie tussen BCP en BHV-plan</h2>
<p>Een BHV-plan is meer tijdloos dan een business continuity plan en veel organisaties hebben dan ook een BHV-plan dat wel up-to-date is. Daar zijn ze bovendien wettelijk toe verplicht. Ook zijn er in de meeste bedrijven BHV-medewerkers aangewezen, die het BHV-plan bewaken en die ook frequent bijgeschoold worden. Voor business continuity is dit helaas zelden het geval.<br />
De kern van het BHV-plan is meestal: hoe zorgen wij er bij een calamiteit voor dat de aanwezigen in het gebouw zo snel mogelijk in veiligheid worden gebracht en hoe krijgen eventuele slachtoffers zo snel mogelijk hulpverlening. Zodra dit geregeld is, kan vanuit de optiek van de bedrijfshulpverlening het sein &#8216;brand meester&#8217; gegeven worden. In veel BHV-plannen wordt er vervolgens vanuit gegaan dat iedereen weer naar zijn werkplek kan terugkeren en in sommige organisaties wordt in de BHV-plannen zelfs expliciet aangegeven dat iedereen op de externe verzamelplaats moet blijven, tot hij kan terugkeren naar zijn werkplek. Dat de calamiteit dusdanige vormen kan aannemen, dat er voor de bedrijfsvoering een uitwijklocatie nodig is, is meestal niet beschreven. De scope is het sein &#8216;brand meester&#8217; en dat wordt meestal in een kwartier tot een half uur bereikt. Daarna moet echter de focus verplaatst worden naar de voortzetting van de bedrijfsvoering. Hiervoor moet een draaiboek klaarliggen en er moet een plan zijn, dat garandeert, dat het draaiboek ook gaat werken. (Zie ook &#8216;Keuzes en aanpak voor uw Business Continuity Plan BCP of calamiteitenplan&#8217;.)<br />
Formeel wordt er meestal wel een crisisteam benoemd. Voordat echter het crisisteam überhaupt bijeen kan komen, is de ontruiming meestal al geregeld, want de veiligheid van personen staat in het BHV-plan centraal. Dat is uiteraard terecht, maar daarmee ben je er niet. Als iedereen in veiligheid is, moet ook de bedrijfsvoering in veiligheid gesteld worden. Mogelijk kan dit vanuit de bestaande locatie, maar mogelijk ook  is deze bestaande locatie niet meer bruikbaar vanwege brand, waterschade of een afzetting van de omgeving door de autoriteiten vanwege een bommelding in of rond het pand of vanwege risico&#8217;s die voorbijgangers kunnen treffen door technische onvolkomenheden aan eigen of andere gebouwen. </p>
<h2>4. Relatie business continuity met ICT-beleid en beveiligingsbeleid</h2>
<p>De relatie die business continuity heeft met het ICT-beleid en het beveiligingsbeleid is meestal evident. Onderdeel van de beleidsplannen zijn veelal preventieve maatregelen waarmee het risico van een incident wordt verminderd of waarmee geregeld wordt dat incidenten niet kunnen escaleren tot een calamiteit. Veelal zijn deze plannen echter opgesteld vanuit een algemene norm of baseline en meestal niet vanuit een integrale risicoanalyse. Ze zijn echter meestal goed geaccepteerd en ingeburgerd en vaak werken ze. Het zou dan ook onverstandig zijn alles weer overhoop te halen. In dat geval verzandt men al snel in een oerwoud van regelgeving en is het vrijwel zeker dat de naleving matig zal zijn. Wel zullen deze aspectgebieden uiteraard meegenomen moeten worden in de integrale risicoanalyse. Omdat er gewerkt is vanuit een norm, is de kans groot dat grote bedrijfsspecifieke risico&#8217;s over het hoofd gezien zijn of dat er maatregelen zijn genomen die in de praktijk overbodig zijn. </p>
<h2>5. Relatie BCP en operationele audit en risk management</h2>
<p>Tijdens een operationele audit zouden in theorie alle aspecten van business continuity aan de orde moeten komen. Helaas worden tijdens dit operationele risk management meestal slechts de financiële risico&#8217;s onder de loep genomen om de positie van eigenaren en aandeelhouders veilig te stellen. De code-Tabaksblat is hiervan een goed voorbeeld. (Zie ook &#8216;Corporate governance Tabaksblat en Sox: hemel of hel?&#8217;.) Zeker als de audit overgelaten wordt aan een externe accountant, dan gaat het vaak meer over de cijfertjes dan over de continuïteit van de bedrijfsvoering. Natuurlijk zijn de cijfertjes belangrijk, maar in geval van een calamiteit is de bedrijfscontinuïteit bepalend voor het feit dat je of wel of niet je geld kwijt bent. De gemiddelde MKB&#8217;er heeft bovendien wel belangrijkere dingen te doen dan te voldoen aan allerlei regeltjes. Met ondernemen verdient hij zijn geld en ondernemen is tenslotte risico&#8217;s nemen.  Natuurlijk getuigt het van slecht ondernemerschap als de bedrijfscontinuïteit op het spel wordt gezet. Maar zeker voor het MKB geldt dat de ondernemer dan zelf de grootste schade lijdt. Daarom kiest de MKB&#8217;er graag voor voor een pragmatische aanpak. (Zie ook ‘Plan bedrijfscontinuïteit MKB: wat, waarom en hoe’.) </p>
<h2>6. Business Continuity Plan: Bewust risico&#8217;s nemen</h2>
<p>Zoals eerder gezegd is ondernemen ook risico&#8217;s nemen. Dit geldt voor profit en non-profit organisaties. De kern is echter dat u bewust risico&#8217;s neemt. En daarbij is het van belang om duidelijk onderscheid te maken tussen risico&#8217;s die er toe doen en risico&#8217;s die in feite niet van belang zijn. Als u beide soorten risico&#8217;s op een grote hoop gooit door een baseline of een checklist te volgen, dan weet u zeker dat u hiervoor geen draagvlak krijgt. (Zie ook &#8216;Maak business continuity toch niet zo complex&#8217;.) U moet uw specifieke bedrijfsrisico&#8217;s bepalen en dan gaat het om die risico&#8217;s die impact hebben op uw bedrijfscontinuïteit. Vaak zijn dit zaken waarmee u niet op voorhand rekening houdt. De kern is dat u het geheel  overziet. En dat kanvanuit de business continuity, en dan niet vanuit een horror-scenario maar vanuit een analyse van uw tijdkritische bedrijfsprocessen.</p>
<h6>Herziene versie: 11 maart 2010</h6>
]]></content:encoded>
			<wfw:commentRss>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/inpassing-business-continuity-bcp-in-bhv-plan-ict-en-algemeen-beleid-veiligheid/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Het ABC van het BCP</title>
		<link>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/het-abc-van-het-bcp/</link>
		<comments>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/het-abc-van-het-bcp/#comments</comments>
		<pubDate>Tue, 16 Dec 2003 13:33:03 +0000</pubDate>
		<dc:creator>Wiebe Zijlstra</dc:creator>
				<category><![CDATA[Calamiteitenplan, Business Continuity Management]]></category>
		<category><![CDATA[ICT, Security en calamiteitenplan]]></category>
		<category><![CDATA[BCP]]></category>
		<category><![CDATA[business continuity plan]]></category>
		<category><![CDATA[calamiteitenplan]]></category>
		<category><![CDATA[resilience]]></category>

		<guid isPermaLink="false">http://zbc.nu/?p=615</guid>
		<description><![CDATA[Wanneer u voor het eerst te maken krijgt met Business Continuity Planning kan het daarmee gepaard gaande jargon behoorlijk verwarrend zijn. In dit artikel staan de belangrijkste termen uitgelegd.]]></description>
			<content:encoded><![CDATA[<h2>Inleiding</h2>
<p>Wanneer u voor het eerst te maken krijgt met Business Continuity Planning kan het daarmee gepaard gaande jargon behoorlijk verwarrend zijn, al was het alleen vanwege de vele engelse woorden die worden gebruikt. Om wat meer duidelijkheid in de BCP-materie te verschaffen volgt hieronder een toelichting op veel gebruikte termen.</p>
<table border="1" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td width="204" valign="top"><strong>Term</strong></td>
<td width="468" valign="top"><strong>Toelichting</strong></td>
</tr>
<tr>
<td width="204" valign="top">Acceptable Down Time</td>
<td width="468" valign="top">Engelse benaming voor Toegestane Uitvaltijd</td>
</tr>
<tr>
<td width="204" valign="top">Business Continuity Planning</td>
<td width="468" valign="top">Het voorbereiden van een organisatie op mogelijke verstoringen in de reguliere bedrijfsprocessen. Doel: enerzijds het minimaliseren van risico&#8217;s die kunnen leiden tot discontinuïteit, anderzijds indien een discontinuïteit zich voordoet de impact ervan zo laag mogelijk houden door het in werking stellen van alternatieve werkprocedures. Continuity Planning wordt ook wel aangeduid met Contingency Planning.</td>
</tr>
<tr>
<td width="204" valign="top">Business Continuity Plan (BCP)</td>
<td width="468" valign="top">In het Business Continuity Plan wordt vastgelegd welke maatregelen worden genomen wanneer zich een zeker incident voordoet. De maatregelen hebben betrekking op het kunnen voortzetten van de kritische bedrijfsactiviteiten maar ook de eventueel te nemen maatregelen om niet-kritische processen tijdelijk stil te leggen. Ook wordt in het BCP de crisisorganisatie beschreven: wie maken er deel van uit, hoe liggen de taken en bevoegdheden, etc.Sleutelfiguren bij het opstellen en uitvoeren van het BCP zijn de Business en de Operations Managers en diens medewerkers. Buiten het aandachtsgebied van het BCP zijn de herstelwerkzaamheden, die nodig zijn om naar de normale situatie terug te keren. Dit is het onderwerp van het Disaster Recovery Plan. Anders gezegd: bij incidenten die het werken vanaf de eigen locatie/werkplek onmogelijk maken treedt het DR Plan in werking, bij overige incidenten het BCP</td>
</tr>
<tr>
<td width="204" valign="top">Calamiteit</td>
<td width="468" valign="top">Een zeer ernstig incident met het karakter van een ramp zoals bijvoorbeeld brand, ontploffing, overstroming, etc.</td>
</tr>
<tr>
<td width="204" valign="top">Calamiteitenplan</td>
<td width="468" valign="top">Het calamiteitenplan bevat het geheel van maatregelen hoe op te treden in geval van zeer ernstige incidenten als brand, ontploffing en overstromingen.Onderwerpen van een calamiteitenplan zijn bedrijfshulpverlening, evacuatie, etc. Nota bene: het calamiteitenplan is dus niet gelijk aan het continuïteitsplan.</td>
</tr>
<tr>
<td width="204" valign="top">Close Down Scenario</td>
<td width="468" valign="top">Dit is de wijze waarop de niet-kritische bedrijfsprocessen worden stilgelegd. Zeker bij incidenten met een sterke negatieve impact is het vaak alle hens aan dek voor zowel de business unit als de afdeling die verantwoordelijk is voor het verhelpen van het incident. Daarom kan het nodig zijn dat de niet-kritische processen worden stilgelegd zodat alle aandacht naar de kritische processen kan gaan.Ook wanneer het incident dermate ernstig is dat moet worden uitgeweken naar een disaster recovery site, zullen alleen de kritische activiteiten daar worden ondergebracht. De overige activiteiten worden dan tijdelijk gestaakt.</td>
</tr>
</tbody>
</table>
<p> </p>
<table border="1" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td width="204" valign="top"><strong>Term</strong></td>
<td width="468" valign="top"><strong>Toelichting</strong></td>
</tr>
<tr>
<td width="204" valign="top">Crawl Back Scenario</td>
<td width="468" valign="top">Hier wordt bedoeld de wijze waarop kan worden teruggekeerd naar de oude situatie ( back to business as usual). Wanneer het incident is opgelost, is het onverstandig om zomaar terug te schakelen, omdat dit onbedoeld tot fouten in het proces kan leiden. Denk bijvoorbeeld aan het uitvallen van een systeem waarmee transacties worden verwerkt. Het systeem zal als gevolg van het incident de verwerking van de transacties niet tijdig kunnen uitvoeren en dus wordt besloten &#8211; conform het fall back scenario &#8211; de transacties handmatig te verwerken. Echter, wanneer het systeem weer &#8216;up&#8217; is moet gecontroleerd worden of er wellicht nog transacties in een &#8216;queue&#8217;  staan om te voorkomen dat de transacties voor een tweede keer worden verwerkt.</td>
</tr>
<tr>
<td width="204" valign="top">Disaster Recovery Site</td>
<td width="468" valign="top">De engelse benaming voor Uitwijklocatie</td>
</tr>
<tr>
<td width="204" valign="top">Disaster Recovery Plan (DR)</td>
<td width="468" valign="top">Het Disaster Recovery Plan bevat het geheel aan maatregelen om in geval van zeer ernstige incidenten (delen van) de bedrijfsactiviteiten onder te brengen op een alternatieve locatie. Ook de maatregelen die worden genomen om de schade/verstoring op de eigen locatie te verhelpen maken deel uit van het DR Plan.Sleutelfiguren bij het opstellen hiervan zijn veelal de IT- en Facility managers en diens medewerkers.</td>
</tr>
<tr>
<td width="204" valign="top">Fall Back Scenario</td>
<td width="468" valign="top">Letterlijk vertaald betekent dit &#8220;terugvalscenario&#8221;. Duidelijker is het om te spreken van &#8220;alternatieve werkwijze&#8221;, want dat is wat hiermee feitelijk wordt bedoeld: hoe ga je te werk als de reguliere werkwijze als gevolg van een incident niet meer tot het gewenste resultaat leidt?  Het antwoord op deze vraag is de kern van business continuity planning.Work Arounds is een ander veel gebruikte term en heeft dezelfde betekenis als Fall Back</td>
</tr>
<tr>
<td width="204" valign="top">Incident</td>
<td width="468" valign="top">In de context van BCP wordt van een incident gesproken bij ieder voorval dat leidt tot een (gedeeltelijke) verstoring of onderbreking van de bedrijfsprocessen. Het maakt daarbij niet uit wat de aard of de oorzaak van het incident is: van stroomuitval tot OV staking, van een kapotte telefooncentrale tot wateroverlast, van brand tot vandalisme, en van computerstoring tot bommelding, het behoort allemaal tot het aandachtsgebied van BCP.</td>
</tr>
<tr>
<td width="204" valign="top">Risicomitigatie</td>
<td width="468" valign="top">Dit is het verminderen van de risico&#8217;s dat een incident zich voordoet, of als een incident zich toch voordoet, de impact hiervan op de bedrijfsprocessen zo gering mogelijk is.Zo beschouwd is het opstellen van een BCP óók een risicomitigerende maatregel. Andere voorbeelden zijn het beschikbaar hebben van een noodstroomvoorziening, het cross trainen van medewerkers opdat ze elkaars werk kunnen overnemen, een goed toegangsbeleid opdat ongenodigde bezoekers geen schade kunnen aanrichten, het beschikbaar hebben van een back-up server, het regelmatig maken van back-ups opdat gegevens toch raadpleegbaar zijn wanneer het netwerk down is, etc.</td>
</tr>
<tr>
<td width="204" valign="top">Toegestane uitvaltijd</td>
<td width="468" valign="top">De toegestane tijd dat een proces uit de lucht mag zijn. Het uitvallen van een bedrijfsproces hoeft immers niet direct tot grote problemen te leiden. De tijdspanne waarbinnen een incident weliswaar hinderlijk maar niet problematisch is, wordt de Toegestane Uitvaltijd (ook wel acceptable downtime) genoemd. Wanneer wordt ingeschat dat de verwachte uitvaltijd de toegestane uitvaltijd overschrijdt, kan dit het startsein zijn om over te schakelen op BCP modus.</td>
</tr>
</tbody>
</table>
<p> </p>
<table border="1" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td width="204" valign="top"><strong>Term</strong></td>
<td width="468" valign="top"><strong>Toelichting</strong></td>
</tr>
<tr>
<td width="204" valign="top">Uitvaltijd</td>
<td width="468" valign="top">Dit is de tijd die verstrijkt tussen het plaatshebben van een incident en het oplossen ervan. Anders gezegd is het de tijdsduur waarbinnen een zeker productiemiddel niet beschikbaar is waardoor het bedrijfsproces gediscontinueerd is.</td>
</tr>
<tr>
<td width="204" valign="top">Uitwijk</td>
<td width="468" valign="top">Dit wil zeggen het overbrengen van de activiteiten naar een andere locatie. Dit is meestal in geval dat de schade aan (delen van) de gebruikelijk locatie zo ernstig is dat deze niet binnen de acceptabele uitvaltijd verholpen kan worden. Het engelse equivalent is Disaster Recovery</td>
</tr>
<tr>
<td width="204" valign="top">Uitwijklocatie</td>
<td width="468" valign="top">Een alternatieve locatie waar de operaties tijdelijk worden ondergebracht tot dat de verstoring/schade aan de gebruikelijke locatie is verholpen. Het engelse equivalent is Disaster Recovery Site.</td>
</tr>
</tbody>
</table>
]]></content:encoded>
			<wfw:commentRss>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/het-abc-van-het-bcp/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Calamiteitenplan</title>
		<link>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/calamiteitenplan/</link>
		<comments>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/calamiteitenplan/#comments</comments>
		<pubDate>Mon, 08 Oct 2001 12:51:34 +0000</pubDate>
		<dc:creator>Wiebe Zijlstra</dc:creator>
				<category><![CDATA[Calamiteitenplan, Business Continuity Management]]></category>
		<category><![CDATA[ICT, Security en calamiteitenplan]]></category>

		<guid isPermaLink="false">http://zbc.nu/?p=607</guid>
		<description><![CDATA[Het waarom, het wat en de aanpak van calamiteitenplanning, mogelijke oplossingsalternatieven met voor- en nadelen (business continuity planning).]]></description>
			<content:encoded><![CDATA[<p><em>Het waarom, het wat, de aanpak, mogelijke oplossingsalternatieven met voor- en nadelen, afhankelijk van de situatie van calamiteitenplanning (Business Continuity Planning)</em></p>
<p>De presentatie bestaat uit de volgende sheets:</p>
<ol>
<li> Calamiteitenplanning   </li>
<li> Inhoud presentatie   </li>
<li> Doel calamiteitenplan   </li>
<li> Relatie calamiteitenplan met risicoanalyse   </li>
<li> Afbakening calamiteitenplan   </li>
<li> Kritische succesfactoren   </li>
<li> Aanpak om te komen tot een calamiteitenplan   </li>
<li> Stappenplan voor fase 2 en 3   </li>
<li> Vaststellen strategie</li>
<li> Bepalen strategie</li>
<li> Voor- en nadelen benaderingen</li>
<li> Bepaling behoeften</li>
<li> Inbreuk continuïteit</li>
<li> Potentiële bedreigingen</li>
<li> Mogelijke objecten voor uitwijk</li>
<li> Uitwijkalternatieven</li>
<li> Geen uitwijk</li>
<li> Empty shell</li>
<li> Bilaterale uitwijk</li>
<li> Gezamenlijk systeemgebruik bij bilaterale uitwijk</li>
<li> Mobiele uitwijk</li>
<li> Tweede computercentrum</li>
<li> Schema dubbele verbinding productie/uitwijkcentru</li>
<li> Indeling interne uitwijkcentra</li>
<li> Tweede computersysteem</li>
<li> Schema verbinding productie-uitwijksysteem</li>
<li> Schema verbinding productie-uitwijksysteem waarbij</li>
<li> Schema fault tolerant systeem</li>
<li> Continuïteitsgarantie per optie bij calamiteiten </li>
<li> Voor &#8211; en nadelen verschillende uitwijk-opties</li>
<li> Keuzeproces opties bij calamiteiten</li>
<li> Keuzeproces opties bij storingen</li>
<li> Inhoud Calamiteitenhandboek</li>
<li> Inhoud Calamiteitenhandboek bijlagen</li>
<li> Escalatie procedure</li>
<li> Next Steps</li>
</ol>
<p>U kunt de volledige Powerpointpresentatie bekijken door deze te downloaden via de button hieronder. Eventueel kunt tevens een Powerpoint Viewer downloaden.</p>
]]></content:encoded>
			<wfw:commentRss>http://zbc.nu/ict/calamiteitenplan-business-continuity-management/calamiteitenplan/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
<!-- This Quick Cache file was built for (  zbc.nu/ict/calamiteitenplan-business-continuity-management/feed/ ) in 0.64342 seconds, on May 19th, 2013 at 11:17 am UTC. -->
<!-- This Quick Cache file will automatically expire ( and be re-built automatically ) on May 19th, 2013 at 12:17 pm UTC -->