Skip to main content

Blog Archives

Older posts
Newer posts

De meldplicht datalekken

Een securitybedrijf wordt gehackt en beveiligde identiteitstokens lekken naar buiten, de gegevens van klanten van een fastfoodketen liggen voor het oprapen en de tapgegevens van het KLPD zijn ook al niet veilig … Datalekken komen helaas vaak voor. En ook steeds vaker komt dit publiekelijk naar buiten. Nog even en dan is het zelfs wettelijk verplicht dergelijke datalekken openbaar te maken; op 29 april 2011 maakten Teeven (ministerie V&J) en Donner (ministerie BZK) bekend dat een brede meldplicht voor alle aanbieders van informatiediensten opgenomen zal worden in de Wet bescherming persoonsgegevens. Op korte termijn zal een zogenaamde ‘smalle meldplicht’ gaan gelden voor alleen telecommunicatiebedrijven en internet-serviceproviders op grond van een wijziging van de Telecommunicatiewet.

Inleiding

Datalekken zijn helaas bijna aan de orde van de dag. En het overkomt de besten onder ons. Niet lang geleden kampte zelfs een securitybedrijf met het uitlekken van informatie over beveiligde IDtokens. Soms had een lek makkelijk voorkomen kunnen worden, een andere keer is er sprake van domme pech of een geavanceerde aanval van buitenaf. Hoe het ook zij, het uitlekken van persoonlijke data van werknemers, klanten of anderszins is buitengewoon vervelend en ook problematisch in verband met allerlei juridische garanties die de ‘eigenaars’ van deze data verstrekt worden. 2011 wordt het jaar dat de (smalle) meldplicht datalekken in werking zal treden. Als alles volgens planning verloopt, moet dit voorjaar al de implementatie daarvan in de Telecommunicatiewet (Tw) gereed zijn. Vooralsnog geldt de meldplicht alleen voor telecommunicatiebedrijven (telco’s) en Internet Service Providers (ISP’s). Een bredere meldplicht die zal gelden voor alle aanbieders van informatiediensten (denk bijvoorbeeld aan banken, de Belastingdienst en verzekeringsmaatschappijen), is op 29 april aangekondigd door Teeven en Donner en zal een plaats krijgen in de Wet bescherming persoonsgegevens. Voorstanders van de meldplicht, zoals onder meer burgerrechtenorganisatie Bits of Freedom en de Consumentenbond, staan hier uitermate positief tegenover. Dit vanuit de wens tot meer transparantie en openheid daar waar het misgaat met de persoonlijke gegevens van burgers en klanten. Het bedrijfsleven weifelt. De gevolgen van een dergelijke meldplicht kunnen groot zijn, reputatieschade en praktische uitvoering lijken de meest voor de hand liggende factoren bij terughoudendheid. Dit artikel gaat nader in op de meldplicht datalekken: wat is het en hoe zal die gaan werken? En hoe zit dat met een meldplicht voor alle organisaties die te maken (kunnen) krijgen met datalekken? Daarnaast worden enkele voor- en tegenargumenten op een rijtje gezet.

Data Loss Barometer

Hoewel uit onderzoek van KPMG blijkt dat er sprake is van een daling in de hoeveelheid incidenten waarbij persoonlijke data gelekt worden, is er desalniettemin nog steeds sprake van een enorme hoeveelheid gevallen waarbij data ‘verloren’ gaan ([KPMG10]). Meer dan 15 miljoen mensen worden hierdoor geraakt. Vooral binnen de financiële sector is het verlies van data ongemeen groot, zeker indien dit afgewogen wordt tegen de andere in de Data Loss Barometer onderzochte sectoren. Van de in totaal verloren ‘records’ is 33% afkomstig uit die financiële sector, maar ook retail (31%) en de informatiediensten (22%) scoren hoog. In 21% van de gevallen wordt het lek veroorzaakt door zogenaamde ‘malicious insiders’ (kwaadwillenden van binnen in de organisatie), 15% wordt veroorzaakt door de diefstal van pc’s en 12% vindt zijn oorsprong in hacks.

C-2011-2-Marbus-01C-2011-2-Marbus-02

Figuur 1. Dataverlies naar sector (boven) en naar oorzaak (bron: [KPMG10]).

De wordingsgeschiedenis van de meldplicht

Al sinds 2005 wordt er in politiek Nederland gestreden voor het invoeren van een wettelijke regeling rondom het verplicht melden van datalekken. Een motie van SP en PvdA uit 2005 met betrekking tot het invoeren van een meldplicht haalde het toentertijd niet. Toenmalig minister Donner oordeelde dat persoonsgegevens al afdoende beschermd werden onder het regime van de Wet bescherming persoonsgegevens. Eventuele door de markt zelf op te stellen regels zouden verdere bescherming moeten afdwingen. Indertijd is wel toegezegd dat onderzoek zou worden gedaan naar de vraag of een dergelijke meldplicht effect sorteert. Dit door te kijken naar de resultaten van de landen waar al wel een wettelijke plicht vastgelegd is. Het duurt daarna echter weer enkele jaren voor de discussie over de meldplicht opnieuw oplaait. In 2009 komen het Europees Parlement en de Raad met een aantal wijzigingen voor de zogenaamde ePrivacy-richtlijn, waarin onder meer een meldplicht is opgenomen voor de aanbieders van openbare telecommunicatiediensten (lees: telco’s en internet-serviceproviders). Daarmee komt een smalle meldplicht wettelijk vast te liggen, alle EU-lidstaten verplichten zich dit in de nationale wetgeving op te nemen. Eerder zei Hirsch Ballin in antwoord op Kamervragen al dat de wijze waarop dit alles wordt vormgegeven, nog nader bepaald zal gaan worden. De zogenaamde ‘smalle’ meldplicht zou evenwel in mei 2011 geïmplementeerd dienen te zijn in de Nederlandse wet.[Antwoord op Kamervragen van Gesthuizen, Aanhangsel van de handelingen 165, vergaderjaar 2010-2011.] De Europese privacywaakhond, de artikel 29 werkgroep, had echter al in het advies op het voorstel tot wijziging van de ePrivacy-richtlijn aangegeven dat ‘An extension of personal data breach notifications to Information Society Services is necessary given the ever increasing role these services play in the daily lives of European citizens…’.[Opinion 1/2009 on the proposals amending Directive 2002/58/EC on privacy and electronic communications (e-Privacy Directive), p. 8.] Daarmee zouden alle dienstaanbieders van de informatiemaatschappij onder de plicht gaan vallen. Het advies werd niet overgenomen, maar is ook niet ongemerkt voorbijgegaan. Over de brede meldplicht volgt later in dit artikel meer.

Wat is dan die meldplicht datalekken?

De meldplicht komt voort uit wijzigingen van de Europese privacy- en telecommunicatiewetgeving.[RICHTLIJN 2009/136/EG VAN HET EUROPEES PARLEMENT EN DE RAAD van 25 november 2009 tot wijziging van Richtlijn 2002/22/EG inzake de universele dienst en gebruikersrechten met betrekking tot elektronische communicatienetwerken en -diensten, Richtlijn 2002/58/EG betreffende de verwerking van persoonsgegevens en de bescherming van de persoonlijke levenssfeer in de sector elektronische communicatie en Verordening (EG) nr. 2006/2004 betreffende samenwerking tussen de nationale instanties die verantwoordelijk zijn voor handhaving van de wetgeving inzake consumentenbescherming.] Deze ‘smalle’ meldplicht wordt opgenomen in de Telecommunicatiewet. In het voorstel van wet staat onder meer:

Artikel 11.3b

  1. De aanbieder van een openbare elektronische communicatiedienst stelt het college onverwijld in kennis van een inbreuk in verband met persoonsgegevens.
  2. De aanbieder bedoeld in het eerste lid stelt degene wiens persoonsgegevens het betreft onverwijld in kennis van een inbreuk in verband met persoonsgegevens indien de inbreuk naar verwachting nadelige gevolgen heeft of kan hebben voor diens persoonlijke levenssfeer.

Als een inbreuk heeft plaatsgevonden waarbij persoonsgegevens in het geding zijn, dan moet de nationale bevoegde instantie in kennis gesteld worden van dit datalek – voor Nederland is dat het College bescherming persoonsgegevens. Dit moet zonder onnodige vertraging (lees eigenlijk ‘vrijwel direct’) gebeuren. Daarbovenop vereist de nieuwe regelgeving dat ook de personen om wier gegevens het gaat een bericht ontvangen, echter, dan moet er wel sprake zijn van waarschijnlijk nadelige gevolgen voor de persoonlijke levenssfeer van het individu. Er moeten dus mogelijk nadelige gevolgen voor de privacy van personen in het geding zijn. Zijn de gegevens bijvoorbeeld dermate versleuteld dat leesbaarheid daarvan niet erg aannemelijk is, dan mag die aanbieder ervan afzien om zijn klanten van het lek op de hoogte te brengen.

De nationaal bevoegde instantie (het Cbp) kan de aanbieders zelfs dwingen om het datalek in de openbaarheid te brengen als ze van oordeel is dat de inbreuk ongunstige gevolgen kan hebben. Als aanbieder moet je in het geval van de melding wel een aantal zaken op orde hebben. Zo moet gemeld worden:

  • de aard van de inbreuk op de persoonsgegevens;
  • de contactpunten voor meer informatie;
  • aanbevolen maatregelen om de gevolgen van de inbreuk te verlichten (voor degene wiens gegevens betrokken zijn in het lek);
  • een omschrijving van de gevolgen; en
  • een omschrijving van de getroffen of voorgestelde maatregelen om de inbreuk daadwerkelijk aan te pakken.

De regeling kan zelfs zover strekken dat de nationaal bevoegde instantie specifieke aanwijzingen mag geven over hoe deze publieke kennisgeving gedaan moet worden; daarbij moet gedacht worden aan de manier waarop (online, via de eigen website, in de landelijke media, etc.) en het toepasselijke formaat daarvan. Overigens, als de aanbieder verzaakt het datalek te melden aan de bevoegde nationale instantie, kunnen sancties opgelegd worden. Wat betreft het College bescherming persoonsgegevens kan dan gedacht worden aan een last onder dwangsom of een bestuurlijke boete.[Artt. 65-75 Wbp.] En daarbovenop kan dan dus nog eens die openbaarmaking van het lek komen.

Niet iedereen wacht op het verschijnen van de wetgeving. Bits of Freedom heeft al enige tijd een eigen Zwartboek datalekken, waarop verschillende forse lekken uitgebreid uit de doeken worden gedaan.[Zie: www.bof.nl/category/zwartboek-datalekken/.] Dat het echt niet alleen maar gaat om uit burgerrechtelijke hoek gedane meldingen van datalekken, bewijst Gawker Media, dat in het openbaar te kennen gaf dat op de servers van het bedrijf een inbreuk had plaatsgevonden.[Zie: http://lifehacker.com/5712785/faq-compromised-commenting-accounts-on-gawker-media.] Bedrijven nemen dus ook zelf de verantwoordelijkheid op zich om lekken kenbaar te maken. Sterker nog, Gawker Media hield het niet alleen maar bij het melden dat er iets misgegaan was. Zo legde ze een uitgebreide FAQ aan waar gebruikers van hun websites onder meer kunnen lezen wat te doen als ze de account van Gawker-websites gelinkt hebben aan Facebook of Twitter, hoe de account van Gawker gedeletet kan worden en waarin ook uitgebreid aandacht is voor datgene wat het bedrijf zelf doet om het lek te dichten en de gevolgen zoveel mogelijk te beperken.

C-2011-2-Marbus-03

Figuur 2. Pagina van de website Zwartboek datalekken.

Een brede meldplicht datalekken

De meldplicht die dit jaar in werking moet gaan treden, treft slechts een gedeelte van de organisaties die te kampen (kunnen) hebben met het weglekken van data. Zoals eerder al aangegeven, is de roep om een bredere meldplicht al langere tijd sterker aan het worden. Zo geeft Eurocommissaris Kroes in de digitale agenda aan dat er op EU-niveau in ieder geval nagedacht wordt over een bredere meldplicht, alhoewel nog met een lichte slag om de arm: ‘In het kader van de recent opgezette herziening van het algemene gegevensbeschermingskader zal de plicht om dergelijke inbreuken tegen de gegevensbeveiliging te melden, eventueel worden uitgebreid’.[Een digitale agenda voor Europa, COM/2010/0245 f/2.] En ook in Nederland zelf lijkt het erop dat een brede meldplicht, voor zowel de overheid als de private sector, inmiddels serieus dichtbij komt, daarmee dus wellicht zelfs vooruitlopend op regelgeving van Europese kant. In de evaluatie van de Wet bescherming persoonsgegevens in maart 2010 merkte Hirsch Ballin echter al op: ‘De gedachte voor het invoeren van een meldplicht bij datalekken ondersteunen wij. Deze meldplicht zou een goede bijdrage zijn aan het bevorderen van de transparantie die een van de uitgangspunten moet blijven bij de bescherming van persoonsgegevens. Je moet kunnen weten wie jou registreert en op welke manier. De implementatie van het EU-brede traject (de smalle meldplicht – RM) verwachten wij dit kalenderjaar af te ronden’.[AO, TK 31051, 2009-2010, p. 20.] Hoe precies invulling gegeven kan worden aan die meer brede meldplicht wordt uit de evaluatie helaas nog niet duidelijk. Er is dus wel degelijk al langere tijd veel aandacht voor de realisering van de brede meldplicht en de discussie beperkt zich (gelukkig) niet alleen binnen de grenzen van het ‘privacydebat’. Ook in de begin 2011 gepresenteerde Nationale Cyber Security Strategie (NCSS) wordt binnen de paragraaf rondom het vergroten van de weerbaarheid van de vitale infrastructuur gerefereerd aan een brede meldplicht datalekken.[De Nationale Cyber Security Strategie, Slagkracht door samenwerking, 22 februari 2011.] De Memorie van Toelichting bij het wetsvoorstel rondom wijziging van de Telecommunicatiewet gaat expliciet in op de brede meldplicht. Daarin wordt nog eens benadrukt dat de minister van Justitie de Tweede Kamer de toezegging heeft gedaan dat er een concreet voorstel zal komen voor een brede meldplicht. Die brede meldplicht zal dan opgenomen gaan worden in de Wet bescherming persoonsgegevens. En ook wat dat aangaat, zal het College bescherming persoonsgegevens de instantie zijn die toezicht moet leveren op de naleving van de meldplicht.[Memorie van Toelichting wetsvoorstel wijziging Telecommunicatiewet, paragraaf 1.8 ‘Bescherming van persoonsgegevens en de persoonlijke levenssfeer’, 15 april 2010.] Op 29 april maakten staatssecretaris Teeven en minister Donner officieel bekend dat
de Wet bescherming persoonsgegevens aangepast zal worden en dat daarin een brede meldplicht opgenomen wordt voor alle aanbieders van informatiediensten.[Zie hiervoor onder meer het persbericht van 29 april 2011 op www.rijksoverheid.nl.] Het kabinet heeft aangegeven dat het een wetsvoorstel daartoe dit jaar nog ter consultatie zal willen aanbieden.

Wat is er nu voor en wat is er nu tegen?

Overduidelijk pluspunt: meer privacybescherming voor individuen. Althans, meer wetenschap over het feit dat er een inbreuk heeft plaatsgevonden. Het kwaad is al wel geschied, maar dat is praktisch inherent aan een inbreuk op de privacy en wordt daarom door privacyspecialisten al geruime tijd één van de ‘privacyparadoxen’ genoemd.[Een andere vaak gehoorde paradox is dat personen vaak zeggen veel waarde te hechten aan privacy en dus niet willen dat bijvoorbeeld de overheid veel gegevens verwerkt, maar tegelijkertijd wel zelf gemakkelijk (door middel van social media) allerlei persoonlijke informatie delen. Zie bijvoorbeeld: S. Barnes, A privacy paradox: social networking in the United States, Firstmonday, vol. 11, no. 9, 4 September 2006.] Zijn de gegevens eenmaal overgegaan in andere handen, dan kan weliswaar actie ondernomen worden, maar de zaak kan nooit meer volledig ongedaan gemaakt worden. Wat een dergelijke meldplicht echter mogelijk wel kan bewerkstelligen, is dat bedrijven alerter zullen reageren indien er een inbreuk heeft plaatsgevonden en wellicht zullen zij ook meer toezien (voor zover mogelijk) op het voorkomen van dergelijke lekken. In zoverre zou de meldplicht dus ook een preventieve werking kunnen hebben. Daar staat echter wel tegenover dat een inbreuk dan ook daadwerkelijk opgemerkt moet kunnen worden. In het huidige voorstel van wet is een verplichting opgelegd om iedere inbreuk te melden. De onmogelijkheid van detectie van elke inbreuk en het feit dat ook geringe inbreuken gemeld zouden moeten worden, zijn dan ook van meet af aan kritiekpunten op de meldplicht geweest.[Zie hierover bijvoorbeeld de reactie van KPN in de consultatieronde van het ministerie van Economische Zaken over het voorontwerp van wet tot implementatie van Richtlijnen 2009/136/EG en 2009/140/EG (versie 15 april 2010), verkrijgbaar via: http://www.internetconsultatie.nl/nrfimplementatie/.] KPN geeft aan dat het ‘lastig, zo niet onmogelijk’ is om altijd te achterhalen of er een veiligheidsinbreuk heeft plaatsgevonden die mogelijke gevolgen heeft voor de privacy van een individu. Caiway, Tele2 en Vodafone lopen te hoop tegen de onmogelijkheid om elk lek te ontdekken. In hun reactie schrijven zij dan ook dat ‘Indien een aanbieder veiligheidsmaatregelen heeft genomen die redelijkerwijs van hem kunnen worden verwacht, en hem een inbreuk op persoonsgegevens niet bekend is geworden, duidelijk zal moeten zijn dat hem niet kan worden verweten dat hij geen melding heeft gemaakt van de inbreuk.'[De reactie van Caiway, Tele2 en Vodafone in de consultatieronde van het ministerie van Economische Zaken over het voorontwerp van wet tot implementatie van Richtlijnen 2009/136/EG en 2009/140/EG (versie 15 april 2010), verkrijgbaar via: http://www.internetconsultatie.nl/nrfimplementatie/.] In haar samenvatting van de consultatie stelt het ministerie van Economische Zaken de betrokken partijen in zoverre gerust dat het aangeeft dat er gevallen denkbaar zijn waarin het niet melden van een datalek de aanbieder niet verweten kan worden. ‘Wat betreft mogelijke uitvoeringsproblemen wordt het volgende opgemerkt. Op grond van artikel 11.3 (Telecommunicatiewet – RM) dient de aanbieder van openbare elektronische communicatiediensten passende maatregelen te nemen ten behoeve van de veiligheid en beveiliging van de door hen aangeboden netwerken en diensten. Indien die beveiliging op orde is en er vindt een veiligheidsinbreuk plaats die waarschijnlijk zal leiden tot een aantasting van persoonsgegevens, en die inbreuk wordt niet opgemerkt, dan kan de aanbieder niet verweten worden dat hij de melding ervan heeft nagelaten. Een aanbieder behoeft en kan ook niet altijd op de hoogte zijn van het feit of als gevolg van een veiligheidsinbreuk er waarschijnlijk persoonsgegevens worden aangetast. Maar in veel gevallen zal de aanbieder voldoende aanwijzingen hebben dat bij het transport persoonsgegevens betrokken zijn.'[Consultatieverslag wetsvoorstel implementatie gewijzigd Europees regelgevend kader (NRF) in de Telecommunicatiewet, verkrijgbaar via: http://www.internetconsultatie.nl/nrfimplementatie/.] De laatste zin laat raden dat men niet zo heel snel zal aannemen dat een aanbieder niets verweten kan worden. Overigens kent ook de Wet bescherming persoonsgegevens voor de verwerker van persoonsgegevens de plicht om ‘passende technische en organisatorische maatregelen ten uitvoer [te leggen] om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking…’. Wel is deze eis strenger dan die welke is opgenomen in het wetsvoorstel van de wijziging Telecommunicatiewet, waar alleen gewezen wordt op ‘gepaste technische maatregelen’ en ‘versleuteling’.

Wat moeten organisaties regelen?

Elke organisatie – of het nu gaat om overheden of het bedrijfsleven – dient bij het verwerken van persoonsgegevens compliant te zijn met de Wet bescherming persoonsgegevens. Dit omvat onder meer het in kaart brengen van de informatiestromen binnen een organisatie (welke gegevens worden verwerkt en voor welke doeleinden), bezien of deze verwerkingen gemeld dienen te worden aan het College en indien er sprake is van zogenaamde Cross Border Data Transfer (gegevens worden buiten de EU/EER gebracht) moet rekening worden gehouden met een aantal specifieke vereisten, zoals bijvoorbeeld het verkrijgen van een vergunning daarvoor. Organisaties die deze zaken op orde hebben, zullen daardoor ook al een voorsprong hebben wat betreft de verplichtingen die voortvloeien uit de meldplicht. Door het op orde hebben van deze zaken zal een organisatie onder meer makkelijker kunnen aangeven wat de aard van de gegevens is en zal ze ook sneller een goed oordeel kunnen geven over de mogelijke impact van het datalek. Er dient immers een omschrijving van de gevolgen en de daarop genomen en nog te nemen maatregelen verstrekt te worden aan het College. In het verlengde daarvan is het noodzakelijk dat organisaties een zogenaamd ‘actieplan’ gereed hebben liggen voor het geval zich daadwerkelijk een datalek voordoet. Een dergelijk plan dient onder meer vast te leggen aan wie binnen de organisatie gemeld wordt dat er een onregelmatigheid heeft plaatsgevonden en welke maatregelen dientengevolge genomen moeten worden (denk daarbij aan het in kaart brengen van de gegevens die mogelijk bij het lek gecompromitteerd zijn geraakt, het gereed hebben van die concrete maatregelen en het uiteindelijke doen van de melding bij het College). Dit is te meer dringend daar een melding aan het College ‘onverwijld’ dient te geschieden.

Het adequaat beveiligen van persoonsgegevens die een organisatie verwerkt, is al onderdeel van de verplichtingen binnen de Wbp. Artikel 13 stelt dat een organisatie passende technische en organisatorische maatregelen ten uitvoer moet leggen tegen verlies of enige vorm van onrechtmatige verwerking. Daarbij moet rekening worden gehouden met de stand van de techniek (wat is feitelijk mogelijk?), de kosten (de kosten moeten proportioneel zijn), maar ook bijvoorbeeld de aard van de gegevens (zo geldt onder de Wbp een strenger regime voor het verwerken van gevoelige persoonsgegevens). Het begrip ‘passende’ maatregelen is niet nader ingevuld in de wet, alhoewel zoals vermeld wel enkele aanknopingspunten zijn gegeven waarmee rekening gehouden moet worden. Belangrijk in het licht van de meldplicht datalekken is het feit dat in het voorliggende voorstel voor de ‘smalle’ meldplicht opgenomen is dat, indien de gegevens cryptografisch versleuteld zijn, een lek weliswaar nog steeds gemeld dient te worden aan het College, maar dat daarbij niet tevens de personen om wier gegevens het gaat ingelicht hoeven te worden. Uit het oogpunt van bedrijfsrisico en dan met name wat betreft de publieke reputatie van een organisatie is het dus een groot pluspunt om de persoonlijke gegevens te versleutelen.

Een laatste belangrijk aspect wat betreft zaken rondom privacy en beveiliging van gegevens is dat het bij het puur technische op orde hebben van de beveiliging niet stopt. Zoals de Wet bescherming persoonsgegevens al aangeeft gaat het ook om het organisatorisch passend beveiligen van de gegevens die verwerkt worden. Privacy en beveiliging moeten dus ook ingebed raken in de organisatie zelf. Te denken valt dan aan het bevorderen van awareness onder werknemers (een e-learningcursus bij aanstelling of workshop voor huidige werknemers), het actief verspreiden en toetsen van het interne beleid (policies beschikbaar stellen op intranet en deze regelmatig updaten) en het beschikbaar hebben van procedures voor het geval zich een datalek voordoet. Daarnaast dienen de verantwoordelijkheden op de juiste plaats belegd te worden en dient er een veiligheidsbeleid te zijn.

Concluderend: is het nu een zorg of een zegen?

Waarschijnlijk een beetje van beide. De angst voor de publieke schandpaal doet menig bedrijf beven. Reputatieschade wordt over het geheel genomen toch vaak zwaarder gewogen dan de (geringe) boete van het College bescherming persoonsgegevens. Waarbij overigens opgemerkt moet worden dat de boetecapaciteit van het College inmiddels ook serieus ter discussie staat en naar verwachting in de herziening van de privacywetgeving op EU-niveau zal worden uitgebreid. Hoe dat eruit komt te zien, is nog niet te zeggen, maar een uitbreiding naar hogere boetemogelijkheden lijkt wel voor de hand te liggen. Ook de praktische uitvoerbaarheid – het moeten melden van elk lek – zal vermoedelijk enige kopzorgen opleveren (om nog maar te zwijgen van de kosten, een aspect waar ook verschillende aanbieders op wezen binnen de consultatieronde op het wetsvoorstel). Maar toch ook een zegen. In ieder geval voor het individu wiens gegevens met enige regelmaat op straat lijken te liggen. Openbaarheid noopt wellicht tot meer voorzichtigheid. Hoe een en ander in de praktijk daadwerkelijk zal uitpakken is vooralsnog gissen. Maar dat erover gepraat zal worden in 2011 staat in ieder geval vast. En … hopelijk zal ook serieus gewerkt worden aan die uitbreiding van de meldplicht. Datalekken komen namelijk echt niet alleen maar voor bij telco’s en ISP’s. Zo was recent ook de klant van McDonalds de klos ([Ring10a]), lekte het KLPD een fax met tapgegevens ([Zeng10a]), zagen miljoenen Amerikanen hun medische gegevens op straat liggen ([Ring10b]), lagen de medische gegevens van enkele Nederlanders bij de Kringloop ([Zeng10b]), en werd een Amerikaanse bank aangeklaagd omdat zij een datalek had geprobeerd te verdoezelen ([Brow10]).

Hoe kunnen organisaties zich nu voorbereiden op die aankomende meldplicht? Door er in ieder geval voor te zorgen dat:

  • er alles aan gedaan is de beveiliging op orde te hebben (heeft u de kennis niet zelf in huis, dan loont het de moeite deze in te huren), daarnaast: versleutelde data hebben in beginsel het voordeel dat een mogelijk lek niet aan de personen (klanten vaak) om wier data het gaat, gemeld hoeft te worden;
  • er besef is dat beveiliging niet alleen maar het technisch afdichten van de systemen is (denk aan de plicht binnen de Wet bescherming persoonsgegevens om ook organisatorisch de zaken op orde te hebben);
  • er gewerkt wordt aan inrichting van processen en richtlijnen over hoe te handelen in geval zich een datalek voordoet, dit inclusief het op orde hebben van up-to-date informatie, zeker gezien het feit dat een lek ‘onverwijld’ gemeld moet worden en daarbij ook eisen gesteld zijn wat betreft welke informatie paraat moet liggen.

Literatuur

[Brow10] D. Browning, U.S. bank allegedly concealed data breach, Star Tribune, 7 december 2010.

[KPMG10] KPMG Data Loss Barometer, november 2010, www.datalossbarometer.com.

[Ring10a] T. van Ringelestijn, Hackers stelen data McDonalds-klanten, Webwereld, 13 december 2010.

[Ring10b] T. van Ringelestijn, Miljoenen medische gegevens Amerikanen gelekt, Webwereld, 26 november 2010.

[Zeng10a] R. Zenger, Datalek: KLPD lekt fax met tapgegevens, 25 november 2010, Zwartboek Datalekken, BoF.

[Zeng10b] R. Zenger, Datalek: Medische gegevens in Kringloopwinkel, 13 december 2010, Zwartboek Datalekken, BoF.

Access Governance: een einde aan de worsteling rondom autorisatiemanagement?

Access Governance is een aanpak waarbij op een geautomatiseerde wijze autorisaties van een heterogeen applicatielandschap worden geanalyseerd met als doel de risico’s van ongeautoriseerde toegang te verminderen. Access Governance wordt ingezet als internecontrolemaatregel, maar kan ook onderdeel uitmaken van de interne of externe audit, waarbij de externe accountant steunt op de uitkomst van het Access Governance-proces en hiermee waarborgen krijgt omtrent de juistheid van de toegang tot de financiële systemen en onderliggende infrastructuur. Naast voornoemde aspecten wordt in dit artikel uitgelegd hoe Access Governance as a Service kan worden ingezet, wat inhoudt dat een organisatie de periodieke autorisatieanalyse uitbesteedt aan een externe partij. Dit model is ook toepasbaar in relatie tot de betrokkenheid van IT-audit bij de jaarrekeningcontrole. Daarnaast wordt de relatie tussen Access Governance en Identity & Access Management (IAM) gegeven.

Inleiding

Het afgelopen decennium is er bij veel organisaties aandacht geweest voor logisch toegangsbeheer. Deze organisaties zijn vaak gestart met een verbeterproject. Ondanks de toenemende aandacht voor toegangsbeheer worstelen nog steeds veel organisaties met dit onderwerp. Toegangsbeheer is veelal een aandachtspunt in de management letter (brief met bevindingen en aanbevelingen naar aanleiding van de jaarrekeningcontrole) van de externe accountant. Hierbij kan men zich afvragen waarom toegangsbeheer een terugkomend aandachtspunt is. Is het onderwerp niet relevant genoeg omdat er bijvoorbeeld voldoende compenserende maatregelen zijn ingericht en additioneel getoetst zijn waardoor bevindingen niet tot echte issues leiden? Of wordt de oplossing van het probleem als te complex ervaren? Beide spelen in ieder geval een rol. Het steunen op mogelijke compenserende maatregelen is echter risicovol. Een organisatie weet vooraf niet of deze maatregelen achteraf voldoende zijn. Daarnaast loopt de organisatie nog steeds risico’s dat (oud-)medewerkers (intern/extern) misbruik maken van een teveel aan autorisaties.

De perceptie dat het structureel verbeteren van logisch toegangsbeheer complex is en gepaard gaat met dure IAM-projecten en ondersteunende software is te begrijpen. IAM-projecten richtten zich vaak voor een groot gedeelte op automatisering van toegangsprocessen, waarbij de kwaliteit van autorisaties niet direct de benodigde prioriteit kreeg en het echte probleem dus niet voldoende werd opgelost. Wanneer er werd gekozen voor de implementatie van rolgebaseerde toegang (Role Based Access Control – RBAC), betekende dit vaak langdurige trajecten om tot een rollenmodel te komen dat passend was voor de gehele organisatie en in veel gevallen werden de doelstellingen niet gerealiseerd. Nu beoogt dit artikel niet om u als lezer volledig af te laten stappen van IAM en RBAC. IAM gecombineerd met RBAC is namelijk nog steeds een adequate methode om logisch toegangsbeheer verregaand te professionaliseren en te automatiseren. De doelstelling van het artikel is wel om u kennis te laten maken met een meer detectieve aanpak (Access Governance). Dit is een aanpak waarbij autorisaties periodiek worden beoordeeld tegen vastgestelde regels, zoals functiescheiding en autorisatiematrices. Vervolgens kan een organisatie op basis van de ambities/noodzaak besluiten om door te groeien naar een preventieve aanpak op basis van IAM en RBAC. De afwegingen tussen deze scenario’s worden verderop in het artikel toegelicht. Een toelichting op IAM is opgenomen in onderstaand kader.

IAM uitgelegd

IAM is een samenspel van beleid, processen en systemen om efficiënt en effectief het proces te beheersen waarin de toegang met betrekking tot applicaties wordt beheerd. In figuur 1 zijn de verschillende IAM-componenten schematisch weergegeven.

C-2011-2-Hart-01

Figuur 1. Het IAM-referentiemodel.

Het referentiemodel is opgebouwd uit de volgende IAM-processen:

  • Gebruikers- en autorisatiebeheer. Dit domein richt zich op de activiteiten gerelateerd aan het beheren van identiteiten (en daaraan gerelateerd de gebruikersaccounts) binnen de gebruikersadministratie. Het heeft betrekking op de gehele levenscyclus (initiële vastlegging, wijziging en verwijdering) van eindgebruikeraccounts. Daarnaast richt het gebruikersbeheer zich op het koppelen van organisatierollen (en specifieke autorisaties) aan geregistreerde identiteiten. Enerzijds geschiedt deze koppeling door het (automatisch) koppelen van afleidbare rollen op basis van attributen binnen de bronregistratie (bijvoorbeeld SAP HCM), anderzijds door het inrichten van een workflow/gebruikersinterface voor toekenning van rollen die niet afleidbaar zijn vanuit de bronregistratie (zoals taakgebaseerde of tijdelijke rollen).
  • Rollenbeheer. Dit domein richt zich op de activiteiten ten aanzien van het definiëren en beheren van organisatierollen, onder andere afgeleid van de administratie van de organisatie en via data-analyses. Via deze organisatierollen verkrijgt men toegang tot en binnen de applicaties. Omdat niet alle autorisaties via rollen zullen worden toegekend, worden binnen het rollenbeheer ook ‘losse’ autorisaties opgenomen in het autorisatiemodel. Dit betreft bijvoorbeeld applicatierollen.
  • Provisioning. Dit domein betreft het aanmaken dan wel verwijderen van accounts, en het toekennen dan wel afnemen van autorisaties voor deze accounts in de systemen. Provisioning kan zowel volledig geautomatiseerd als handmatig (met tussenkomst van een functioneel beheerder) plaatsvinden.
  • Monitoring en auditing. Dit domein richt zich op het controleren van de naleving van het van toepassing zijnde beleid en het vergelijken van de geïmplementeerde toegangsrechten (‘ist’) met de gewenste en/of geadministreerde toegangsrechten in het rollenmodel (‘soll’).

Access Governance uitgelegd

Access Governance is een efficiënt proces om de toegang met betrekking tot applicaties/systemen op een frequente basis te reviewen. Bij dit proces wordt gebruikgemaakt van analysesoftware. Verderop in dit artikel wordt de relatie tussen IAM en Access Governance verder uitgewerkt. Samenvattend kan worden gesteld dat Access Governance een detectief proces is om autorisaties te valideren en op te schonen. Hiermee is het een opmaat naar de implementatie van preventieve controles met IAM, zoals de implementatie van Role Based Access Control.

In figuur 2 is het Access Governance-proces schematisch weergegeven.

C-2011-2-Hart-02

Figuur 2. Autorisatieverificatieproces.

Het autorisatieverificatieproces beslaat grofweg drie fasen.

Fase 1. Data verzamelen en definiëren testregels

In de eerste fase wordt allereerst bepaald welke systemen/applicaties moeten worden bekeken. Vervolgens worden per applicatie de autorisatiedata geëxporteerd naar bijvoorbeeld een ‘comma separated file’, een zogenaamd plat tekstbestand. De export van de autorisatiedata kan uit verschillende bestanden bestaan, aangezien diverse informatie benodigd is, onder andere de koppeling van de autorisaties aan de accounts; het totaaloverzicht van beschikbare autorisaties.

De tweede stap is het verkrijgen van de persoonsgegevens uit de HR-administratie. Eén van de basale controles is namelijk het nagaan of ieder account te herleiden is tot een natuurlijke persoon uit die HR-administratie. Om te voorkomen dat te veel accounts niet gekoppeld kunnen worden, is het noodzakelijk dat de externe medewerkers ook in een bronregistratie zijn opgenomen. Dit mag een tweede, aparte registratie zijn. Uit deze controle komen altijd accounts naar voren die niet te koppelen zijn aan een persoon. Dit betreft namelijk de systeemaccounts die vaak benodigd zijn voor bepaalde functies in een applicatie. Overigens zouden deze systeemaccounts wel te verklaren moeten zijn en zou aan ieder systeemaccount een eigenaar moeten zijn toegekend die het account beheert, maar in de praktijk blijkt dit echter niet altijd het geval te zijn.

Om de autorisatieanalyse goed te kunnen verrichten, moeten zogenaamde bedrijfsregels worden opgesteld. Deze kunnen onderscheiden worden in generieke bedrijfsregels en applicatiespecifieke bedrijfsregels. De generieke regels zijn op iedere applicatie van toepassing. Hierbij kan worden gedacht aan:

  • Ieder persoonlijk account moet te herleiden zijn tot een natuurlijk persoon uit een bronregistratie, zodat activiteiten in de applicaties zijn te herleiden tot personen.
  • Er mogen geen test-accounts in de productieomgeving actief zijn, zodat test-accounts niet misbruikt kunnen worden voor daadwerkelijke transacties.
  • Er mag geen account met alle autorisaties zijn om te voorkomen dat hiermee functiescheiding wordt doorbroken.

De applicatiespecifieke regels worden opgesteld per applicatie. Deze regels zijn gebaseerd op eventuele reeds aanwezige autorisatiematrices of specifieke functiescheidingsregels. De eigenaar van de applicatie (applicatie- c.q. proceseigenaar) is verantwoordelijk voor de toegekende autorisaties in de applicatie. De applicatiespecifieke regels worden daarom afgestemd met de proceseigenaar. Bij dit afstemmingsproces is vaak ook functioneel beheer betrokken, maar uiteindelijk worden de regels goedgekeurd door de proceseigenaar. De applicatiespecifieke regels kunnen ook testen of functiescheiding over applicaties heen wordt nageleefd. Daarnaast kunnen ook specifieke regels voor IT-componenten (bijvoorbeeld de database en het besturingssysteem) worden gedefinieerd, zodat autorisaties uit het gehele applicatiedomein worden getest. De applicatiespecifieke regels richten zich voornamelijk op de non-SAP-omgeving, aangezien voor SAP al specifieke analysesoftware met voorgedefinieerde regels aanwezig is.

Fase 2. Uitvoeren analyse

De in de vorige fase gedefinieerde bedrijfsregels worden ingevoerd in de analysesoftware. Gecombineerd met de autorisatie- en HR-data die in de voorgaande fase zijn vergaard, wordt nu de geautomatiseerde analyse uitgevoerd. Op basis van de regels worden overzichten gegenereerd van zaken die afwijken van de ingevoerde bedrijfsregels.

Voordat de overzichten met afwijkingen in de rapportages worden verwerkt, worden de ruwe overzichten afgestemd met een functioneel beheerder. Op basis van deze afstemming worden de resultaten verder verfijnd. Hiermee wordt zoveel mogelijk voorkomen dat in de rapportage afwijkingen zijn opgenomen die ten onrechte als afwijking zijn geclassificeerd, bijvoorbeeld doordat een regel niet correct is gedefinieerd.

Fase 3. Rapportage en follow-up

In deze fase worden afwijkingsoverzichten verwerkt tot rapportages. In deze rapportages kan ook een vergelijking worden gemaakt met het aantal afwijkingen per regel ten opzichte van de voorgaande controle. Op basis van een dergelijk overzicht wordt eenvoudig inzicht verkregen in de voortgang van de follow-up, namelijk of de eerder geconstateerde afwijkingen zijn opgelost.

C-2011-2-Hart-03

Figuur 3. Voorbeeld van afwijkingsdashboard.

De terugkoppeling van de resultaten vindt plaats met de proceseigenaar. Deze persoon bepaalt of een afwijkende autorisatie verwijderd moet worden of dat een specifieke situatie als uitzondering wordt geaccepteerd. Dit dient dan uiteraard wel te worden vastgelegd. In de rapportage kan ook een risicoclassificatie worden opgenomen, zodat direct duidelijk is of en zo ja, hoeveel afwijkingen als hoog risico worden geclassificeerd. Voor deze afwijkingen kan worden besloten om na te gaan of het teveel aan autorisaties daadwerkelijk is misbruikt en of er compenserende maatregelen van toepassing zijn die het risico van ongeautoriseerde transacties verminderen. Dit is met name van belang indien in het kader van de financiële audit wordt gesteund op de periodieke autorisatieverificatie (het Access Governance-proces).

Op grond van de aard van de afwijkingen kunnen ook suggesties worden gedaan om het autorisatiemanagementproces te verbeteren om afwijkingen in de toekomst te voorkomen.

De belangrijkste kenmerken van Access Governance:

  • Analyse van een heterogeen applicatielandschap
  • Off-line analyse → geen online connectie met te analyseren applicatie nodig
  • Aanpak met focus, organisatie kan zich alleen richten op kritieke applicaties en gegevens
  • Schaalbaar van 1 – n applicaties
  • Praktische aanpak met direct resultaat
  • Aanpak is leverancieronafhankelijk en diverse softwarepakketten zijn beschikbaar voor analyse

Mogelijke verbeteringen bij vervolgiteraties

Access Governance heeft de meeste toegevoegde waarde als het verificatieproces periodiek wordt herhaald, bijvoorbeeld ieder kwartaal. In dat geval worden afwijkingen relatief snel opgemerkt en wordt het risico op misbruik kleiner. De eerste iteratie is normaliter de meest intensieve iteratie omdat dan het gehele proces moet worden opgezet en de bedrijfsregels moeten worden geïnventariseerd. De vervolgiteraties bieden daarom vaak ruimte voor verbetering van het verificatieproces door:

  • applicatiespecifieke regels met meer diepgang te definiëren;
  • een risicoclassificatie aan de bedrijfsregels toe te kennen.

Voordelen voor de (financial) auditfunctie

Traditioneel is het testen van de effectiviteit van logische toegangsbeheermaatregelen arbeidsintensief en vergt dit veel handmatig werk. Hierdoor is het testen van de toegangsbeheermaatregelen vaak meer een ad-hocproces waar de (financial) auditor slechts beperkt op kan steunen. In tabel 1 zijn de belangrijkste voordelen weergegeven.

C-2011-2-Hart-t01

Tabel 1. De voordelen van Access Governance.

Naast de bovengenoemde voordelen kan Access Governance ook als auditinstrument worden ingezet bij de verkoop of opsplitsing van bedrijfsonderdelen. Access Governance maakt namelijk inzichtelijk wie waartoe toegang heeft en op basis van de rapportages en autorisatieoverzichten kan worden bepaald welke rechten moeten worden ingetrokken van personeel dat na de splitsing of verkoop niet meer werkzaam is bij de organisatie.

Inrichten van Access Governance

Om te voorkomen dat autorisaties na één controleslag worden geschoond en er daarna weer vervuiling ontstaat die niet tijdig wordt opgemerkt, is het van belang om een periodiek controleproces in te richten. Op deze manier implementeert de organisatie een detectieve controlemaatregel op een structurele wijze.

Een organisatie kan ervoor kiezen om het controleproces intern te implementeren. In de praktijk blijkt dat de verantwoordelijkheid voor het faciliteren van dit process vaak bij een afdeling Risk Management of Security Management terechtkomt. De proceseigenaren zelf zijn verantwoordelijk voor de uitvoering van het proces en het laten doorvoeren van de benodigde autorisatiewijzigingen. Risk Management of Security Management heeft dan een bewakende rol om ervoor te zorgen dat het controleproces juist en tijdig wordt doorgevoerd en dat de proceseigenaar zich met name bezighoudt met de vaststelling van de bedrijfsregels en de follow-up van de rapportages (oplossen van de geconstateerde afwijkingen). De daadwerkelijke uitvoering kan afhankelijk van de capaciteit worden belegd bij de IT-organisatie of bij Risk dan wel Security Management. Voor het intern uitvoeren van het controleproces moet ook analysesoftware worden aangeschaft door de organisatie.

Een ontwikkeling die steeds meer in opkomst is, is het uitbesteden van de daadwerkelijke uitvoering van het controleproces: Access Governance as a Service. In dat geval blijft de organisatie wel verantwoordelijk voor de uitvoering van het controleproces en het feit of afwijkingen worden opgevolgd. De uitvoering van het gehele controleproces, inclusief het verkrijgen van data en het inventariseren van bedrijfsregels, wordt uitbesteed aan een externe partij. Groot voordeel van Access Governance as a Service is dat de organisatie zelf geen kennis hoeft op te bouwen in het controleproces en geen kennis hoeft te hebben van de analysesoftware. Tevens hoeft de organisatie niet zelf analysesoftware aan te schaffen en te beheren. Een derde punt is dat door de uitbesteding de organisatie er zeker van is dat het controleproces wordt uitgevoerd. Bij controleprocessen die intern worden uitgevoerd is het risico groter dat vanwege drukke werkzaamheden bepaalde controles niet of niet tijdig worden verricht.

Met name het aantal applicaties dat geanalyseerd dient te worden en hoe vaak, is bepalend voor de vraag of het verstandig is om het controleproces intern te beleggen of extern als Access Governance as a Service. Hoe meer analyses er moeten worden uitgevoerd, hoe hoger de investering voor uitbesteden wordt. Het is daarom raadzaam om bijvoorbeeld eerst een beperkt aantal applicaties te laten analyseren en op basis van de ervaringen de Access Governance-strategie te bepalen, waarin onder andere de volgende aspecten aan bod komen:

  • scope van de analyse (welke applicaties/systemen);
  • frequentie van de analyse;
  • belegging van de taken en verantwoordelijkheden voor de verschillende onderdelen uit het proces;
  • groeimodel richting preventieve maatregelen (IAM-implementatie).

Relatie Access Governance & Identity en Access Management

Zoals in het kader in het begin van dit artikel uitgelegd, is IAM een samenspel van beleid, processen en systemen om efficiënt en effectief het proces te beheersen waarin de toegang met betrekking tot applicaties wordt beheerd. Een brede IAM-implementatie behelst hierbij meerdere processen. Access Governance is voornamelijk een rapportageproces waarbij wordt beoogd op basis van afwijkingsrapportages de bestaande situatie van de geïmplementeerde autorisaties te wijzigen en in lijn te brengen met de geldende bedrijfsregels. Een groot voordeel van Access Governance ten opzichte van IAM is dat geen tijdrovende implementatie van een RBAC-model noodzakelijk is. Dit is met name voor organisaties waarbij de bedrijfsprocessen niet of in een beperkte mate zijn gestandaardiseerd een grote uitdaging.

In figuur 4 is Access Governance gepositioneerd ten opzichte van IAM.

C-2011-2-Hart-04

Figuur 4. Access Governance gepositioneerd ten opzichte van Identity & Access Management.

Vanuit Access Governance kan de organisatie stapsgewijs doorgroeien richting een IAM-implementatie waarbij meer preventieve maatregelen worden geïmplementeerd en steeds meer wordt opgeschoven richting continuous auditing omdat een IAM-voorziening continu inzicht kan geven in de juistheid van de geïmplementeerde autorisaties. Afwegingen om te bepalen of de stap van Access Governance richting een brede IAM-voorziening voldoende toegevoegde waarde biedt, zijn:

  • Is meer zekerheid nodig over de juistheid van de autorisaties, is de organisatie nog niet voldoende in control?
  • Biedt Access Governance voldoende basis voor de externe accountant en/of toezichthouders? Afhankelijk van het profiel van de organisatie en de wijze van inrichting van het controleproces kan dit voldoende zijn.
  • Is er behoefte aan automatisering van de processen om autorisaties sneller te laten verwerken?
  • Is er voldoende ‘pijn’ in de organisatie om het aanvraagproces verregaand te gaan aanpassen met workflows/gebruikersinterface voor aanvraagproces en rolgebaseerde toegang?

Het is van belang zich te realiseren dat het niet altijd de ambitie hoeft te zijn om een brede IAM-voorziening te implementeren. Voor sommige organisaties biedt een goed functionerend Access Governance-proces voldoende invulling aan de uitdagingen rondom logisch toegangsbeheer. Daarnaast zijn er nog tussenvormen mogelijk tussen Access Governance en een brede IAM-implementatie. Men kan bijvoorbeeld de bedrijfsregels die binnen Access Governance worden gebruikt ook hanteren in het aanvraagproces. De aanvragen worden dan vooraf getoetst tegen de bedrijfsregels om vervuiling te voorkomen. Ook kan het controleproces bijvoorbeeld verregaand worden geautomatiseerd, waarbij managers via een workflow aangeven of een afwijking moet worden ingetrokken of dat het een geaccepteerde uitzondering betreft.

Conclusie

Het aantoonbaar verantwoording kunnen afleggen over de juistheid van autorisaties is van belang voor organisaties en is voor veel organisaties een uitdaging. Access Governance is een aanpak waarbij autorisaties periodiek op een pragmatische wijze worden geanalyseerd. Op basis van de resultaten kan het teveel aan autorisaties worden geschoond. Met name de pragmatiek van de aanpak komt tegemoet aan de complexiteit van een brede IAM-implementatie waarbij de baten ten aanzien van de juistheid van de toegekende autorisaties op korte termijn uitblijven. Access Governance past goed binnen de financial audit omdat de aanpak de mogelijkheid biedt om specifieke applicaties diepgaand te analyseren op de juistheid van de autorisaties.

Ten slotte biedt een goed functionerend Access Governance-proces de basis om door te groeien richting een brede IAM-implementatie indien een organisatie hiertoe de ambitie heeft.

SIEM: dé oplossing voor het beveiligingsbeheer van het IT-landschap?

Het steeds complexer wordende IT-landschap betekent voor organisaties een groeiende uitdaging dit aantoonbaar onder controle te houden. De eerste uitdaging is het in kaart brengen van de beveiligingsstatus van dit landschap. Deze informatie is niet alleen nodig in verband met compliance-eisen vanuit wet- en regelgeving zoals de Sarbanes-Oxley (SOx), privacywetgeving en de Payment Card Industry Data Security Standard (PCI DSS), maar het stelt organisaties ook in staat tijdig en adequaat te reageren op belangrijke beveiligingsmeldingen en de steeds complexer en professioneler wordende externe dreigingen. De tweede uitdaging ligt in het adequaat handelen naar aanleiding van de gedetecteerde beveiligingsmeldingen en -dreigingen. Dit stelt organisaties beter in staat te reageren op dreigingen en geeft hen ook meer inzicht in het risico dat zij lopen. Dit artikel geeft een introductie tot Security Information & Event Management (SIEM) als oplossing voor de gerezen vraagstukken.

Inleiding

Moderne computernetwerken staan onder een continue dreiging van hackers en ongeautoriseerde handelingen van (malafide) medewerkers. IT-omgevingen worden complexer, onder andere door fusies en acquisities. Externe IT-dienstverleners krijgen een steeds grotere rol juist doordat zeer specialistische kennis nodig is voor specifieke IT-omgevingen. De afhankelijkheid van informatietechnologie groeit. Hierdoor neemt het aantal (bekende) beveiligingsincidenten dagelijks toe en stijgen de kosten daarvan ([KPMG10], [McAf11]).

In reactie hierop hebben organisaties geprobeerd zichzelf te beschermen door het implementeren van beveiligingsmaatregelen zoals antivirussoftware, firewalls en intrusion detection systemen. Deze producten zijn stuk voor stuk nuttig maar creëren ook nieuwe problemen. Immers, de complexiteit van het IT-landschap neemt toe, net als het aantal beveiligingsmeldingen. Dit stelt bedrijven voor twee uitdagingen. Enerzijds het in kaart brengen van de beveiligingsstatus van het IT-landschap en anderzijds adequaat handelen naar aanleiding van de gedetecteerde beveiligingsmeldingen en -dreigingen.

Aan deze uitdagingen zijn twee belangrijke aspecten verbonden: ‘inzicht’ en ‘tijdigheid’. De uitdaging is om op grond van de miljoenen beveiligingsmeldingen te komen tot tijdige en relevante inzichten. Dit op een slimme geautomatiseerde manier. Deze ‘slimme manier’ moet de menselijke factor in de operationele uitvoering zo klein mogelijk houden om de reactiesnelheid en de kosten zo laag mogelijk te houden. De alternatieven, zoals het (laten) uitvoeren van een grote hoeveelheid IT-audits of het (periodiek) handmatig doorzoeken van logbestanden, zijn vaak geen reële optie. Deze alternatieven kennen vaak een vrij lange aanloop- en doorlooptijd, met veel menselijke betrokkenheid en daarmee relatief hoge kosten.

De markt heeft deze wens inmiddels onderkend. Onder de naam Security Information & Event Management (SIEM) ontplooien diverse organisaties en leveranciers initiatieven die handig inspelen op de geschetste situatie en de wensen van het management. Dit artikel heeft als doel helderheid te scheppen over zaken die meespelen in de volgende vragen: Wat is SIEM? En hoe kan een SIEM-voorziening helpen de wensen over ‘tijdig inzicht’ in te vullen? Daarnaast zullen we ingaan op leerervaringen uit de praktijk.

Wat is SIEM?

In de loop der tijd zijn diverse definities en interpretaties van SIEM ontstaan, mede doordat SIEM tevens een marketingconcept is geworden. SIEM kan begrepen worden als:

… de combinatie van software en hardware die is toegewezen om geautomatiseerd IT-gerelateerde beveiligingsinformatie te verzamelen, te combineren en te analyseren, met als doel om tijdig inzicht te krijgen en proactief te reageren op activiteiten die een negatieve invloed kunnen hebben op de vertrouwelijkheid, integriteit of beschikbaarheid van data of IT-middelen.

Onder ‘IT-gerelateerde beveiligingsinformatie’ verstaan wij het volgende:

  • Gebeurtenissen die een negatieve invloed hebben op het beveiligingsniveau. Een voorbeeld is het aanmaken van een gebruikersaccount met beheerrechten op een kritieke applicatie.
  • Afwijkingen van de technische configuratiestandaarden (baselines). Denk hierbij bijvoorbeeld aan een incorrect wachtwoordbeleid op een server.
  • Kwetsbaarheden binnen de IT-middelen. Bijvoorbeeld het toestaan van onveilige communicatie naar een server.

Kort gezegd maakt een SIEM-voorziening gebruik van bestaande logging- en monitoringfaciliteiten. Zij combineert deze informatie tot relevante informatie en rapporteert hierover. Deze rapportages kunnen zowel betrekking hebben op de beveiligingsstatus van IT-middelen als op beveiligingsgerelateerde activiteiten. Enkele veelvoorkomende voorbeelden van het gebruik van SIEM zijn:

  • het geautomatiseerd monitoren van systemen, applicaties en/of databaselogging met de mogelijkheid in een vroeg stadium misbruik van systemen te detecteren en hierover te rapporteren;
  • het geautomatiseerd monitoren van systemen, applicaties en/of databaselogging met als doel continu inzicht te hebben in de staat van de ‘compliance’ met interne of externe vereisten;
  • het ondersteunen in het onderzoek naar een incident door loginformatie uit het verleden te analyseren en de verschillende gebeurtenissen op de verschillende systemen (grafisch) weer te geven.

Deze definitie en voorbeelden zijn nog steeds vrij breed, vandaar wellicht ook dat SIEM inmiddels een paraplubegrip is geworden. Het is daarom nuttig om aan te geven wat wij niet verstaan onder SIEM:

  • Een Service Level Management-voorziening. Er zijn producten op de markt die bijvoorbeeld de beschikbaarheid en prestaties van IT-middelen bewaken. Deze gegevens worden vervolgens gebruikt om aan te tonen dat (al dan niet) aan (klant)afspraken is voldaan. SIEM-systemen kunnen hier wel een bijdrage aan leveren, maar richten zich meer op de activiteiten die op deze IT-middelen worden uitgevoerd.
  • Een gecentraliseerde opslagfaciliteit van logbestanden. Sommige producten bieden de functionaliteit logbestanden beveiligd op te slaan. Het doel hiervan is om bij beveiligingsincidenten achteraf te kunnen vaststellen wat er is gebeurd. Een SIEM-voorziening bewaakt het IT-landschap continu en vrijwel real-time. Zij beperkt zich niet tot analyse nadat beveiligingsincidenten of fraude in volle omvang aan het licht zijn gekomen.
  • Een voorziening die volledige beveiliging geeft, of de werking van alle andere beveiligingsproducten overneemt. De effectiviteit van een SIEM-voorziening zal juist mede afhangen van de logbestanden van de andere beveiligingsproducten.

C-2011-2-Boer-01

Figuur 1. Schematische weergave van het gewenste procesverloop bij beveiligingsincidenten.

Hoewel SIEM-voorzieningen soms worden ingezet om te valideren of systemen kwetsbaar zijn voor bepaalde aanvallen door hackers, gaan we hier in dit artikel niet op in.

Er zijn diverse grote spelers op de markt die SIEM-voorzieningen aanbieden. Vaak wordt een complete oplossing in één suite aangeboden. In een aantal gevallen wordt echter onderscheid gemaakt tussen Security Event Management (SEM) en Security Information Management (SIM). Een SEM-voorziening richt zich op het ‘real-time’ monitoren en managen van beveiligingsgebeurtenissen. SIM-voorzieningen richten zich op het opslaan van loginformatie en het gebruik van deze informatie voor het genereren van compliancerapporten.

Grote spelers op de SIEM-markt zijn onder andere ([Gart10]):

  • ArcSight: ArcSight – onlangs overgenomen door HP – biedt één van de meest complete SIEM-voorzieningen.
  • RSA Envision: RSA Envision wordt geleverd door EMC en biedt een volledige SIEM-voorziening.
  • QRadar SIEM: QRadar SIEM wordt geleverd door Q1 labs en biedt een volledige SIEM-voorziening.
  • Symantec Security Information Manager (SSIM): wordt geleverd door Symantec en biedt een volledige SIEM-voorziening.
  • LogLogic: LogLogic levert losstaande SEM- en SIM-producten die samen een volledige SIEM-voorziening vormen.

SIEM: het bereiken van ‘tijdig inzicht’ over het gehele IT-landschap

Hoe kan een SIEM-voorziening helpen de wensen over ‘tijdig inzicht’ in te vullen? De kracht van een SIEM-voorziening zit er met name in dat zij organisaties in staat stelt loginformatie uit het gehele IT-landschap te verzamelen en te analyseren op beveiligingsgebeurtenissen, configuratieafwijkingen en kwetsbaarheden. Dit levert een totaalbeeld op van de beveiligingsstatus van het IT-landschap.

Het IT-landschap kan grofweg worden onderverdeeld in vier verschillende lagen:

  • applicaties, bijvoorbeeld ERP-programma’s zoals SAP;
  • besturingssystemen, bijvoorbeeld Windows-, Linux- en Unix-varianten;
  • middleware en databases, bijvoorbeeld webservers, Oracle en MS SQL;
  • netwerk, bijvoorbeeld firewalls en intrusion detection systemen.

C-2011-2-Boer-02

Figuur 2. Positionering van de SIEM-voorziening binnen een applicatielandschap.

Op elk van de vier lagen kan onderscheid worden gemaakt tussen ongewenste gebeurtenissen, afwijkingen van configuratiestandaarden en kwetsbaarheden.

De grote hoeveelheid loginformatie waarmee de SIEM-voorziening wordt gevoed, vertegenwoordigt niet alleen relevante beveiligingsgebeurtenissen. Een groot deel van de gelogde activiteiten bestaat uit toegestane gebeurtenissen of gebeurtenissen die opzichzelfstaand geen incident vertegenwoordigen. Een typisch voorbeeld is het vastleggen van foutieve inlogpogingen. Wanneer de foutieve inlogpoging zich slechts eenmaal voordoet is dit geen incident. Wanneer binnen korte tijd tien of meer foutieve inlogpogingen van dezelfde gebruiker zijn gedetecteerd, is er mogelijk wel sprake van een incident (wellicht probeert een onbevoegd persoon het wachtwoord te raden). In het hiervoor genoemde voorbeeld zal de SIEM-voorziening slechts één melding weergeven; tien foutieve inlogpogingen door gebruiker ‘x’ op systeem ‘y’. Dit samenvoegen van vergelijkbare gebeurtenissen tot één gebeurtenis wordt aggregeren genoemd.

Het zojuist beschreven voorbeeld gaat nog steeds uit van loginformatie van één bronsysteem. De ware kracht van een SIEM-voorziening zit in het combineren van loginformatie uit verschillende bronsystemen. Stel dat tijdens een scan een kwetsbaarheid is gevonden op de e-mailserver (beveiligingsmelding 1), dat een IDS een bekende aanval detecteert op de e-mailserver (beveiligingsmelding 2) en dat daarna e-mails van diverse accounts worden doorgestuurd (beveiligingsmelding 3). De drie verschillende beveiligingsmeldingen zijn afkomstig uit verschillende systemen, maar zijn allemaal gerelateerd aan een succesvolle aanval. Het combineren van voornoemde beveiligingsinformatie afkomstig uit loginformatie van verschillende bronsystemen wordt correleren genoemd.

Tabel 1 geeft een overzicht van organisatierisico’s met daarbij een mogelijke monitoringregel die dit risico kan beperken. Daarnaast zijn de IT-lagen opgenomen die informatie moeten aanleveren aan de SIEM-voorziening om een juiste analyse te kunnen maken. De monitoringregels kunnen gericht zijn op één laag of systeem uit het IT-landschap, maar ook op een combinatie van lagen en systemen.

C-2011-2-Boer-t01

Tabel 1. Overzicht met enkele mogelijke organisatierisico’s en hoe SIEM deze helpt te beperken.[Klik hier voor grotere afbeelding]

Voorgaande beschrijving en tabel tonen al aan dat een SIEM-voorziening de loginformatie uit verschillende bronsystemen analyseert en filtert. Een goede filtering bevordert dat er weinig irrelevante meldingen (valse positieven) zijn, wat een te grote werklast zou betekenen voor de analisten van de SIEM-voorziening. Tegelijkertijd wil men ook geen relevante beveiligingsmeldingen (‘valse negatieven’) missen.

Het voorbeeld in het kader illustreert hoe een monitoringsysteem gericht op een specifieke component uit het IT-landschap, gebruikt kan worden binnen een SIEM-implementatie.

Een SIEM-voorziening verschaft organisaties meer inzicht in de risico’s van het steeds complexer wordende IT-landschap, maar een volwaardige SIEM-voorziening kan meer. SIEM-voorzieningen stellen organisaties in staat op elk gewenst moment analyses uit te voeren op de grote hoeveelheid verzamelde loginformatie. De meeste SIEM-voorzieningen hebben standaardrapportages gedefinieerd die voldoen aan de informatievereisten vanuit SOx of PCI DSS. Deze informatie stelt de organisatie en de auditor in staat zich niet alleen een tijdiger, maar ook een vollediger beeld te vormen van de compliancestatus van het IT-landschap van de organisatie.

Het monitoren van databases binnen de ‘middleware en database’-laag

Veel applicaties slaan hun gegevens op in databases. Het is daarom niet vreemd dat tot 92 procent van de gelekte data afkomstig is van databases ([Veri10]).

Aangezien databases veel gebruikt worden binnen organisaties, is het (handmatig) monitoren van elke individuele database lastig en tijdrovend. Om deze uitdaging te verhelpen zijn er databasemonitoringsystemen op de markt. Deze systemen bieden SIEM-functionaliteit, maar dan specifiek voor databases. Databasemonitoringsystemen stellen organisaties in staat centraal log- en monitoringregels vast te stellen die voor alle gekoppelde databases gelden.

Om deze centrale log- en monitoringregels te kunnen valideren, zal een koppeling moeten worden gemaakt met elke database. Dit is mogelijk door het installeren van een softwarekoppeling en het aanmaken van een account op de databaseserver. Het databasemonitoringsysteem controleert aan de hand van de ingestelde regels op onjuiste configuraties en op activiteiten die mogelijk ongeautoriseerd zijn.

Bij koppeling met een SIEM-voorziening kan ervoor gekozen worden alle informatie uit het databasemonitoringsysteem beschikbaar te stellen aan de SIEM-voorziening, of slechts een relevant deel daarvan. Voor beide mogelijkheden zijn valide argumenten te geven. Wanneer alle database-informatie doorgestuurd wordt naar de SIEM-voorziening, dan wordt deze mogelijk overbelast. Mogelijke gevolgen zijn traagheid en ontoereikende opslagruimte.

Wanneer slechts het relevante deel naar een SIEM-voorziening wordt gevoerd, worden mogelijk relevante gebeurtenissen gemist. Immers, wanneer de SIEM-voorziening bepaalde data niet ontvangt, kan zij deze ook niet analyseren en correleren. Het is daarom van belang om tijdens het ontwerp en de inrichting van de SIEM-voorziening een informatieanalyse uit te voeren, die ingaat op dit soort aspecten. Dit voorkomt het achteraf moeten doorvoeren van (kostbare) wijzigingen.

Welke leerervaringen kennen we uit de praktijk?

De recente geschiedenis leert dat IT-implementatietrajecten een vrij hoge faalkans kennen ([Else08]). SIEM-implementaties kennen een sterke technische component: een SIEM-voorziening moet immers gekoppeld worden aan een diversiteit van systemen. Toch is de technische component niet de grootste uitdaging voor een succesvolle implementatie. Waarop moeten bedrijven dan anticiperen om tot succesvolle SIEM-implementatie te komen?

Vijf belangrijke succesfactoren voor een SIEM-implementatie zijn ‘focus’, ‘analyseprocessen voor beveiligingsmeldingen’, ‘organisatie’, ‘fasering’ en ‘onderhoud’.

Hieronder gaan we in op deze succesfactoren.

Focus

Alle beschikbare loginformatie voor analyse naar de SIEM-voorziening sturen, kan verleidelijk zijn. Echter, dit stelt niet alleen hoge eisen aan het systeem, ook is de kans groot dat dit een enorme hoeveelheid beveiligingsmeldingen oplevert. Deze hoeveelheid beveiligingsmeldingen kan de analisten overspoelen. Als gevolg daarvan onderzoeken de analisten mogelijk willekeurige meldingen in plaats van alleen de belangrijke meldingen. Het is daarom essentieel focus aan te brengen. Het gebruik van onderstaande doelen kan helpen focus aan te brengen in de gewenste informatie:

  • Compliance. Welke informatie wil de organisatie inzichtelijk hebben om aantoonbaar te voldoen aan de interne compliancevereisten, maar ook aan de extern opgelegde compliancevereisten vanuit bijvoorbeeld SOx, PCI DSS (voor creditcardgegevens) of HIPAA (voor medische gegevens)?
  • Risicobeheer. In welke beveiligingsinformatie is de organisatie geïnteresseerd om zowel interne als externe dreigingen en fraude te identificeren? Enkele voorbeelden zijn het saboteren van systemen, het lekken van (gevoelige) informatie, een Denial of Service-aanval of het aanmaken van nieuwe gebruikers met gevoelige autorisaties.
  • Netwerkbeheer. Monitoring van de beschikbaarheid en belasting van kritieke systemen ter voorkoming van een beschikbaarheidsincident.

Naast het in kaart brengen van de gewenste informatie, dient bepaald te worden welke systemen te monitoren. Een aanpak die vaak goed werkt is om eerst te bepalen welke gebeurtenissen het hoogste organisatierisico opleveren (bijvoorbeeld de top 20 van organisatierisico’s). Vervolgens kan bepaald worden welke systemen hier een rol in spelen. Dit zijn systemen met een hoog risicoprofiel, waardoor het nuttig is om deze systemen aan te sluiten op de SIEM-voorziening. Zo kan de SIEM-voorziening het risicoprofiel van een organisatie concreet helpen verlagen.

Ook compliancevereisten kunnen de focus bepalen. Bij een dergelijke focus ligt de nadruk op de bewaking van systemen die vanuit wet- en regelgeving speciale aandacht vragen. Zo is PCI DSS-compliance-informatie alleen relevant voor systemen die creditcardgegevens verwerken en zijn SOx-vereisten alleen relevant voor systemen die belangrijk zijn voor de jaarrekeningcontrole.

Analyse van de beveiligingsmeldingen

Een SIEM-voorziening kent een sterke procescomponent. Dit betreft met name de analyse en afhandeling van beveiligingsmeldingen. Voor de introductie van een SIEM-product zullen deze processen vormgegeven moeten worden. Veelal vereisen de diverse typen beveiligingsmeldingen verschillende afhandelprocessen. De analyse en vervolgstappen bij een serie ongeautoriseerde handelingen zullen anders zijn dan bij een foutieve configuratie. Voor elk van de processen dient te worden bepaald wie verantwoordelijk is voor de verschillende (sub)stappen. Als onderdeel hiervan dient een escalatieprocedure te worden ingericht. Het vaststellen van verantwoordelijkheden en escalatieprocedures is extra belangrijk wanneer derde partijen ook IT-diensten leveren.

Veel organisaties die een SIEM-voorziening implementeren, stappen over van een meer reactieve manier van reageren op beveiligings- of compliance-incidenten naar de proactieve vorm. Deze overstap kan bijvoorbeeld ingegeven zijn door auditbevindingen of recente beveiligingsmeldingen. De kans is dan groot dat er niet alleen nieuwe processen moeten worden opgesteld voor het analyseren van beveiligingsincidenten, maar dat ook huidige incidentmanagementprocessen moeten worden aangepast. De proactieve aanpak van SIEM zal immers meer input voor de bestaande IT-beheerprocessen genereren, aangezien op basis van de beveiligingsmeldingen corrigerende maatregelen getroffen zullen worden.

Organisatie

Gerelateerd aan de voorgaande stap is een derde belangrijk aspect het vormgeven van een opvolgingsteam dat de beveiligingsmeldingen zal gaan verwerken. Binnen veel grotere organisaties is al een afdeling rondom beveiliging ingericht. Mogelijk kan het opvolgingsteam binnen deze afdeling worden ingepast. Dit heeft als voordeel dat weinig wijzigingen noodzakelijk zijn op organisatorisch vlak.

Vaak blijkt dat deze afdeling rondom beveiliging meer met beleid en controle bezig is dan met operationaliteit. Deze afdeling zal daardoor geen beveiligingsmeldingen van de SIEM-voorziening onderzoeken. Dit wetende kunnen verschillende oplossingsrichtingen worden gekozen.

Ten eerste kan worden gekozen voor een compact intern opvolgingsteam, of een wat uitgebreidere inrichting in de vorm van een Security Operations Centre (SOC), een extern opvolgingsteam. Daarnaast kan gebruik worden gemaakt van een SOC van een grote IT-dienstverlener waarvan al een dienst wordt afgenomen. Door voor deze weg te kiezen kan op de kosten bespaard worden en daarnaast zijn vaak verschillende soorten serviceniveaus mogelijk waarmee beter afgestemd kan worden op de specifieke behoeften. Nadeel is het risico van belangenverstrengeling wanneer beveiligingsmeldingen worden veroorzaakt door de IT-dienstverlener zelf. Een derde mogelijkheid is daarom om een onafhankelijke externe leverancier in te huren. Nadeel hiervan is dat vertrouwelijke gegevens zullen worden verstuurd aan een extra externe partij. Hierover zullen dus aanvullende afspraken moeten worden gemaakt en op de naleving hiervan zal moeten worden toegezien.

Belangrijke randvoorwaarde is in ieder geval dat goede contractuele afspraken worden gemaakt. Hierin moeten in ieder geval afspraken worden gemaakt over beschikbaarheid, reactiesnelheid (ook buiten kantooruren), de rapportagelijnen, het mandaat en hoe de mankracht het meest adequaat ingezet kan worden.

De introductie van een SIEM-voorziening zal meer beveiligingsmeldingen opleveren die allemaal moeten worden geanalyseerd en waarvan een groot deel opvolging vereist. De implementatie van een SIEM-voorziening zal dus ook invloed hebben op bestaande IT-afdelingen binnen de organisatie.

Fasering

Zoals hierboven geschetst, kennen SIEM-implementatietrajecten een sterke IT-component, maar ook een sterke organisatie- en procescomponent. Dit maakt dergelijke trajecten tot een interessante uitdaging. Een goede manier om hiermee om te gaan is het opstellen van een gefaseerd implementatieplan.

Aandachtspunten bij deze fasering zijn om op relatief korte termijn de toegevoegde waarde van SIEM aan te kunnen tonen, terwijl het traject tegelijkertijd beheersbaar blijft. Een goede aanpak maakt gebruik van de vastgestelde focus. De implementatie kan beginnen met een beperkt aantal doelsystemen en activiteiten die een groot deel van het risicoprofiel van een organisatie vormen. Deze aanpak omvat de organisatie, techniek en processen. Hierdoor worden op deze vlakken parallel verbeteringen doorgevoerd en is de toegevoegde waarde van de SIEM-voorziening snel zichtbaar.

Het is goed om tijdens de implementatie rekening te houden met bekende valkuilen. Zo zal geen enkele SIEM-voorziening exact alle regels kunnen configureren waar een organisatie behoefte aan heeft. Dit heeft te maken met zowel technische beperkingen als het ontbreken van logginginformatie op het juiste detailniveau. Daarnaast zullen veel (risicovolle) handelingen op het IT-landschap zijn toegestaan, maar hoe kan de SIEM-voorziening geautomatiseerd vaststellen of een risicovolle handeling is toegestaan?

De in de SIEM-voorziening geconfigureerde regel zal lang niet altijd de doelstelling van deze regel geheel afdekken. Dit kan zowel valse positieve meldingen opleveren, als valse negatieve meldingen. Een valse positieve melding krijg je als een regel te soepel is gedefinieerd. De SIEM-voorziening genereert daardoor meer meldingen dan nodig is. Die meldingen moeten in principe allemaal onderzocht worden. Een valse negatieve melding is een melding die ten onrechte niet wordt gegenereerd omdat een regel te strak is gedefinieerd.

Het is zaak het aantal meldingen te stabiliseren tot een acceptabel niveau alvorens de functionaliteit uit te breiden of nieuwe systemen aan te sluiten. Dit voorkomt dat de organisatie overstelpt wordt met beveiligingsmeldingen. Aan de andere kant voorkomt deze aanpak het bieden van schijnveiligheid.

Onderhoud

De wereld is continu in beweging en daarmee verandert het risicoprofiel waarmee organisaties te maken hebben. Tevens kan de risicotolerantie van organisaties veranderen. Daarom is het van belang periodiek te evalueren of de SIEM-voorziening aanpassing behoeft. Tijdens de evaluatie kan aan bod komen of:

  • de organisatierisico’s zijn veranderd;
  • de doelstelling van de SIEM-voorziening moet veranderen (bijvoorbeeld aanvullende aandacht voor beveiligingsincidenten ten opzichte van compliance);
  • de relatie tussen de doelstelling en de bewaakte IT-middelen juist is;
  • de diepgang van de bewaking juist is;
  • de bewaakte systemen zijn aangepast, vervangen of worden uitgefaseerd en daarmee of de aggregatie en correlatie van logging nog adequaat verloopt;
  • de beveiligingsmeldingen en rapportages nog voldoen aan de doelstellingen en wensen;
  • aan de organisatie- of proceskant wijzigingen moeten worden doorgevoerd om te waarborgen dat aan de kwaliteitseisen die van toepassing zijn op de SIEM-voorziening voldaan wordt;
  • de bescherming van het SIEM-product zelf nog adequaat is, zodat hierin geen beveiligingslekken ontstaan. Dit betreft zowel het doorvoeren van patches als het controleren of de logische toegangsbeveiliging adequaat is ingericht.

Deze periodieke evaluatie waarborgt dat de effectiviteit van de SIEM-voorziening niet wegebt in de loop der tijd.

Conclusie

De ontwikkelingen rondom beveiligingsoplossingen zoals SIEM gaan in rap tempo. Dit is mede ingegeven door een sterke managementbehoefte aan een tijdig inzicht in het risicoprofiel van het IT-landschap en aan snelheid van handelen bij incidenten. Hierdoor kunnen SIEM-systemen zich verheugen in een toenemende aandacht van organisaties. Interessant hierbij is dat SIEM-voorzieningen in grote mate kunnen worden aangepast naar de focus die een organisatie heeft. Dit kan resulteren in kleinschalige SIEM-voorzieningen, maar ook in SIEM-voorzieningen die hun nut bewijzen als onderdeel van brede beveiligingsprogramma’s.

Echter, het implementeren van een SIEM-voorziening is niet eenvoudig. Dit is mede te verklaren doordat een dergelijke voorziening raakt aan de organisatie, beveiligingsprocessen, IT-beheerprocessen en natuurlijk aan techniek. Dit vraagt om een gebalanceerde en weloverwogen implementatieaanpak. Het is daarom van belang om de leerervaringen uit de praktijk in acht te nemen. Dit stelt organisaties in staat SIEM-voorzieningen goed in te passen in hun initiatieven ten aanzien van risicobeheer en de krachtige mogelijkheden van SIEM volledig te benutten.

Literatuur

[Else08] Elsevier, ‘Geen Rolls-Royces meer’, 13 september 2008.

[Gart10] Gartner, Magic Quadrant for Security Information and Event Management, May 2010.

[KPMG10] KPMG, Data Loss Barometer, november 2010, http://www.datalossbarometer.com.

[McAf11] McAfee Foundstone Professional Services and McAfee Labs, Global Energy Cyberattacks: Night Dragon, 10 February 2011.

[Veri10] Verizon Risk Team in cooperation with the United States Secret Service, 2010 Data Breach Investigations Report, 2010.

Establishing a Tax Control Framework: The utility and necessity of IT

The Dutch Tax Administration has developed a new approach to supervise tax paying organizations. It is called “horizontal supervision.” A vital element in this approach is the “Tax Control Framework.” This article will clarify why it is not only helpful but necessary to apply IT and ERP-systems when setting up a TCF.

Preamble

Prompted by the economic crisis, the interest in risk management has grown substantially. Traditionally, tax risks were not high on the agenda in the area of risk management. But times are changing.

The growing attention to tax by legal bodies and investors is primarily caused by the material impact tax has on the financial position of companies. Stakeholders, like investors, the Tax Administration and other supervising bodies, are asking for a new approach to coping with tax issues. What is at stake is more than complying with tax laws and regulations. Transparency, insight into fiscal risks and adequately controlling these risks are becoming more and more important. Apart from better understanding and controlling tax risks, this will enable companies to benefit from tax opportunities.

Besides the fact that companies are “in control” of their tax issues, it is important that this can be demonstrated to stakeholders, like the Audit Committee, the management and the tax authorities.

Among global tax authorities a similar trend is apparent. They are leaving the path of performing elaborate tax audits as in past years and are increasingly turning to current tax issues, control processes, tax strategies and tax risk management. This approach is shared and promoted by the Organization for Economic Cooperation and Development (OECD) ([OECD08]).

Tax authorities in many countries are refocusing their attention to developing similar initiatives:

  • US Compliance Assurance Program
  • Ireland Cooperative Approach to Tax Compliance
  • UK Compliance Risk Management
  • Australia Forward Compliance Arrangement
  • South Africa Enhanced Relationship Program
  • South Korea Horizontal Compliance for Corporations
  • China Large Business Taxation Department

In the following paragraphs, the concepts “horizontal supervision,” “compliance agreement” and “tax control framework” are explained in more detail. These concepts are the result of the increased attention to tax risks.

Horizontal supervision and compliance agreement

The Dutch Tax Administration describes the following in an announcement regarding horizontal supervision:

“Investigations in the past fiscal year were unsatisfactory for companies, but also for the Tax Administration whose objective is to deal with current tax issues. Sometimes, extreme positions were taken by the parties involved. There was little trust between the parties and little information was shared. Resolving a disagreement led to long delays and high costs for both sides. That did not contribute to enhancing compliance, which was one of the main objectives of the Tax Administration. In order to achieve the objective of enhanced compliance, the Tax Administration introduced horizontal supervision.”

In short, “horizontal supervision” means that the company and the Tax Administration approach each other differently. Trust, transparency and mutual respect are key. Horizontal supervision is in line with developments in the area of corporate governance.

The compliance agreement is the ultimate form of horizontal supervision. In such an agreement specifications are made about the way both parties will cooperate. If a company wants to apply for a compliance agreement, the Tax Administration expects that an adequate TCF is in place or that serious steps are being taken in order to implement a TCF within a reasonable time frame.

Because of horizontal supervision, the focus on a TCF has increased significantly. Often it is assumed that a TCF is a result of horizontal supervision. This is not true. Even companies that do not have a compliance agreement would benefit from implementing a TCF. Not because it is a recommendation from the tax authorities, but because they themselves believe that being in control of tax is essential for good business operations.

Tax control framework (TCF)

A TCF is a set of processes and internal control procedures (hereinafter referred to as “Controls”) ensuring that a company’s tax risks are known and controlled. A TCF is an important means to manage an organization’s overall tax matters.

In principle, it includes all the taxes applying to an organization: for example corporation tax, payroll tax, sales tax and excise duty. However, regulatory energy tax, gambling tax, environmental taxes, container taxes, car taxes, airfare taxes etc. should, where appropriate, also be incorporated into a TCF. The complete, accurate and timely submission of tax returns and payment of assessments also falls within the scope of a TCF.

The above-mentioned types of taxation have interfaces with almost all business processes. Closing a transaction and issuing an invoice, elements of the primary business processes, may impact upon corporation tax, sales tax and excise levies. A TCF is therefore an integral part of an overarching business control framework (BCF).

Because the audit approach of tax authorities is largely determined by the manner in which a company controls its tax and other processes, tax authorities must evaluate the design, implementation and effectiveness of the TCF. In the Netherlands, the Tax Administration has not imposed any minimum requirements on TCFs, but offers guidance for the creation of a good TCF. It has identified the COSO model as a logical starting point, since it is the international standard for setting up an internal control system and is already used by many companies for the creation of a BCF.

A TCF enables a company to achieve its operational and financial tax goals and to implement its tax strategy in a manageable and controllable manner. A TCF helps a company communicate clearly about tax issues with all its external and internal stakeholders.

Benefits of a TCF

A TCF should lead to fully functioning tax procedures. This has several advantages:

  • Work is up to date
  • Certainty about tax position (no more “surprises”)
  • Image improvement, increased stakeholder confidence
  • Efficient and effective control system for taxation
    • Improved quality of tax data
    • Faster reporting of tax
    • Better understanding of the tax situation, providing more insight into tax options
  • Fewer corrections during tax audits and lower audit costs

Additionally, a TCF is useful for much more than concluding a compliance agreement. While a compliance agreement is concluded with tax authorities and has national scope, a TCF can also be used internationally (as an integral part of a BCF), bringing all of an organization’s tax concerns “under control.”

Developing a TCF

The previous section described how a TCF covers all of an organization’s tax issues and how most business processes, often supported by different IT systems, have a direct impact on taxation. IT systems incorporate many control procedures designed to mitigate risks. The role of IT (and thus the involvement of IT consultants and auditors) is also essential in a TCF.

Designing, implementing and maintaining a TCF may involve the following phases. The role of IT is indicated for each phase.

C-2011-0-Peters-t01

Figure 1: TCF method

Phase 1: Planning

The aims and scope of a TCF are established in Phase 1. This involves such issues as the purpose for which the organization wants to use the TCF, the type(s) of tax on which the organization wants to place the primary focus, the decision to only use the TCF for one or more countries, etc. Another important concern is the establishment of a project team and formulation of the terms for controlling the TCF project (including project management and obtaining of resources). It is wise to first run a limited pilot. No specific IT activities are performed at this stage.

Phase 2: Insight

In Phase 2, a large number of cases are identified as a “baseline.” Not entirely voluntarily, we identify the tax strategy, the legal and tax structure, the main products/services and markets, the tax organization, tasks and responsibilities relating to taxes, the main types of taxes, the relevant business processes, IT systems (including authentication mechanisms) and other registries. This broad approach to the organization is required to identify where and how taxation affects the processes in the organization, so that a thorough tax risk analysis can be performed. It is also necessary to determine whether and, if so, to what extent these risks are covered by (automated) Controls.

Since “soft controls” have a major impact on the proper working of “hard controls,” they are also addressed. Examples are “tone at the top,” the motivation and training of employees, corporate culture, the presence of a code of conduct, compensation structure, leadership style, values and tax awareness. Tax authorities usually consider soft controls when assessing the TCF process in connection with the possible conclusion of a compliance agreement.

Eventually, the work in this phase finishes by identifying and describing internal Control deficiencies and prioritizing the next steps in the project to eliminate these defects.

IT has an active role at this stage in the analysis of processes and IT systems. When performing a risk analysis, it could be useful to have an IT auditor or consultant contribute his or her extensive experience.

Phase 3: Design

The design phase focuses on the (re)design of Control procedures. The performance of this task is of course linked to already existing procedures. Where possible, the procedures will be placed in the IT environment, mostly because automated Controls are more efficient and more effective than manual ones. This especially applies to procedures targeting risks in routine processes. For non-routine processes, such as mergers, acquisitions, IPOs or refinancing, an organizational, procedural approach is the more obvious route to take.

IT has an active role in identifying and determining existing and future Controls in tax-relevant IT systems.

Phase 4: Implementation

New and/or modified Control procedures are implemented in this phase, but not before agreeing on priorities in consultation with management and setting a schedule for improvement. “Key Controls” and obvious “control gaps” are first addressed, enabling an initial effort to generate major progress. Communication with all the employees and departments is crucial in this phase. If necessary, employees must be informed, instructed and/or trained. It goes without saying that the role of IT in this phase is also important for the successful implementation of an effective TCF.

Phase 5: Monitoring

Assessing the design, implementation and effectiveness of the Control procedures put in place for the TCF is essentially no different from assessing the implementation and effectiveness of other Controls that are part of the BCF. Wherever possible, this testing is incorporated into the management control processes (self assessment), the audit plan of the internal audit department and/or included in the audit of the external auditor.

While the implementation and effectiveness can, to a large extent, be assessed by direct observation, the repetition of procedures, procedural testing, line checks, etc., great importance is also attached to performing substantive file analysis and (mathematical) sampling of various elements. This enables critical items to be identified and monitored in an efficient manner. Tax authorities are familiar with these methodologies and will appreciate their value. IT will also play an important role in this phase.

The issue of materiality is relevant at this point. The standard of materiality employed by tax authorities is normally much lower than the one used on financial statements. However, the Netherlands Tax Administration notes in this regard that, in “low” level business processes, materiality hardly plays a role; control measures are not designed to ensure that only material items are subject to control. The low materiality standards of tax authorities seem reasonable considering the effectiveness of internal control procedures. The quantity of substantive (monitoring) activities to be performed is then greatly reduced, because a large part can be based on existing internal control procedures.

The findings arising from testing the implementation and effectiveness of a TCF together with changes in internal and external environments form the basis for continuous adjustments and improvements to the TCF.

Integration of a TCF and a BCF into a single platform

In its memorandum, the Netherlands Tax Administration states that a TCF should be regarded as part of a business control framework (BCF). Many companies have been experimenting with a BCF in response to regulations such as the Tabaksblatt Code and Sarbanes Oxley.

In practice, companies are still clearly finding it difficult to comply with such regulations and to demonstrate their compliance. An integrated BCF is set up to reduce the pressure to perform “testing” and “monitoring” activities to a degree that is acceptable to the business and, ultimately, to provide a “single view of risk” ([KPMG08]). This integrated BCF (Figure 2) will include all the Controls required to comply with relevant laws and regulations. In this way, Controls defined for different purposes are effectively and efficiently implemented.

C-2011-0-Peters-01

Figure 2: Integrated approach to TCF and BCF ([KPMG08])

Support by automated tools

A fully integrated BCF is often a complex whole, and an automated tool to monitor Controls may provide a means of handling the complexity. There are many software applications available on the market that deal with governance, risk and compliance. Specific TCF tooling is becoming more widespread.

KPMG Meijburg & Co. has worked with a risk management software company to develop an application that enables a TCF to be completely set up and managed (in-house management by the organization) and to be fully integrated with or expanded by new or existing risk management applications. This application is based on COSO and contains sample risks and Controls for virtually all tax resources. It furthermore responds to the requirements and demands of many clients as well as building on extensive practical experience. Figure 3 provides an overview of the tax risk management section of the application. Figure 4 shows one of its reporting capabilities, in which the “In Control” status is displayed for each entity, tax type and process.

C-2011-0-Peters-02

Figure 3: Tax Risk Management Section

C-2011-0-Peters-03

Figure 4: Reporting Section

The role of ERP systems

In recent years, companies have acquired a great deal of experience in setting up BCFs and, in many cases, bringing them to maturity. By this, we mean that the Controls in the initial BCF, which are primarily manual, are further developed to the point of being automated and becoming therefore often more efficient. A TCF can be immediately integrated into this development without having to go through the learning curve again.

It could be argued that tax controls are divisible into those that ensure the quality of the reporting processes and those that are incorporated into primary business processes and provide the input for the reporting process (see Figure 5). The latter mainly comprise procedures for providing assurance about the accuracy and completeness of this input. For instance, controls may be established to ensure that a VAT declaration is submitted on time to the authorities in various countries and with adequate checks and balances. In this case, the Controls pertain to the reporting process. In business processes, it is possible to guarantee, while considering the probability of error, that VAT codes can never be entered on sales orders manually but are always automatically defined by the system and based on decisive rules. As a result, the accuracy and completeness of the input for the VAT return is ensured by the decision logic. Figure 6 contains several examples of similar VAT risks and their corresponding application Controls.

In most modern ERP systems, the development of this logic is a matter of parameterization and master data management. Assessing the quality of the decision logic in this case is an important control. Testing or data analysis should first be used to establish that the decision logic is functioning properly and can be relied on. To do this, it will be necessary to determine if the change management process in an ERP Competence Center is of sufficient quality for the ERP system in general and the decision logic in particular. A particular concern here is that, when analyzing the impact of a change request, sufficient attention is given to the consequences of the change on tax compliance. In this respect, there is nothing new under the sun. This principle has been long known insofar as it applies to BCFs.

C-2011-0-Peters-04

Figure 5: Scope of tax controls

C-2011-0-Peters-t02

Figure 6: Examples of specific SAP VAT risks and application controls ([Zege07])

Useful tips for successful establishment of a TCF

The authors have extensive practical experience in designing, implementing, maintaining and optimizing business control frameworks and tax control frameworks.

For successful implementation of a TCF (or BCF), they would therefore like to offer you the following practical tips:

  • Dynamic: A TCF must be dynamic – not a snapshot but a film! A TCF goes beyond a quick scan of tax risks and internal Controls. The company tax department should know what is happening within the organization and be involved in it. No cabinet full of paper checklists will suffice.
  • Start small: The trick is to set up a workable and manageable TCF. Limits are necessary. It can always be expanded later. Start with 1 tax type, 1 division and a limited amount of risk. Provide support within the organization.
  • Integration: Contrary to popular belief, a TCF is certainly not just used by tax departments, but also by other staff and departments, such as risk managers, controllers, internal audit and IT. It is absolutely necessary to work with these departments in order to achieve a good and workable TCF as a component of the company’s overall risk management.
  • Platform: Provide an integrated platform for tax and other risk management. Our experience indicates that an organization generally develops a great many Controls for business control frameworks that are not thought to belong to a TCF and that are solidified into a number of procedures. An integrated platform makes everything dynamic. It is important to ensure integration with a business control framework.
  • Automated tools: A fully integrated BCF is often a complex whole. An automated tool to monitor Controls may provide a means of handling the complexity.
  • Structure: A structured and codified approach ensures that a TCF focuses on key risks and processes.
  • Communication: Organizations usually have everything under control. What is difficult is to show that this degree of control exists. This requires communication with other departments, internal and external auditors, directors, tax authorities and supervisors. In our view, a clear TCF with structured overviews and reports is essential for this communication.

We would also like to emphasize one final time that, although the attention given TCFs has certainly been strengthened by horizontal monitoring, controlling all of a company’s tax matters is essential for good business. A TCF should not therefore be limited to taxation in the Netherlands. Application to all national and international tax considerations will not only enable an organization to better manage its tax risks but also to gain greater insight into the possibilities of profiting from tax opportunities.

Literatuur

[Bela08] Tax Control Framework; Van risicogericht naar “in control”: het werk verandert, Belastingdienst, March 2008.

[KPMG08] KPMG, Governance, Risk, and Compliance: Driving value through controls monitoring, KPMG Advisory, 2008.

[KPMG09] KPMG, Total TAX Control, Tax Accounting & Control Services, KPMG Meijburg & Co, 2009.

[OECD08] Organization of Economic Cooperation and Development, Study into the Role of Tax Intermediaries, Fourth OECD Forum on Tax Administration, Cape Town, South Africa, January 2008.

[Zege07] A.T.M. Zegers, Omzetbelastingwetgeving en ERP systemen – een overbrugbare kloof?, Master’s Thesis, Eindhoven University of Technology, The Netherlands, 2007.

Successful Governance, Risk and Compliance within reach

In recent years, businesses have clearly been developing initiatives to promote cooperation among, and even integration of, the organizational units charged with the tasks of risk management, internal control, compliance and auditing. These initiatives are often born from the desire and need to establish more transparent and efficient activities related to governance, risk and compliance. Moreover, the legislative and regulatory pressure is increasing, and companies are looking to efficiently and effectively meet the requirements of regulatory and other “control frameworks.” Yet not all companies manage to create effective and efficient collaboration between their various divisions. An integrated approach to Governance, Risk and Compliance (GRC) is the solution to this difficulty. This article will provide insight into the manner in which a successful GRC implementation might proceed by discussing the approach, requirements and potential pitfalls. Understanding these issues increases the success rate of GRC, thereby bringing effective, efficient and transparent cooperation and/or integration within reach.

Introduction

Internal control is an issue that applies to every company, and each company approaches the issue in its own way. Over the course of many years, a wide array of function-based units and divisions have been created within companies to deal with various aspects of the control process: internal control, inspection, (operational) risk management, business continuity management, information security, compliance, legal, IT, planning and control and internal audit. All these sub-domains play an important role, but each is limited to its own area with its own specific characteristics. Companies have now learned that this multiplicity of functions and departments is not effective enough, and it is also inefficient. There is increasing pressure from the business community itself (particularly from executive and supervisory boards), including shareholders and regulators, for a clear understanding of the really important risks and their control, as well as for clear and transparent reporting. There is obvious interest in instigating better collaboration among the multitude of risk and “control” functions, or even integrating them entirely.

GRC stands for Governance, Risk & Compliance. On the market, GRC initiatives are also referred to as “risk convergence,” “integrated assurance,” “E-GRC” and “single view of risks.” These terms are simultaneously supported by a large number of (internal) control frameworks[Various frameworks for the internal control of organizations are currently in circulation, such as COSO-ERM, COCO, Cadbury, Cobit and ITIL.] and a great deal of GRC software, including SAP GRC, Thomson Reuters, OpenPages and BWise ([Gart09]). All have a common goal: they are meant to eliminate “silo thinking” and reduce currently existing redundancies among governance, risk and compliance activities by implementing a GRC framework, supported by an IT platform and a single application. Improved cooperation among, or complete integration of, the various organizational units responsible for risk management, internal control, audit and compliance is one of the successful outcomes of GRC. Companies that tend to have high legislative and regulatory requirements and a certain role in society experience a greater willingness or desire to bring about collaboration and/or integration. These companies are mostly active in the financial sector, “chemicals” or “energy and utilities.” But companies in other sectors are increasingly seeing the importance of integrated GRC, as it enables management to be demonstrably “in control” and creates improved and more transparent insight into the status of risk and control frameworks, while explicitly co-coordinating the tasks and responsibilities of the “silos.” The implementation of GRC software can also significantly improve the manner, speed and effectiveness of reporting.

An integrated “control framework” and implemented GRC software only gets you part way there. There are many initiatives that have been undertaken in practice, but these usually do not deliver the desired results over the long term. Different departments often feel too distinct to work together (people feel that laws and regulations, or various codes are best approached from their own area of expertise, on account of which cooperation, not to mention integration, only distracts from the main task at hand). In addition, many of these departments are anxious about discarding any carefully acquired expertise, tooling, methods, reporting structures or developed risk ratings.

Typically, there are various levels of an organization involved in the specifics regarding compliance with laws and regulations, internal control frameworks, risk management, executing internal controls, conducting audits and interpreting governance issues. There is also some discussion about the “three lines of defense” model. All the layers in this model (i.e. management, risk and control support services and internal audit) play a role in GRC, and this produces a certain amount of overlap, the characteristics of which will be further explained in this article. In addition, the realization of GRC discernibly and permanently reduces the work involved in the “three lines of defense” and thus makes them more efficient (see Figure 1). A far-reaching implementation of GRC principles shifts the distribution of the various roles of internal control from the second and third line to the first line (management), where most of them essentially belong. The weighting of the internal control activities is represented from left to right in Figure 1 as a function of the extent to which GRC is implemented, ranging from low realization of GRC (left) to high realization of GRC (right).

C-2011-0-Beugelaar-01

Figure 1: Distribution of roles involved in the “three lines of defense” in relation to greater GRC commitment

A number of factors affect the successful deployment of GRC within organizations. This article will furnish answers to the following questions:

  • What is the importance of successful GRC? Why should organizations strive to integrate GRC?
  • What are the steps that an organization should take in a successful roll-out of GRC?
  • What are the advantages of integrated GRC?
  • What are the conditions that make for a successful roll-out of integrated GRC?

The importance of successful GRC

Proliferation

There are many reasons why organizations are desperately seeking an effective and efficient structuring of the entire control framework around governance, risk and compliance. However, the importance of successful GRC can only be properly appreciated by examining why these organizations have, in principle, allowed multiple control functions to proliferate. After all, no organization deliberately chooses to perform activities that appear to be similar or overlap, result in loss of a clear and comprehensive picture (i.e. transparency) and are undertaken without understanding the total costs. The reasons for the proliferation are shown in Table 1.

C-2011-0-Beugelaar-t01

Table 1: Causes of proliferation

Importance

The problems identified above show how important a successful GRC initiative can be. According to AMR Research ([AMRR08]), the importance of successful GRC lies in the following drivers (listed in order of importance):

  • better risk management and control in the business
  • reduced total costs of GRC activities
  • automation of GRC activities and the continuous application of them
  • provision of internal and external transparency
  • risks and costs of non-compliance
  • creation of a defensible information environment

The problem is that these drivers are often insufficiently quantified. In fact, there is insufficient clarity about the current “cost of risk,” “cost of control” and “cost of compliance.” To clear this up, an inventory has to be made of all GRC-related costs incurred within an organization. We are not just talking about the costs of external and internal audits, but also about the costs of the first and second “lines of defense” and the costs of operational controls, including the costs expressed in hours spent on GRC activities. The latter often constitute hidden costs because they are incorporated in regular business processes. In addition, many of the control procedures are inadequately classified as “operational controls” and “monitoring controls” ([Klum09]), and there is a lack of insight regarding the extent to which controls are automated or performed manually. It also appears that many organizations are unclear about the amounts of time (and money) that are spent on corrective actions in response to detected shortcomings in performance. See Figure 2 on the components of control costs.

C-2011-0-Beugelaar-02

Figure 2: Control costs components

The integration of different “control frameworks” is often a good first step in remedying this lack of oversight, but it certainly does not go far enough.

The business case ([AMRR09]) for a successful implementation of GRC is certainly solid, but needs to be prepared. The challenge lies in determining the estimated benefits (or reduced costs). This can be expressed in terms of a number of factors such as:

  • reduction in the number of FTEs responsible for GRC tasks
  • increased productivity through a more efficient execution of GRC tasks, for example, by automating a number of “controls”
  • streamlining and optimizing business processes
  • joint performance of reviews and audits by various teams, thereby reducing redundancy
  • improved risk management and GRC reports (dashboards)
  • faster availability of management information through the use of GRC software and therefore improved transparency

The estimated benefits (or reduced costs) have a quantitative but also a qualitative character. Successful implementation of GRC also requires investment. Therefore it is important to formulate a sound business case, detailing an approach to successful GRC.

Toward a successful roll-out of GRC

A vision of integrated GRC

For a successful roll-out of GRC, it is important that organizations develop a corresponding GRC vision. This entails clearly identifying where the organization is currently positioned in terms of GRC and how it would like to grow (the target). This target may be approached from various points of view. A competitive advantage may be achieved by faster, sharper and better informed decisions. But the desire to be the first to have internal control demonstrably up and running may also be a target. It may also be desirable to have an integrated solution for all risk and control functions in situations where supervision is carried out by regulatory bodies or where rating agencies are constantly looking over your shoulder.

All of the above demonstrates that GRC is not just “joint” execution of certain operations. It is a fully integrated manner of thinking and working in accordance with an efficient and effective business model in which all GRC activities, ranging from strategy to final reporting and performance measurement, are unambiguous, subject to appropriate cooperation and coordinated with activities outside the GRC domain.

Figure 3 illustrates this integrated approach. GRC is accordingly defined as:

  • the integrated “framework” that, based on organizational goals, establishes
  • a link between the functions of “governance, ” “risk,” “control,” “compliance” and “assurance”
  • in order to implement a uniform, consistent and comprehensive approach to GRC
  • throughout the entire organization.

Within this approach, processes are based on a series of successive development, implementation and result components.

C-2011-0-Beugelaar-03

Figure 3: KPMG’s holistic GRC model

The mission, which encompasses the expectations of the organization’s stakeholders, will be translated into a strategy concerning “governance,” “risk,” “control,” “compliance” and “assurance” tasks, as well as the values and convictions to be shared. The business model for the GRC activities will be connected to the organization’s overall business model. The “value drivers” ultimately determine the success of the GRC activities, based on the organizational goals.

The “Governance, Organization and Infrastructure” category is also called “hard” governance. It unambiguously determines the management and supervisory structures for all the necessary approaches to risk and coordinates them with each other. For example, it leads banks to create an unambiguous structure for credit, market, liquidity and operational risk. Roles and responsibilities are determined and a strategic choice made concerning the use of (IT) systems and supporting applications for GRC activities and reporting. Suitable specific GRC software is available on the market.

“Culture and Behavior” is also called “soft” governance. Robust GRC works only when things like integrity, motivation, discipline, communication, responsibility, independence and transparency are fully embedded in the organization and its people. The corresponding culture and behavior must be rooted in the hearts and minds of employees. The importance of a clear and positive culture cannot be stressed too often. It is one of the most important conditions of successful GRC. Within this culture, issues are identified and disseminated, such as “tone at the top,” training, awareness sessions, compensation and incentive plans, “soft controls,” as well as open, honest and clear communication.

The “risk profile” is drawn up at least once a year by means of an “assessment” that is compiled using all the areas of expertise in the organization. This “assessment” therefore covers all fields of work in the culture. It will create a clear and comprehensive picture of the “risk universe” and an unambiguous assessment of risks connected to the mission and strategy of the business. A uniform risk measurement in each risk category is of crucial importance in the translation of the risk profile into follow-up activities, monitoring and reporting.

The “operational model” and “business processes” are the lifeblood of GRC. They are where operational activities take place. It is therefore important to manage risk in respect of activities such as procurement, sales, production, R & D, HR and accounting, while taking account of the established “risk profile.” This “heart” is where GRC activities occur and where the “control framework” for risk management is established. The regular GRC activities are varied: policy making; maintaining “risk and control frameworks”; recording and monitoring incidents, issues and “losses”; teaching management; conducting awareness programs; and implementing and accompanying approval processes for new products.

All monitoring, review and internal audit activities are brought together under “enterprise assurance,” where they are performed in a coordinated manner in order to secure the organization’s goals (as embodied in the mission and strategy and translated into tactical and operational objectives). This “enterprise assurance” can be formulated in a highly efficient and effective manner. The concept of “embedded testing” ([Klum09]), again emphasized by the COSO organization in its latest guideline on monitoring in COSO ERM ([COSO09]), produces an efficient design for the entire internal control and accountability structure. Its basic principle consists of attributing the task of monitoring the implemented operational controls to a level as close to management as possible. If this arrangement is effectively put in place and policy has been set, the review function (second “line of defense,” such as risk management and compliance) only has to have a supportive and evaluative role. Internal audit can then examine the proper design and operation of the “second line of defense.” When this “line” does its job well, you only have to use internal audits to determine if management is adequately performing its monitoring role and to run spot checks on the “operating effectiveness” of operational controls. Furthermore, automated methods of analysis and continuous monitoring / auditing can make important contributions to an efficient and effective system of internal control. In this respect, consideration should be given to software such as Idea, Approval, SAP GRC Process Controls and ACL. Based on predefined parameters, deviations in trends and bandwidths will give rise to further analysis. The “enterprise assurance” toolbox should also contain tools for capturing, tracking and monitoring issues, incidents and errors. Examples include GRC software like BWise, OpenPages, Thomson Reuters, Axentis and Qumas ([Forr07]).

If everything is properly supplied and operational, the organization will perform adequate reporting procedures (i.e. reporting in an efficient, effective and timely manner) for performance and the extent of compliance with internal and external laws, regulations and guidelines (compliance). As a consequence, the flexible (resilient) organization will be able to respond quickly to future internal and external developments.

GRC and COSO-ERM

Viewed properly, GRC and COSO-ERM share much in common. The above-described holistic GRC paradigm encompasses all COSO ERM activities, all objectives and all levels of the organization. In addition, the ERM approach establishes an unambiguous and coherent process based on all categories of risk. Figure 4 shows the components of COSO ERM, namely the eight activities (front), the layers within the organization (the right side) and objectives (top). There is one difference, however. COSO ERM specifically indicates which activities have to be performed in order to achieve which objectives, and how they are distributed over the various organizational levels. In contrast, the holistic GRC model shows precisely how an integrated approach and enhanced cooperation can be organized, and how such a method will work. Both models complement each other well.

C-2011-0-Beugelaar-04

Figure 4: COSO-ERM framework

Complexity of implementing GRC

Despite the clearly obvious benefits, the solidity of the business case and the clarity of the vision (see holistic model), actually implementing GRC in practice turns out to be complex and often either fails or has to overcome enormous pitfalls on the road to success.

But why does the implementation of GRC encounter so many obstacles in practice? If you are involved in one of the risk and control functions (such as risk management, compliance, IT, IT security, business continuity management or internal audit) or if you are active in the business, you will undoubtedly recognize the following objections.

  1. Often, risk and “control” functions are only responsible for a defined area of internal control. Usually, the task requires specific knowledge and skills and there is a prevalent view that the activities involved cannot be performed by others or that collaboration does not provide an effective contribution to the specific field of work.
  2. The individuals performing these functions follow the instructions of a departmental head, an independent manager who assumes the responsibility for the specific department. This department contains a certain number of employees. Collaboration and (worse) integration often leads to fear about having to surrender autonomy, independence and a number of people under the manager’s charge.
  3. In recent years, each of the function-based units have been carefully working on developing appropriate procedures, processes, IT systems, applications, reports and methodologies in their own field. Collaboration and integration mean that these developed methodologies, databases, applications, etc. have to be adjusted, or else their contribution in the new GRC environment will become negligible.

In general, calls for greater collaboration and reduced duplication more frequently come from business and “corporate.” The advantages of collaboration have been recognized within each of the function-based units, but such recognition is often only translated into small (though often good) improvements, including the coordination of schedules and concerted action regarding “risk and control self-assessments.” The managers of each of these risk and control departments shall have the collective task of finding a better and more expansive solution enabling the advantages of collaboration to be fully exploited.

GRC scan

As indicated, implementation of GRC in an extensive and comprehensive project often proves to be unworkable. Therefore we advocate the initiation of a GRC scan in order to determine how a successful roll-out of integrated GRC can be achieved. This will remove the obstacles standing in the way of successful implementation, identify them as early as possible and enable a phased implementation of GRC to be started within the latitude provided by the organization.

An approach to a successful roll-out of “integrated GRC” starts by determining the current status of GRC in the organization, along with the organization’s target level with respect to GRC (desired state). It is then important to understand those elements of GRC that will provide the maximum benefit for the organization as a whole. These benefits may be defined in monetary terms, or in terms of increased transparency and speed of decision-making, or even in terms of reduced redundancy and less “harassment” of the business. Running a GRC scan enables the organization to examine a number of issues. The results of such a GRC scan partially form the basis for preparing the business case and the implementation plan for a phased and “sustained” transition to integrated GRC.

In general, a GRC scan provides answers to the following questions:

  • What is the current status of GRC in the organization?
  • What is the GRC target level?
  • To what extent is the organization ready to initiate GRC?
  • What are the steps for achieving the target level, and in what order should they be implemented?

These issues should be clarified by conducting targeted interviews using a questionnaire. Only then is the organization ready to unpack the successes of GRC into more wide-ranging successes for the organization. The advantages of the GRC scan include the phased development and roll-out of the various GRC components. In this respect, it is important to start with those components considered the most likely to deliver the greatest benefits for the organization or to furnish risk and control functions. Based on the readiness for change in the various departments and the importance of rolling-out these high-value components, the sequence of implementation and the parties involved in the roll-out can be determined. Gaining insight into the “quick wins” at this point is one of the key drivers for continued success. During the GRC scan, an analysis will be made of the components that can be created relatively quickly and at sufficiently low costs. These quick wins will pave the way for subsequent successes.

Prior to conducting the GRC scan, all GRC activities will be clearly organized, categorized pragmatically into nine groups and explained by means of the questionnaire. These activity groups contain activities performed in every governance, risk and control function, but almost all of them are customized in a distinct and specific manner. These nine activity groups are fully compatible with KPMG’s holistic GRC model. However, the holistic GRC model is not based on the grouping of activities, but the subsequent development, implementation and outcome components of GRC. See Figure 5 for the activity groups covered by the GRC scan. By determining the status, ambition and willingness to change, as well as the pros and cons for the organization in each of these areas, the organization can make an informed choice regarding the anticipated manner of growth required to achieve an integrated GRC environment throughout its discrete segments.

These activity groups are:

  1. Strategy & Mission. This component further details such elements as the compatibility of business goals with the appetite for risk, as well as the general goal regarding risk integration. Furthermore, in this component the risk business model is further developed, as are the communication channels to the rest of the organization.
  2. Charters. This component relates mainly to the further structuring of function-based units, roles, tasks, responsibilities and the commitment of resources and other tools.
  3. Planning. This component involves the way that the planning activities of each of the function-based units are carried out, and the extent to which they can be integrated or cooperation among them enhanced.
  4. Risk & Control Self Assessments. This component explores the RCSA’s commitment and progress within the organization when dealing with new products, in reviewing existing processes and in investigating incidents.
  5. Databases (for issues, losses and events). This component concerns in particular the quality of available data, accessibility of data and the presence of a stand-alone or integrated IT solutions.
  6. IT. This component explores the current IT infrastructure in terms of platforms, applications and other existing or desired IT-related solutions, such as the use of GRC software and the possibility of running all risk and control functions on the same server, thus enabling data exchange to occur more easily.
  7. Risk & Control Framework. This component principally examines the existing control frameworks, their overlap and integration, and the deployment of GRC tools.
  8. Reporting. This component mainly concerns reporting structures, quality and speed of reporting, as well as the availability of accurate, timely and complete information in order to make informed choices and decisions.
  9. Culture & Behavior. This component explores the willingness to change within each of the organization’s segments, their culture and behavior regarding GRC and how people deal with their responsibilities.

C-2011-0-Beugelaar-05

Figure 5: The components of KPMG’s GRC scan

Once the actual state and target state are determined and each of the areas is assessed in terms of the extent to which it contributes to the goals of the organization as a whole, then the route to the target level can be plotted (the roadmap). Both the benefits of and obstacles to integrated GRC will be clear for each of the areas. As an example, Figure 6 provides an overview of the possible obstacles and benefits for the “Strategy & Mission” component.

C-2011-0-Beugelaar-06

Figure 6: Potential benefits and obstacles – Strategy & Mission

The perceived benefits and obstacles for each of these groups can be plotted on a graph (see Figure 7) in which the elements in the top left corner provide the greatest “benefits” for the organization while involving the fewest predicted obstacles during implementation. GRC development and deployment will therefore be initiated in these areas.

C-2011-0-Beugelaar-07

Figure 7: Priority matrix for GRC

The benefits and conditions for a successful roll-out of integrated GRC

The big question now concerns how to determine when the roll-out of integrated GRC has been successful. The important characteristics of a successful roll-out will be measured based on the realization of the prepared business case. Various GRC implementations in practice have given rise to the following benefits in particular ([KPMG]):

  • Organizations that improve their business performance with GRC will find that they increase their flexibility to cope with changes in the environment while being able to enhance their “corporate” reputation and improve shareholder value.
  • Cooperation among internal-audit, risk-management and compliance-related functions is improved, while front-line management is less frequently tasked with overlapping issues and functions.
  • The use of GRC and continuous monitoring / auditing software improves understanding about the extent to which processes, risks and issues are controlled, while insight into the actual state may be obtained online by means of “executive dashboards.” In addition, costs are further reduced by the concerted action of the various business functions combined in these dashboards.
  • Better integrated risk and control frameworks reduce the overlap in activities as well as the quantity of the required controls, or a rationalization of the controls enables the business to be less encumbered by them.
  • The organization has better control and is seen to be in better control.
  • The organization can respond quickly and flexibly to changes in environmental conditions in areas such as legislation and regulation, customer needs and new products (but also to internal changes).

A case study

At a major international financial institution, the decision was made to increase the efficiency and effectiveness of the internal controls used in some of the risk and control departments by improving the cooperation among the departments and even integrating them. Seven of the second and third line departments (Inspection, Operational Risk Management, Compliance, SOx, IT Security, Process Management and Internal Audit) participated in this initiative. Significant opportunities for improvement were identified in six components that could be translated into actions increasing the effectiveness of internal control and the efficiency of risk mitigation. These involved 1) the integration of the charters, 2) the integration of risk and control frameworks, 3) the development of a GRC application, 4) the further coordination of risk & control self-assessment activities, 5) rationalization of the issues, losses and incidents databases and 6) establishing a system of non-financial risk reporting.

The prepared business case and roadmaps for further implementation yielded the following principal advantages:

  • Improvement of risk management by focusing on key controls and using the best risk management methods
  • Increased central management of risk and control activities, leading to lower insurance premiums, reduced risks to reputation, and enhanced clarity in assessing risk.
  • Increased effectiveness of operational activities through the efficient maintenance of controls, reduction of stratification in risk assessments and a reduced number of IT applications.
  • Cost reduction due to smaller number of FTEs, use of uniform IT technology and reduced redundancy.
  • Risk reduction resulting in improved resource allocation, increased responsiveness to incidents and an increase in risk awareness.

However, a number of factors need to be addressed as conditions for obtaining these benefits and successes. Some of these conditions are:

  • The willingness to change of managers and employees within the various units (culture and behavior).
  • A phased approach based on the results of a GRC scan in which the components yielding the highest expected benefits for the organization are performed first.
  • Development and implementation of a solid communications plan, under which everyone is promptly and transparently informed about progress and the impact of changes on each individual.
  • Commitment from the organization’s management, without which successful GRC will not occur.
  • Time and money available to invest in GRC. GRC means that a number of items involved in risk and control will be identified and radically transformed; since such an overhaul will require development time and money, it must be budgeted and assigned as the responsibility of senior management.
  • Change management. Throughout the program, attention is focused on the changes that have to take place; without this vigilance, people will tend to continue their current activities, and fear of the new will get in the way.

Conclusion

Successful GRC is achievable. Understanding the current status of the various GRC components within the organization, the organizational goal with respect to each of these GRC components and the willingness of the various units to change will make it possible to provide sound advice concerning the steps to take. A further assessment of the perceived obstacles arising when each component is developed and rolled out will result in a clear idea of how the organization can achieve integrated and successful GRC.

The GRC scan is an appropriate means to identify all these matters. The scan results lead to a widely-supported and transparent implementation plan (roadmap) under which the components that meet the fewest obstacles and are the best for the business are chosen to be performed first. Obviously, successful implementation will ultimately only be achieved if certain preconditions are met, including the deployment of a robust communications plan and the commitment of senior management.

Literatuur

[AMRR08] AMR Research, The Future of GRC, 2008, presentation by John Hagerty.

[AMRR09] AMR Research, The GRC Imperative – A Pragmatic Guide to Jumpstarting Your GRC Project, November 2009.

[COSO09] Internal Control – Integrated Framework, Guidance on Monitoring Internal Control Systems, COSO, January 2009.

[Forr07] The Forrester Wave™: Enterprise Governance, Risk, and Compliance Platforms, Q4 2007, For Security & Risk Professionals.

[Gart09] Gartner, Magic Quadrant for Enterprise Governance, Risk and Compliance Platforms, Q3, 2009.

[Klum09] C. Klumper, Toepassing van de Monitoring component van het COSO-raamwerk, MAB, March 2009.

[KPMG] KPMG, The Evolution of Risk and Controls; From Score-Keeping to Strategic Partnering.

Trends in IT internal audit

Veel organisaties ervaren een continue druk en verandering als gevolg van het huidige economische klimaat. Geconfronteerd met een afnemende markt rationaliseren organisaties; onderdelen worden samengevoegd of activiteiten worden ingekrompen. De technologie die systemen en processen bij elkaar houdt, gaat mee in deze veranderingen, hetgeen leidt tot een aantal specifieke risico’s. De IT internal auditor heeft een integrale en belangrijke rol in het monitoren van deze risico’s, deze functie ontwikkelt zich dan ook snel in deze turbulente tijden. Dit artikel bespreekt de resultaten van een EMA (Europe, Middle East and Africa)-survey naar de trends en ontwikkelingen inzake IT internal audit.

Inleiding

(Informatie) Technologie speelt een steeds prominentere rol in het dagelijks bestaan van organisaties. Als gevolg hiervan worden organisaties kwetsbaarder voor doelbewuste sabotage in deze hectische tijd. Daarnaast is het aantal gevallen van onopzettelijk verlies van data en het falen van IT toegenomen. In deze omgeving zijn de rol en de betekenis van de IT internal auditor sterk toegenomen, met als doel het waarborgen van de beveiliging van commerciële data en de reputatie van organisaties.

In het najaar van 2008 is door KPMG IT Advisory een internationaal onderzoek uitgevoerd naar de rol van de IT internal auditor. De resultaten van dit onderzoek zijn gepresenteerd in KPMG’s 2009 IT Internal Audit Survey, The status of IT Audit in Europe, the Middle East and Africa. In totaal hebben 297 organisaties verspreid over twintig landen en meerdere sectoren meegewerkt aan het onderzoek. De volgende onderwerpen zijn in kaart gebracht: organisatie en planning, teambezetting en vaardigheden, het gebruik van tools, rapportageproces en kwaliteit.

In dit artikel is een samenvatting opgenomen van een aantal trends, dat gesignaleerd is in de IT Internal Audit Survey. Tevens bevat het een korte samenvatting van de discussie vanuit de ronde tafel Trends in IT Audit die in juli 2009 is gehouden.

Organisatie en planning

Planningsproces

De invloed van een goede planning en planningscyclus op het succes van de IT-auditactiviteiten dient niet te worden onderschat. Het merendeel van de respondenten geeft aan dat zij een formeel planningsproces hebben ten aanzien van het bepalen van de juiste scope van de controlewerkzaamheden. Tevens wordt beaamd dat het opstellen van een gedetailleerde planning essentieel is voor het waarborgen dat organisatierisico’s worden geadresseerd in het auditplan. Het op frequente basis evalueren en aanpassen van de auditplanning, mede ook naar aanleiding van de huidige economische situatie en wijzigingen in de strategie en bedrijfsstructuren, vindt bij een minderheid van de onderzochte bedrijven plaats. Het is daarom aan te bevelen op frequentere basis de auditplanning te evalueren en eventueel te herzien om zo tijdig te kunnen anticiperen op veranderingen in de in- en externe omgeving.

Gebruik van standaardraamwerken

Bij de planning en uitvoering van de IT-auditwerkzaamheden wordt steeds meer gebruikgemaakt van standaardraamwerken, waarmee een gestructureerde aanpak wordt gefaciliteerd en focus wordt aangebracht in de analyse van de bedrijfs- en technologierisico’s binnen de organisatie. Aangegeven is dat het merendeel van de organisaties het Cobit-raamwerk hanteert, gevolgd door het ISO 17999-raamwerk (figuur 1).

C-2010-1-Houwelingen-01

Figuur 1. Gehanteerde raamwerken.

Integratie van IT-audit met andere disciplines

Er is een duidelijke verandering waarneembaar van een traditionele uitvoering van de IT-auditwerkzaamheden naar een meer proactieve aanpak waarin IT-audit streeft naar het opleveren van waardecreërende IT-auditactiviteiten. Er is daardoor meer samenwerking en afstemming met de IT en de business in de uitvoering van de werkzaamheden. Daarnaast is er ook sprake van meer integratie met de ‘algemene’ auditors, met compliance-auditors en met SOx-auditors. Een voorbeeld betreft de betrokkenheid van IT-auditors bij de review van grootschalige (IT-) projecten. Ook kan door de IT-auditor, juist in de huidige tijden, een meer prominente rol ingevuld worden ten aanzien van onder meer strategische (IT-) processen.

De werkzaamheden van de IT-auditor variëren van het voldoen aan wet- en regelgeving en het formuleren van informatiebeveiligingsstandaarden, tot aan het toetsen van projecten om nieuwe informatiesystemen te implementeren. Belangrijk is dat IT internal audit zich bewust is van en aandacht besteedt aan het waarborgen van de onafhankelijkheid en objectiviteit van de eigen functie. De onpartijdigheid (en hiermee de integriteit) van de auditor is één van de kernelementen van het bestaansrecht en dient derhalve te worden geborgd door middel van het planningsproces en het vaststellen van de juiste rapportagelijnen.

Goedkeuring auditplan en -rapportage

Het onderzoek bracht aan het licht dat bij ruim de helft van de respondenten (63%) het auditplan wordt goedgekeurd door het Audit Committee. Helaas wordt bij 10% van de respondenten het plan door het verantwoordelijk IT-management goedgekeurd, hetgeen een risico is voor de onafhankelijkheid van de auditafdeling ten opzichte van het IT-management.

Idealiter dient het hoofd van het Internal Audit Department (IAD), waaronder IT internal audit valt, te rapporteren aan de Raad van Bestuur of aan het Audit Committee, om op deze wijze de onafhankelijkheid van het IAD ten opzichte van de organisatie te waarborgen. Figuur 2 laat zien dat dit helaas in slechts 30% van de deelnemende organisaties het geval is.

C-2010-1-Houwelingen-02

Figuur 2. Rapportering door het IAD.

Teambezetting en vaardigheden

Teambezetting

Het vinden van de juiste balans tussen technische kennis en organisatiebrede proceskennis blijft een uitdaging voor leidinggevenden binnen IAD’s. Het vormen van de juiste bezetting kan enerzijds door het aantrekken van nieuwe medewerkers van buiten de organisatie en anderzijds door het trainen/ ontwikkelen van het bestaande team. Daarnaast kan ook de onderlinge samenwerking tussen IT-audit en andere auditdisciplines een belangrijke bijdrage leveren in het waarborgen dat kennis wordt opgebouwd om bedrijfsbrede en IT-specifieke issues te adresseren. Het merendeel van de organisaties uit het onderzoek heeft een gecombineerde auditafdeling.

De vaardigheden die boven aan het verlanglijstje van IAD’s staan zijn onder andere informatiebeveiliging en specifieke applicatiekennis zoals van ERP-systemen.

Opleiden of werven?

Door het merendeel van de organisaties is aangegeven dat niet alle noodzakelijke kennis intern aanwezig is. Dit blijkt uit het feit dat 55% van de respondenten aangeeft de juiste kennis en vaardigheden aan te trekken door middel van externe werving. In de huidige economische situatie is dit echter niet altijd een optie. Er is daarom een stijgende lijn te zien in het aantal bedrijven dat ervoor kiest de huidige staf verder op te leiden.

Een tegenstrijdige bevinding is echter dat het aantal beschikbare opleidingsuren teleurstellend laag is. Bij ongeveer een derde van de respondenten is slechts één week per jaar beschikbaar voor opleiding. Een groot gedeelte van dit opleidingsbudget wordt bovendien eerder besteed aan het behalen van de noodzakelijke certificering, dan aan het trainen van vaardigheden.

Het is van belang dat bedrijven meer formele opleidingsplannen ontwikkelen om ontbrekende kennis en vaardigheden en trainingsbehoeften te kunnen identificeren. Dit is tevens bevorderlijk voor de motivatie en retentie van het huidige personeel.

Een derde manier waarop het tekort aan kennis en vaardigheden wordt opgelost, is het tijdelijk inhuren van externe IT-auditors. Meer dan een derde van de deelnemende bedrijven geeft aan gebruik te maken van dergelijke diensten van externen. Het is de verwachting dat dit aantal sterk gaat toenemen in de komende maanden. Enerzijds is door de externe inhuur de benodigde kennis op korte termijn beschikbaar, anderzijds wordt meer flexibiliteit bereikt (ten opzichte van het aannemen van nieuwe medewerkers).

Het gebruik van tools

Van planning van de audit tot en met de rapportering, auditors steunen in toenemende mate op geautomatiseerde tools om het auditproces te ondersteunen. In de KPMG-survey is de toepassing van tools onderzocht. Hieruit blijkt dat tools voornamelijk worden ingezet voor data-analyse (figuur 3).

C-2010-1-Houwelingen-03

Figuur 3. Toepassingen van tooling.

Verrassend genoeg worden de tools die bijdragen aan meer focus op de auditactiviteiten en een efficiënter gebruik van de beschikbare auditcapaciteit, nog niet veel gebruikt voor aspecten zoals planning en risk- en ‘controls’-analyse. Ondanks dat er zeer veel belangstelling is voor continuous auditing software, vindt de werkelijke ontwikkeling en implementatie daarvan nog in weinig organisaties plaats.

Algemeen beschikbare tools zoals Microsoft Excel en Microsoft Access zijn de meest gebruikte toepassingen door het IAD. De gebruikersvriendelijkheid van deze tools helpt hierbij. Echter, deze tools kennen hun beperkingen. Denk bijvoorbeeld aan de kans op ongewenste aanpassingen in de data en de beveiliging.

Rapportageproces en kwaliteit

Het werk van de IT internal auditor wordt meer zichtbaar binnen de organisaties als hierover wordt gecommuniceerd aan het management op het juiste niveau. Door het presenteren van de bevindingen aan topmanagement wordt gewaarborgd dat een beter begrip ontstaat over de issues die van invloed zijn op de organisatie. Alleen op deze manier kan worden bereikt dat de IT internal audit-functie aan belang wint binnen de organisatie, dat er top-down steun is voor deze functie en dat er een toenemende zichtbaarheid voor internal audit op managementniveau ontstaat.

Bijna alle respondenten van het onderzoek presenteren de IT-auditbevindingen en -aanbevelingen in een formeel rapport. Hetgeen opvallend is, is dat slechts 6% van de organisaties de resultaten presenteert op executive-managementniveau. Positiever is het hoge percentage (72%) van organisaties dat zijn bevindingen rapporteert aan het Audit Committee. Externe auditors ontvangen echter in slechts 37% van de gevallen een kopie van dit rapport (figuur 4).

C-2010-1-Houwelingen-04

Figuur 4. Rapportagelijnen.

Dit toont een serieuze discrepantie aan tussen interne en externe rapportering. Er kan beargumenteerd worden dat het werk van internal audit irrelevant is voor de externe auditors. Echter, voor de externe audit kan dit leiden tot gemiste kansen om te bouwen op of om gebruik te maken van werk dat is verricht door hun collega’s van het IAD.

Het meten van kwaliteit

De kwaliteit van het werk van IT internal audit wordt door ongeveer de helft van de organisaties gemeten. De meerderheid daarvan heeft geen kwaliteitscontroles ingericht en in 41% van de gevallen wordt alleen een informeel assessment of geen assessment uitgevoerd. Feedback vanuit management omtrent de tevredenheid over de dienstverlening wordt aan 44% van de IAD’s verstrekt. De vraag is dan: Hoe kunnen deze organisaties dan vol vertrouwen zijn dat de diensten die worden geleverd aan klanten van acceptabele kwaliteit zijn?

KPMG gelooft dat het definiëren van performance-indicatoren een effectieve manier is om de toegevoegde waarde van IT internal audit aan het management te presenteren.

Ronde tafel Trends in IT Audit

Naar aanleiding van de EMA-survey is in juli 2009 een ronde tafel Trends in IT Audit georganiseerd. Deze ronde tafel werd georganiseerd voor IT internal auditors uit diverse branches. Naast KPMG-presentaties over de survey en dataprivacy, gaf een gastspreker van ING (Dirk Brouwer) een toelichting op de inrichting en werkwijze van de interne-auditafdeling binnen ING.

Surveybespreking

De resultaten van de survey gaven aanleiding tot diverse discussies en uiteenlopende standpunten. Eén van de discussies die gevoerd werd, betrof de vraag hoe organisaties omgaan met de rapportering van bevindingen op verschillende niveaus binnen de organisatie, welke tools hierbij worden ingezet en hoe opvolging van bevindingen wordt gewaarborgd. Uit de discussie blijkt dat organisaties verschillend hiermee omgaan en dat er eigenlijk geen eenduidig antwoord gegeven kan worden. De grootte van de organisatie, de interne processen en de volwassenheid van een IAD zijn daarbij van bepalende invloed. Een aantal suggesties kwam naar voren zoals:

  • meer samenwerking met risk management om bevindingen vast te leggen in een gezamenlijk systeem en ook te monitoren qua opvolging;
  • het meer groeperen van bevindingen afhankelijk van het niveau waarop gerapporteerd wordt en periodiek een geconsolideerde rapportage uitbrengen aan het management;
  • het hanteren van Cobit als model als een belangrijk uitgangspunt in het proces.

Invloed economische crisis

Daarnaast is stilgestaan bij de impact van de economische crisis op de werkzaamheden van de IT internal audit-functie. Uit de discussie kwam naar voren, dat ‘teruggaan naar de basis van het auditproces’ een belangrijke ontwikkeling is. Dat wil zeggen dat IT internal audit zelf in de lead is om de auditobjecten te bepalen. Dit in tegenstelling tot het verleden, waarin een meer servicegericht concept naar IT-management gehanteerd werd.

Een andere ontwikkeling betreft het strak managen van de auditplanning en het weglaten van bijvoorbeeld managementreacties in IT-auditrapporten om de snelheid van uitbrengen van rapporten te waarborgen. Belangrijke constatering was om in het huidige klimaat meer aandacht te besteden aan de beheersing van fraudeaspecten, security awareness en de beheersing van processen en systemen.

Dataprivacy

Als laatste is het onderwerp dataprivacy in de internal audit toegelicht. Bij dataprivacy draait het om de vertrouwelijkheid waarmee met klantgegevens wordt omgegaan en welke rol een IT internal auditor heeft in dit proces. Belangrijke constatering was dat de complexiteit en impact van dataprivacy op organisaties afhankelijk is van het type business en de klantsamenstelling. Wet- en regelgeving op dit vlak is in beweging en het is van belang dat IAD’s hier ook van op de hoogte zijn.

Hoe verder?

Naar aanleiding van de onderzoeksresultaten en de onderwerpen besproken tijdens de ronde tafel worden de volgende verbeteracties voorgesteld om zo de effectiviteit en daarmee de toegevoegde waarde van IT internal audit in de bedrijfsvoering te vergroten:

  • IT internal audit dient meer betrokken te zijn bij vraagstukken op het gebied van de bedrijfsvoering en IT-besluitvorming, zonder dat zij haar onafhankelijkheid verliest. De kennis op het gebied van bedrijfsrisico’s en technologische risico’s dient gelijkmatig te worden vertegenwoordigd.
  • In hectische tijden veranderen het commerciële en het organisatorische landschap voortdurend. Het reviewen van de auditplanning op basis van een ‘rolling forecast’ of kwartaalbasis maakt het mogelijk adequaat te reageren op verandering en risico’s.
  • Standaard risico- en planningsraamwerken bieden ondersteuning om de audit beter te focussen op de business en de aanwezige risico’s.
  • Afstemmen van IT-auditactiviteiten met andere governance-activiteiten kan schaalvoordelen en synergie opleveren. Ook het geïntegreerd laten samenwerken van IT-auditors en ‘algemene’ auditors kan kennisuitwisseling faciliteren.
  • Auditplannen dienen te worden goedgekeurd door het Audit Committee en het hoofd IAD dient aan de Raad van Bestuur of het Audit Committee te rapporteren.
  • Verbeteren van het kennisniveau op het gebied van IT-security.
  • Meer gebruikmaken van geautomatiseerde tools kan bijdragen aan de effectiviteit en efficiency van audits.

Literatuur

[Fijn09] R. Fijneman en R. Poch, KPMG’s 2009 IT Internal Audit Survey, The status of IT Audit in Europe, the Middle East, and Africa, March 2009.

[GAIN09] Global Audit Information Network – The Institute for Internal Auditors, Knowledge Alert, 2009 hot topics for the internal audit profession, January 2009.

Geslaagd GRC binnen handbereik

We zien dat ondernemingen de laatste jaren initiatieven ontplooien om de organisatieonderdelen die belast zijn met taken op het gebied van risicomanagement, interne controle, compliance en audit beter te laten samenwerken of zelfs te integreren. Deze initiatieven zijn veelal ontstaan uit de wens en noodzaak om activiteiten die samenhangen met governance, risk en compliance efficiënter en transparanter in te richten. Bovendien geldt dat de wetgeving en regeldruk toenemen en ondernemingen zoeken naar het op efficiënte en effectieve wijze voldoen aan de vereisten vanuit die wet- en regelgeving en andere ‘control frameworks’. Toch slagen niet alle ondernemingen erin om de samenwerking tussen de verschillende organisatieonderdelen op een effectieve en efficiënte manier tot stand te brengen. Een geïntegreerde aanpak op het gebied van Governance, Risk en Compliance (GRC) is hiervoor de oplossing. Dit artikel beoogt inzicht te geven in de wijze waarop een GRC-implementatie succesvol kan verlopen. De aanpak, voorwaarden en mogelijke valkuilen komen aan bod. Inzicht hierin verhoogt de slagingskans van GRC. Een effectieve, efficiënte en transparante samenwerking en/of integratie is dan binnen handbereik.

Inleiding

Interne beheersing is van alle tijden en wordt binnen ieder bedrijf op een eigen manier ingevuld. Sinds vele jaren echter zien we dat binnen veel ondernemingen een ruime schakering aan functies en afdelingen is ontstaan die zich bezighouden met allerlei deelaspecten van die interne beheersing: interne controle, inspectie, (operational) risk management, business continuity management, information security, compliance, legal, IT, planning en control, internal audit. Al deze functies vervullen een belangrijke rol, maar wel elk op hun eigen aandachtsgebied met eigen specifieke kenmerken. Ondernemingen zijn er inmiddels achtergekomen dat deze veelheid aan functies en afdelingen onvoldoende effectief is en ook nog eens inefficiënt opereert. Niet alleen vanuit het bedrijfsleven zelf, aangemoedigd door raden van commissarissen en raden van bestuur, maar ook vanuit de aandeelhouders en toezichthouders wordt steeds grotere druk uitgeoefend om een transparant inzicht te verkrijgen in de écht belangrijke risico’s, de beheersing daarvan en een heldere en duidelijke rapportage. Het belang om de verzameling aan risico- en ‘control’-functies beter te laten samenwerken dan wel te laten integreren is daarmee duidelijk.

GRC staat voor Governance, Risk & Compliance. In de markt zien wij dat de initiatieven betreffende GRC ook wel aangeduid worden als ‘risk convergence’, ‘integrated assurance’, ‘E-GRC’ en ‘single view of risks’. Deze termen worden tegelijkertijd ondersteund door evenzovele (internal) control frameworks[Diverse frameworks voor de interne beheersing van organisaties zijn in omloop, zoals COSO-ERM, COCO, Cadbury, Cobit en ITIL.] en GRC-software, waaronder SAP GRC, Thomson Reuters, OpenPages en BWise ([Gart09]). Alle hebben zij één gemeenschappelijk doel, namelijk het wegnemen van de ‘silo-gedachte’ en het verminderen van redundanties die momenteel bestaan tussen de verschillende governance-, risk- en complianceactiviteiten door het implementeren van één GRC-framework, ondersteund door één IT-platform en één applicatie. Het verbeteren van de samenwerking, of de integratie van activiteiten van de verschillende organisatieonderdelen belast met risicomanagement, interne controle, audit en compliance, is één van de resultaten van geslaagd GRC. We zien dat ondernemingen, die veelal te maken hebben met hoge vereisten vanuit de wet- en regelgeving en een bepaalde rol hebben in het maatschappelijk verkeer, een grotere bereidheid of drang ervaren om de samenwerking en/of integratie tot stand te brengen. Deze ondernemingen zijn veelal actief in de financiële sector, de ‘chemicals’ en ‘energy and utilities’. Maar ook ondernemingen in andere sectoren zien steeds vaker het belang van geïntegreerd GRC. Door geïntegreerd GRC zal de bedrijfsvoering aantoonbaar ‘in control’ zijn en ontstaat een verbeterd en transparanter inzicht in de status van risico’s en control frameworks, alsmede een expliciete afstemming van taken en verantwoordelijkheden tussen de ‘silo’s’, en kunnen de wijze, snelheid en effectiviteit van rapportering significant verbeteren door de inzet van GRC-software.

Maar met een geïntegreerd ‘control framework’ en GRC-software bent u er nog niet. In de praktijk zien we veel initiatieven, maar veelal leveren deze op termijn niet het gewenste resultaat. De verschillende afdelingen voelen zich vaak te uniek om samen te werken (wet- en regelgeving, dan wel diverse codes kunnen het beste vanuit het eigen expertisegebied benaderd worden, meent men, waarbij samenwerking, laat staan integratie, enkel van de hoofdzaak afleidt). Daarnaast zullen veel van deze afdelingen angstig zijn dat de zorgvuldig opgebouwde expertise, tooling, methodieken, rapportagestructuren en ontwikkelde risk ratings overboord gegooid gaan worden.

Bij veel organisaties wordt er op verschillende niveaus invulling gegeven aan onder meer het voldoen aan wet- en regelgeving en internecontroleraamwerken, het beheersen van risico’s, het uitvoeren van interne controles, het uitvoeren van audits en de invulling van governancevraagstukken. Er wordt ook wel eens gesproken over het ‘three lines of defense’-model. Alle lagen in dit ‘three lines of defense’-model, te weten het management, de ondersteunende risico- en controlfuncties en internal audit, vervullen een rol op het gebied van GRC en hierin zit op bepaalde aspecten een overlap. Deze aspecten zullen wij in dit artikel verder toelichten. Daarnaast zien wij dat door realisatie van GRC de totale inzet van de ‘three lines of defense’ duurzaam vermindert en daardoor efficiënter wordt (zie figuur 1). Door een vergaande realisatie van GRC te bewerkstelligen verschuift de inzet van de verschillende rollen bij interne beheersing van derde en tweede lijn naar de eerste lijn (het management), waar deze in essentie ook thuishoort. In figuur 1 is van links naar rechts de zwaarte van de interne beheersingsactiviteiten weergegeven bij een lage realisatie van GRC (links) en een hoge realisatie van GRC (rechts).

C-2010-1-Beugelaar-01

Figuur 1. Rolverdeling van de ‘three lines of defense’ bij een verdergaande realisatie van GRC.

Voor een geslaagde uitrol van GRC binnen organisaties is een aantal factoren bepalend. In dit artikel beogen wij een antwoord te geven op de volgende vragen:

  • Wat is het belang van een geslaagd GRC? Waarom zouden organisaties moeten streven naar geïntegreerd GRC?
  • Op welke, stapsgewijze, manier kan een organisatie een succesvolle uitrol van GRC bereiken?
  • Wat zijn de voordelen van geïntegreerd GRC?
  • Wat zijn de voorwaarden voor een succesvolle uitrol van geïntegreerd GRC?

Het belang van geslaagd GRC

De wildgroei

Redenen waarom organisaties naarstig op zoek zijn naar een effectieve en efficiënte inrichting van de gehele beheersingsorganisatie rondom governance, risk en compliance, zijn velerlei. Het belang van geslaagd GRC is echter pas goed aan te geven als ook gekeken wordt naar de aanleiding, waarom deze organisaties in beginsel de wildgroei aan deze functies hebben laten ontstaan. Immers, geen organisatie kiest er bewust voor om, zonder inzicht in de totale kosten en met verlies van een helder en overkoepelend beeld (lees: transparantie), activiteiten uit te voeren die ogenschijnlijk op elkaar lijken, dan wel overlappend zijn. De aanleidingen voor de wildgroei zijn opgenomen in tabel 1.

C-2010-1-Beugelaar-t01

Tabel 1. Aanleidingen voor de wildgroei. [Klik hier voor grotere afbeelding]

Het belang

Het belang van een geslaagd GRC-initiatief ligt dus besloten in veel van de hierboven geschetste problemen. Volgens het AMR Research ([AMRR08]) is het belang van een geslaagd GRC te vinden in de volgende (in volgorde van belangrijkheid) drivers:

  • het beter managen en beheersen van risico’s in de business;
  • het reduceren van de totale kosten van GRC-activiteiten;
  • het automatiseren van GRC-activiteiten en het continu toepassen daarvan;
  • het leveren van interne en externe transparantie;
  • risico’s en kosten van non-compliance;
  • het opzetten van een verdedigbare informatieomgeving.

Het probleem is echter dat deze drivers vaak onvoldoende gekwantificeerd kunnen worden. Immers, de huidige ‘cost of risk’, ‘cost of control’ en ‘cost of compliance’ zijn onvoldoende duidelijk. Om dit helder te krijgen zou een inventarisatie gemaakt moeten worden van alle GRC-gerelateerde kosten die binnen een organisatie worden gemaakt. We praten dan niet alleen over de externe en interne auditkosten, maar ook over eerste en tweede ‘line of defense’-kosten en kosten van de operationele controls, inclusief de in kosten uitgedrukte urenbesteding voor GRC-activiteiten. Deze laatste vormen vaak de verborgen kosten, doordat zij in de reguliere bedrijfsuitvoering zijn opgenomen. Daarnaast geldt dat veel van de beheersingsmaatregelen onvoldoende ingedeeld zijn in ‘operationele controls’ en ‘monitoring controls’ ([Klum09]) en het inzicht ontbreekt in de mate waarin controls manueel dan wel geautomatiseerd worden uitgevoerd. Tevens blijkt dat veel organisaties onvoldoende zicht hebben op hoeveel tijd (en dus kosten) wordt besteed aan correctiewerkzaamheden naar aanleiding van geconstateerde gebreken in de uitvoering. Zie hiervoor figuur 2 inzake de componenten van beheersingskosten.

C-2010-1-Beugelaar-02

Figuur 2. Componenten van beheersingskosten.

Het integreren van verschillende ‘control frameworks’ is hier vaak een goede eerste aanzet toe maar is zeker niet voldoende.

De business case ([AMRR09]) voor een succesvolle implementatie van GRC is er wel degelijk, maar dient opgesteld te worden. De uitdaging ligt in het bepalen van de geschatte opbrengsten (of verlaagde kosten). Dit kan tot uitdrukking komen in een aantal aspecten zoals:

  • besparing in aantal fte’s belast met GRC-taken;
  • verhoging van de productiviteit door een efficiëntere uitvoering van GRC-taken, bijvoorbeeld door een aantal ‘controls’ te automatiseren;
  • stroomlijnen en optimaliseren van bedrijfsprocessen;
  • gezamenlijk uitvoeren van review- en auditwerkzaamheden door de staven, waardoor redundantie wordt verminderd;
  • verbetering van risicomanagement en GRC-rapportages (dashboards);
  • sneller beschikbaar hebben van stuurinformatie door inzet van GRC-software, waardoor transparantie verbetert.

De geschatte opbrengsten (of verlaagde kosten) hebben een kwantitatief, maar zeker ook een kwalitatief karakter. Een succesvolle implementatie van GRC vraagt ook een investering. Derhalve is het van belang om een gedegen business case op te stellen, waarin ook de aanpak voor een succesvol GRC is bepaald.

Een aanpak tot succesvolle uitrol van GRC

Een visie op geïntegreerd GRC

Ten behoeve van een succesvolle uitrol van GRC is het van belang dat organisaties een visie ontwikkeld hebben op GRC. Dit betekent dat duidelijk moet zijn waar de organisatie nu staat op het gebied van GRC en waar zij naartoe wil groeien (de ambitie). Deze ambitie kan daarbij ingegeven zijn vanuit verschillende invalshoeken. Mogelijk is er een concurrentievoordeel te behalen door snellere, scherpere en beter geïnformeerde besluitvorming. Maar wellicht kan het ook de ambitie zijn om allereerst de interne beheersing aantoonbaar op orde te hebben. Ook in situaties waar toezicht plaatsvindt door bijvoorbeeld toezichthouders, zoals DNB, of waar rating agencies over de schouder meekijken, kan het wenselijk zijn een geïntegreerde oplossing voor alle risico- en controlfuncties te hebben.

Al met al betekent bovenstaande dus dat GRC niet zomaar een ‘gezamenlijk’ uitvoeren van enkele activiteiten betreft. Het betreft een volledig geïntegreerd denken en werken volgens een efficiënt en effectief businessmodel, waarbij eenduidigheid bestaat over alle binnen het GRC-domein uit te voeren werkzaamheden, van strategiebepaling tot en met uiteindelijke rapportage en effectmeting en een goede samenwerking en afstemming met de activiteiten buiten dit GRC-domein.

Figuur 3 toont deze geïntegreerde benadering. GRC wordt hierbij gedefinieerd als:

  • het geïntegreerde ‘framework’ dat vanuit de organisatiedoelstellingen
  • een verbinding legt tussen ‘governance’-, ‘risk’-, ‘control’-, ‘compliance’- en ‘assurance’-functies
  • teneinde een uniforme, consistente en veelomvattende visie op GRC door te voeren
  • in de gehele organisatie.

Binnen deze benadering wordt uitgegaan van een aaneenschakeling van opeenvolgende inrichtings-, uitvoerings- en resultaatcomponenten.

C-2010-1-Beugelaar-03

Figuur 3. KPMG’s holistisch GRC-model.

De missie, welke de verwachtingen in zich bergt van de belanghebbenden van de organisatie, zal zijn vertaald in een strategie ten aanzien van ‘governance’-, ‘risk’-, ‘control’-, ‘compliance’- en ‘assurance’-taken, de te delen waarden en overtuigingen (values). Het bedrijfsmodel van deze GRC-activiteiten zal aangesloten moeten zijn op het bedrijfsmodel van de organisatie. De ‘value drivers’ bepalen uiteindelijk het succes van de GRC-activiteiten, geredeneerd vanuit de doelstellingen van de organisatie.

Het onderdeel ‘Governance, Organisation and Infrastructure’ wordt ook wel de ‘harde’ governance genoemd. De management- en toezichtstructuren worden hier bepaald, eenduidig voor alle benodigde risico-invalshoeken en afgestemd op elkaar. Voor bijvoorbeeld banken ontstaat hierdoor een eenduidige structuur voor credit, market, liquidity en operational risk. Rollen en verantwoordelijkheden worden bepaald en een strategische keuze wordt gemaakt over de inzet van (IT-) systemen en ondersteunende applicaties ten behoeve van de GRC-activiteiten en -rapportage. Specifieke GRC-software is hiervoor beschikbaar in de markt.

‘Culture & Behavior’ wordt ook wel aangeduid met de ‘zachte’ governance. Robuuste GRC werkt alleen als zaken als integriteit, motivatie, discipline, communicatie, verantwoordelijkheid, onafhankelijkheid en transparantie volledig zijn ingebed in de organisatie en bij haar mensen. Cultuur en gedrag moeten in de harten en in de hoofden van de medewerkers zitten. Het belang van een eenduidige en positief ingestelde cultuur kan niet te vaak worden benadrukt. Het is één van de belangrijkste voorwaarden voor een geslaagd GRC. Binnen deze cultuur worden zaken genoemd en uitgedragen als ‘tone at the top’, training, bewustwordingssessies, compensatie- en beloningsschema’s, ‘soft controls’, open, eerlijke en heldere communicatie.

Het ‘risk profile’ wordt minimaal eenmaal per jaar door middel van een ‘assessment’ opgesteld, gebruikmakend van alle expertisegebieden van de organisatie. Dit ‘assessment’ beslaat dan ook al haar werkvelden. Er zal een eenduidig en allesomvattend beeld van de ‘risk universe’ ontstaan en een, aangesloten op de missie en strategie van de onderneming, eenduidige inschatting van de risico’s. Een uniforme risicometing per risicocategorie is daarbij van cruciaal belang in het doorvertalen van het risicoprofiel naar vervolgactiviteiten, monitoring en rapportages.

Het ‘operational model’ en de ‘business processes’ vormen het hart van GRC. Hier vinden de operationele activiteiten plaats en is het van belang om de risico’s te beheersen ten aanzien van bedrijfsactiviteiten zoals inkoop, verkoop, productie, R&D, HR en accounting, rekening houdend met het opgestelde ‘risk profile’. In dit ‘hart’ zijn de activiteiten belegd en is het ‘control framework’ voor risicobeheersing opgesteld. De reguliere GRC-activiteiten bestaan onder andere uit het maken van beleid, het onderhouden van ‘risico en control frameworks’, het registreren en opvolgen van incidenten, issues en ‘losses’, het onderwijzen van het management, het uitvoeren van bewustwordingsprogramma’s en het uitvoeren en begeleiden van goedkeuringsprocessen voor nieuwe producten.

Binnen ‘Enterprise assurance’ zijn alle monitoring-, review- en interne auditactiviteiten samengebracht die gecoördineerd worden uitgevoerd ten behoeve van het veiligstellen van de doelstellingen van de organisatie (zoals vervat in de missie en strategie en vertaald naar tactische en operationele doelstellingen). Deze ‘enterprise assurance’ kan in hoge mate efficiënt en effectief worden vormgegeven. Het concept van ’embedded testing’ ([Klum09]), nog eens door de COSO-organisatie extra benadrukt in de laatste guidance op de monitoringrol binnen COSO ERM ([COSO09]) leidt hierbij tot een efficiënte inrichting van de gehele interne beheersings- en verantwoordingsstructuur. Deze gaat uit van het zo dicht mogelijk bij het management beleggen van de monitoringrol op de uitgevoerde operationele controls. Wanneer deze effectief is ingericht, zal de reviewfunctie (tweede ‘line of defense’, zoals risk management en compliance) slechts een ondersteunende en toetsende rol hoeven te hebben na het uitvaardigen van beleid. Internal audit kan vervolgens gericht kijken naar de adequate opzet en werking van de tweede ‘line of defense’. Als deze ‘line’ zijn werk goed blijkt te doen, dan hoeft internal audit enkel vast te stellen dat het management zijn monitoringrol adequaat vervult en zal internal audit slechts op steekproefbasis een test willen doen op de ‘operating effectiveness’ van de operationele controls. Verder kunnen geautomatiseerde analysemethodieken, alsmede continuous monitoring / continuous auditing een belangrijke bijdrage leveren aan de efficiënte en effectieve inrichting van de interne beheersing. Hierbij kan gedacht worden aan software zoals Idea, Approva, SAP GRC Process Controls en ACL. Op basis van vooraf vastgestelde parameters zullen afwijkingen in trends en bandbreedtes leiden tot nadere analyse. Ook tooling voor het vastleggen, volgen en opvolgen van issues, incidenten en fouten in de interne beheersing behoort tot de gereedschapkist inzake ‘enterprise assurance’. Hierbij moet gedacht worden aan GRC-software zoals BWise, OpenPages, Thomson Reuters, Axentis en Qumas ([Forr07]).

Wanneer dit alles goed werkt en is ingericht, is de organisatie in staat op adequate, lees effectieve, efficiënte en tijdige wijze, te rapporteren over de performance en over de mate waarin voldaan wordt aan de interne en externe wet- en regelgeving en richtlijnen (compliance). Daardoor zal de organisatie flexibel (resilience) kunnen ingaan op toekomstige ontwikkelingen, zowel intern als extern.

GRC en COSO-ERM

Goed beschouwd hebben GRC en COSO-ERM veel gemeen. Binnen het holistische GRC-denkmodel, zoals hierboven geschetst, komen alle COSO ERM-activiteiten, alle doelstellingen en alle lagen in de organisatie aan bod. Daarnaast heeft ERM ook de invalshoek om vanuit alle risicocategorieën een eenduidige en integrale aanpak in te richten. In figuur 4 zijn de COSO-ERM-elementen weergegeven, te weten de acht activiteiten (voorvlak), de lagen binnen de organisatie (het rechter zijvlak) en de doelstellingen (bovenvlak). Echter, er is een verschil. Het COSO-ERM geeft met name aan welke activiteiten moeten worden verricht voor welke doelstellingen en verdeeld binnen de verschillende organisatielagen. Het holistische GRC-model daarentegen geeft juist aan hoe deze wijze van geïntegreerde aanpak en aanpak van verbeterde samenwerking kan worden ingericht en kan werken. Beide modellen vullen elkaar dus uitstekend aan.

C-2010-1-Beugelaar-04

Figuur 4. COSO-ERM-framework.

De complexiteit van het inrichten van GRC

Ondanks dat de voordelen zo duidelijk zijn, de business case gemaakt en de visie (zie het holistische model) helder verwoord zijn, blijkt dat het feitelijk tot stand brengen van GRC in de praktijk ingewikkeld is en vaak ook mislukt, dan wel dat op de weg naar het succes grote hobbels ontstaan.

Maar waarom ondervindt het inrichten van geïntegreerd GRC in de praktijk dan zoveel obstakels? Als u werkzaam bent in één van de risico- en controlfuncties, zoals risk management, compliance, IT, IT security, business continuity management of internal audit, of als u in de business actief bent, dan zult u één van de volgende bezwaren ongetwijfeld herkennen.

  1. Vaak zijn risico- en ‘control’-functies verantwoordelijk voor slechts één afgebakend gedeelte van de interne beheersing. Veelal bezit de functie specifieke kennis en kunde en is zij van mening dat deze functie niet door anderen gedaan kan worden, begrepen wordt, dan wel dat samenwerking een effectieve bijdrage levert aan het specifieke werkveld.
  2. De functies worden aangestuurd door een hoofd, die een autonome verantwoordelijkheid voelt voor de betreffende afdeling. In deze afdeling is een bepaalde hoeveelheid mensen werkzaam. Samenwerking en (erger nog) integratie leidt vaak tot de angst in te moeten leveren op autonomie, zelfstandigheid en aantal mensen waarvoor men verantwoordelijk is.
  3. Ieder van de functies heeft de afgelopen jaren zorgvuldig gewerkt aan de totstandkoming van adequate procedures, processen, IT-systemen en -applicaties, rapportages en methodieken voor het eigen werkveld. Samenwerking en integratie betekenen dat deze ontwikkelde methodieken, databases, applicaties, enzovoort moeten worden aangepast, dan wel dat hun bijdrage in de nieuwe GRC-omgeving nihil is.

Vanuit de business en vanuit ‘corporate’ wordt over het algemeen wel steeds vaker aangedrongen op meer samenwerking en het reduceren van dubbel werk. Binnen ieder van de functies wordt het voordeel van samenwerking wel erkend, echter blijft het vaak bij kleine (en vaak goede) verbeteringen, zoals het op elkaar afstemmen van planningen en het samen optrekken bij risk en ‘control self assessments’. Aan de managers van ieder van die risico- en controlafdelingen gezamenlijk dus de opdracht om daar een passend en verder reikend antwoord op te vinden.

De GRC-scan

Zoals aangegeven, blijkt het inrichten van GRC in één omvangrijk en allesomvattend project vaak onhaalbaar. Derhalve pleiten wij ervoor om te starten met een GRC-scan om te bepalen op welke wijze een succesvolle uitrol van geïntegreerd GRC gerealiseerd kan worden. Hiermee worden de obstakels die een succesvolle uitrol in de weg staan, zoveel mogelijk vroegtijdig geïdentificeerd en kan een gefaseerde implementatie van GRC gestart worden binnen de ruimte die de organisatie daarvoor biedt.

Een aanpak tot een succesvolle uitrol van ‘geïntegreerd GRC’ start met het bepalen wat de huidige status is van GRC binnen de organisatie en het bepalen van het ambitieniveau van de organisatie ten aanzien van GRC (de gewenste status). Vervolgens is het belangrijk om inzicht te krijgen in welke onderdelen van GRC de meeste voordelen voor de organisatie als geheel opleveren. Deze voordelen kunnen in termen van geld worden gedefinieerd, maar ook in verhoging van transparantie, snelheid van besluitvorming, verlaging van redundante werkzaamheden en het minder ‘lastigvallen’ van de business. Door middel van het inzetten van de GRC-scan wordt de organisatie op een aantal aspecten doorgelicht. De uitkomsten van een dergelijke GRC-scan vormen mede de basis voor de op te stellen business case en het implementatieplan om gefaseerd en ‘gedragen’ tot geïntegreerde GRC over te gaan.

De GRC-scan beantwoordt op hoofdlijnen de volgende vragen:

  • Wat is de huidige status van GRC binnen de organisatie?
  • Wat is het ambitieniveau voor GRC?
  • In hoeverre is de organisatie klaar om te starten met GRC?
  • Wat zijn de stappen, en in welke volgorde, om het ambitieniveau te realiseren?

Door middel van gerichte interviews worden, aan de hand van een vragenlijst, bovenstaande aspecten inzichtelijk gemaakt. Alleen dan is de organisatie in staat de successen van GRC te extrapoleren naar meer successen voor de organisatie. De voordelen van de GRC-scan bestaan onder meer uit het gefaseerd ontwikkelen en uitrollen van de verschillende GRC-componenten. Hierbij is het van belang dat gestart wordt met die componenten waarvan de perceptie bestaat dat deze de meeste voordelen voor de organisatie, dan wel de ondersteunende risico- en controlfuncties opleveren. Afhankelijk van de veranderbereidheid van de verschillende functies en het belang dat de functies hebben bij het uitrollen van die componenten wordt een keuze gemaakt voor de volgorde van implementatie en wie betrokken worden bij de uitrol. Het inzichtelijk krijgen van de ‘quick wins’ is hierbij één van de belangrijke drivers voor verder succes. Tijdens de GRC-scan zal een analyse plaatsvinden van welke componenten relatief snel, eenvoudig en tegen relatief lage kosten te realiseren zijn. Deze quick wins zullen de weg vrijmaken voor de volgende successen.

Voor de uitvoering van de GRC-scan zijn alle GRC-activiteiten overzichtelijk en praktisch gegroepeerd in negen groepen en aan de hand van de vragenlijst inzichtelijk gemaakt. Deze activiteitgroepen bevatten activiteiten die binnen iedere governance-, risk- en controlfunctie aan bod komen, echter veelal ieder op een eigen specifieke manier worden ingevuld. Deze negen activiteitengroepen sluiten volledig aan op KPMG’s holistisch GRC-model. Echter, het holistisch GRC-model gaat niet uit van de groepering van activiteiten, maar van de opvolgende inrichtings-, uitvoerings- en resultaatcomponenten van GRC. Zie figuur 5 voor de activiteitengroepen voor de GRC-scan. Door de status, ambitie, veranderbereidheid en voor- en nadelen voor de organisatie op elk van deze gebieden te bepalen, kan een bewuste keuze worden gemaakt voor hoe het groeipad naar een geïntegreerde GRC-omgeving eruit kan zien op voor de organisatie herkenbare onderdelen.

Deze activiteitengroepen betreffen:

  1. Strategie & missie. Deze component gaat nader in op elementen als aansluiting van bedrijfsdoelstellingen op de risk appetite en het algemene ambitieniveau ten aanzien van risico-integratie. Verder wordt het risicobusinessmodel hier verder vormgegeven alsook de communicatie naar de rest van de organisatie.
  2. Charters. Bij deze component gaat het met name om het nader structureren van functies, rollen, taken, verantwoordelijkheden en inzet van resources en andere hulpmiddelen.
  3. Planning. Deze component behelst de wijze waarop de planning van activiteiten van ieder van de functies plaatsvindt en de mate waarin hier integratie kan plaatsvinden, dan wel een verbeterde samenwerking.
  4. Risk & Control Self Assessments. Deze component gaat nader in op inzet en status van RCSA’s binnen de organisatie, zowel voor nieuwe producten, voor review van bestaande processen als voor incidenten.
  5. Databases (voor issues, losses en events). Deze component betreft met name de kwaliteit van beschikbare gegevens, toegankelijkheid van gegevens en het hebben van een stand-alone of geïntegreerde IT-oplossing.
  6. IT. Deze component gaat nader in op de huidige IT-infrastructuur in termen van platformen, applicaties en overige IT-gerelateerde oplossingen en de gewenste IT-oplossingen, zoals de inzet van GRC-software en het laten draaien van de risico- en controlfuncties op dezelfde server waardoor uitwisseling van data gemakkelijker kan plaatsvinden.
  7. Risk & Control Framework. Deze component bekijkt met name de aanwezige control frameworks, de overlap en integratie en inzet van GRC-tools.
  8. Rapportages. Deze component betreft vooral de rapportagestructuren, kwaliteit en snelheid van rapportering en beschikbaarheid van juiste, tijdige en volledige informatie om geïnformeerd keuzen te maken en besluiten te nemen.
  9. Cultuur & gedrag. Deze component gaat nader in op de veranderbereidheid binnen ieder van de functies, de cultuur en het gedrag ten aanzien van GRC en de wijze waarop medewerkers met hun verantwoordelijkheden omgaan.

C-2010-1-Beugelaar-05

Figuur 5. De componenten van KPMG’s GRC-scan. [Klik hier voor grotere afbeelding]

Als de huidige status en de gewenste status bepaald zijn en ieder van de gebieden is beoordeeld naar de mate waarin het bijdraagt aan de doelstellingen van de organisatie als geheel, dan kan de weg naar het ambitieniveau uitgestippeld worden (de roadmap). Zowel de voordelen van geïntegreerd GRC als de obstakels zijn dan, voor ieder van de gebieden, inzichtelijk. Als voorbeeld is voor het gebied ‘Strategie & missie’ in figuur 6 een overzicht opgenomen van de mogelijke obstakels en voorbeelden.

C-2010-1-Beugelaar-06

Figuur 6. Mogelijke voordelen en obstakels – Strategie & missie.

Voor ieder van de gebieden worden deze gepercipieerde voordelen en obstakels uitgezet in een grafiek (zie figuur 7), waarbij de gebieden die in de linker bovenhoek belanden de hoogste ‘benefits’ voor de organisatie opleveren terwijl bij de implementatie de minste obstakels worden voorzien. Met deze gebieden zal dus gestart moeten worden bij het ontwikkelen en uitrollen van GRC.

C-2010-1-Beugelaar-07

Figuur 7. Prioritymatrix voor GRC.

De voordelen en voorwaarden voor een geslaagde uitrol van geïntegreerd GRC

De grote vraag is nu wanneer de uitrol van geïntegreerd GRC als geslaagd kan worden aangemerkt. De belangrijke kenmerken van een geslaagde uitrol zullen gemeten moeten worden aan de hand van de realisatie van de opgestelde business case. Op basis van diverse GRC-implementaties in de praktijk komen veelal de volgende voordelen naar voren ([KPMG]):

  • Organisaties die met GRC hun business performance verbeteren zullen merken dat zij hun flexibiliteit verhogen om veranderingen in de omgeving op te vangen, terwijl zij in staat zijn de ‘corporate’ reputatie te verbeteren en te bouwen aan verbetering van aandeelhouderswaarde.
  • Samenwerking tussen internal audit-, risk management- en compliancegerelateerde functies verbetert waardoor eerstelijnsmanagement minder belast wordt met vragen en functies die overlappend zijn.
  • Door inzet van GRC-software en continuous monitoring / auditing software verbetert het inzicht in de mate van beheersing van processen, risico’s, issues en kan door middel van ‘executive dashboards’ online inzicht gegeven worden in de huidige status. Daarnaast kunnen kosten verder gereduceerd worden door het gezamenlijk optrekken van diverse functies die deze dashboards combineren.
  • Door meer geïntegreerde risk en control frameworks wordt de overlap in activiteiten gereduceerd en kan de hoeveelheid controls omlaag, dan wel zal door een rationalisatie in controls de business minder worden belast.
  • De organisatie is beter en aantoonbaar ‘in control’.
  • De organisatie kan flexibel en snel inspelen op veranderingen in omstandigheden in de omgeving (maar ook intern) op gebieden zoals wet- en regelgeving, behoeften van klanten en nieuwe producten.

Praktijkcasus

Bij een grote internationaal opererende financiële instelling is ervoor gekozen om voor enkele van de risico- en controlafdelingen te zoeken naar verhoging van de effectiviteit en efficiëntie van de interne beheersing door de samenwerking tussen deze afdelingen te verbeteren dan wel integratie te realiseren. Zeven van de tweede- en derdelijnsafdelingen (Inspectie, Operational Risk Management, Compliance, SOx, IT Security, Processmanagement en Internal Audit) deden mee aan dit initiatief. Op zes onderdelen zijn significante verbetermogelijkheden geïdentificeerd waardoor de effectiviteit van de interne beheersing en de efficiency van risicomitigering een positieve impuls lieten zien. Het betrof hier 1) de integratie van de charters, 2) het integreren van de risico- en control frameworks, 3) de inrichting van een GRC-applicatie, 4) de verdere afstemming van de risk & control selfassessmentactiviteiten, 5) het rationaliseren van de issue-, loss- en incidentdatabases en 6) de totstandbrenging van een Non-Financial-Risk reporting.

Aan de hand van een opgestelde business case en roadmaps voor verdere implementatie zijn de volgende voordelen als leidend aangedragen:

  • Verbeteren van risicogerelateerde beheersing door focus op key-controls en gebruikmaking van de beste risicomanagementmethodieken.
  • Verhogen van de centrale aansturing van risico- en beheersingsactiviteiten, met als gevolg het verlagen van verzekeringspremies, het verlagen van reputatierisico’s, en het verbeteren van een eenduidig zicht op risico’s.
  • Verhogen van de effectiviteit van de operationele activiteiten door efficiënt onderhoud van controls, reductie van de gelaagdheid in risicorapportages en het verlagen van het aantal IT-applicaties.
  • Kostenreductie in termen van verlaging van het aantal fte’s, gebruikmaking van eenzelfde IT-technologie en verlaging van redundantie.
  • Reductie van risico’s met als gevolg een betere resource-allocatie, verhoging van reactiesnelheid op incidenten en een verhoging van de risk awareness.

Als voorwaarden voor het behalen van deze voordelen en successen geldt evenwel dat een aantal aspecten geadresseerd dient te worden. Enkele van deze voorwaarden betreffen:

  • Veranderbereidheid van de managers en medewerkers binnen de verschillende functies (cultuur en gedrag).
  • Gefaseerde aanpak op basis van de uitkomsten van een GRC-scan, waardoor gestart wordt met die componenten die de hoogste verwachte benefits opleveren voor de organisatie.
  • Het inrichten van en invulling geven aan een gedegen communicatieplan, waardoor iedereen tijdig en transparant wordt geïnformeerd over de voortgang en wat de ontwikkelingen betekenen voor ieder individu.
  • Commitment vanuit de leiding van de organisatie. Zonder dit commitment zal een geslaagd GRC niet tot stand komen.
  • Tijd en geld beschikbaar maken om in GRC te investeren. GRC betekent dat een aantal zaken op het vlak van risico en control aanwijsbaar en rigoureus anders zal gaan. Hiervoor zal ontwikkeltijd en geld nodig zijn. Dit moet gebudgetteerd zijn en de hoogste leiding dient hiervoor de verantwoordelijkheid te nemen.
  • Changemanagement. Gedurende het gehele traject zal aandacht voor de veranderingen plaats moeten vinden. Zonder deze aandacht zullen mensen geneigd zijn door te gaan met hun huidige activiteiten en bang zijn voor hetgeen nieuw op hen afkomt.

Conclusie

Een geslaagd GRC is haalbaar. Door inzicht te krijgen in de huidige status van de verschillende GRC-componenten binnen de organisatie, het ambitieniveau van de organisatie ten aanzien van elk van deze GRC-componenten en de veranderbereidheid van de verschillende functies zal een gedegen advies kunnen worden gegeven over de te volgen stappen. Als ook nog de gepercipieerde obstakels beoordeeld zijn wanneer elk van de componenten ontwikkeld en uitgerold zal worden, ontstaat een duidelijk beeld van hoe de organisatie tot een geïntegreerd en geslaagd GRC kan komen.

De GRC-scan biedt hiervoor het juiste handvat. De resultaten leiden tot een gedragen en transparant implementatieplan (roadmap) waarbij gekozen wordt om te starten met die componenten die bij implementatie de minste obstakels ontmoeten, maar wel het beste voor de business zullen opleveren. Uiteraard zal een geslaagde implementatie uiteindelijk alleen tot stand komen als wordt voldaan aan enkele randvoorwaarden, zoals de uitrol van een gedegen communicatieplan en de commitment van de leden van de raad van bestuur.

Literatuur

[AMRR08] AMR Research, The future of GRC, 2008, presentation by John Hagerty.

[AMRR09] AMR Research, The GRC Imperative – A pragmatic Guide to Jumpstarting your GRC Project, November 2009.

[COSO09] Internal Control – Integrated Framework, Guidance on Monitoring Internal Control Systems, COSO, January 2009.

[Forr07] The Forrester Wave™: Enterprise Governance, Risk, And Compliance Platforms, Q4 2007, For Security & Risk Professionals.

[Gart09] Gartner, Magic Quadrant for Enterprise Governance, Risk and Compliance Platforms, Q3, 2009.

[Klum09] C. Klumper, Toepassing van de Monitoring component van het COSO-raamwerk, MAB, maart 2009.

[KPMG] KPMG, The evolution of risk and controls; from score-keeping to strategic partnering.

Data Leakage Prevention

De hoeveelheid digitale informatie binnen bedrijven, die ook in toenemende mate gevoelige informatie bevat, neemt dagelijks toe. Aangezien het lekken van gevoelige informatie, een data leakage incident, een grote impact kan hebben op zowel het bedrijf als de getroffen personen, is het belangrijk de juiste preventieve en recessieve maatregelen te nemen. Het nemen van maatregelen wordt meer en meer vanuit wet- en regelgeving afgedwongen. Om een data leakage incident te voorkomen is het belangrijk organisatorische maatregelen te nemen zoals het opstellen en implementeren van een informatiebeveiligingsbeleid en het classificeren van informatie. Naast het uitvoeren van de organisatorische maatregelen kan een Data Leakage Prevention (DLP)-softwarepakket helpen het risico van lekken te verkleinen.

Inleiding

De steeds grotere hoeveelheden digitaal opgeslagen (gevoelige) informatie in combinatie met een transparantere manier van werken binnen organisaties brengt een verhoogd risico tot lekken van deze informatie met zich mee. Het is immers steeds gemakkelijker om allerlei informatie te raadplegen en moderne communicatiemiddelen maken ook het uitwisselen steeds eenvoudiger. De gevolgen van data leakage kunnen enorm zijn. Stel, de gevolgen voor zowel het bedrijf als de getroffen personen eens voor wanneer creditkaartgegevens op straat komen te liggen. Het lekken van informatie gaat gepaard met flinke imagoschade en er kunnen aanzienlijke financiële gevolgen mee gemoeid zijn. Onderzoek heeft uitgewezen dat niet alleen het aantal incidenten toeneemt, maar dat ook de financiële gevolgen steeds groter worden. Het is dan ook niet verrassend dat ander onderzoek uitwijst dat databescherming één van de belangrijkste drijfveren is voor informatiebeveiliging.

In dit artikel wordt eerst een overzicht gegeven van de risico’s en gevolgen die gepaard gaan met het lekken van gevoelige informatie. Er zal onderscheid worden gemaakt tussen de oorzaken van het lekken en de gevolgen daarvan. Het belang om maatregelen te treffen zal worden geïllustreerd met gegevens uit relevant onderzoek en met praktijkvoorbeelden. In toenemende mate worden maatregelen ook afgedwongen vanuit wet- en regelgeving, en daarvan zal een kort overzicht worden gegeven. Daarna wordt ingegaan op de werking en het nut van Data Leakage Prevention (DLP)-softwarepakketten.

Risico’s, gevolgen en oorzaken

De meeste data leakage incidenten worden pas opgemerkt wanneer negatieve gevolgen optreden. Dit is precies de reden waarom het onmogelijk is de exacte omvang van het aantal data leakage incidenten te bepalen. Uit recentelijk door KPMG uitgevoerd onderzoek ([Mars09]) bleek dat alleen al in de laatste drie maanden van 2008 de persoonlijke gegevens van 47,8 miljoen mensen op straat waren komen te liggen in een totaal van 404 waargenomen incidenten.

Bij de term data leakage wordt vaak ten onrechte alleen aan hackers gedacht die (digitaal) inbreken om zo toegang tot gevoelige informatie te verkrijgen. Een minstens even belangrijke oorzaak van data leakage zijn de eigen medewerkers en zakenpartners. Bij het lekken van gevoelige informatie kunnen we onderscheid maken tussen de volgende vormen:

  • Onbewust lekken. Lekken als gevolg van een fout, bijvoorbeeld met e-mail waarbij de verkeerde bijlage of de verkeerde ontvanger wordt geselecteerd.
  • Bewust lekken. Werknemers die de regels kennen maar deze toch overtreden zonder dat ze uit zijn op persoonlijk gewin, bijvoorbeeld door gevoelige informatie naar een privéaccount te mailen met het oog op thuis werken.
  • Kwaadaardig lekken. Zowel een medewerker als een extern persoon kan hieraan ten grondslag liggen. Met voorbedachten rade informatie langs de beveiliging smokkelen met als doel persoonlijk gewin.

Het is niet altijd duidelijk wat allemaal als gevoelige informatie beschouwd kan worden. Erg breed uitgezet kan hierbij gedacht worden aan alle informatie die door een andere partij misbruikt kan worden voor persoonlijk of bedrijfsmatig gewin of waardoor het betreffende bedrijf er nadeel van kan ondervinden. In tabel 1 wordt onderscheid gemaakt tussen een aantal verschillende vormen van gevoelige informatie ([Herm09]).

C-2009-4-Vliet-t01

Tabel 1. Verschillende vormen van gevoelige informatie.

De gevolgen van een data leakage incident hangen af van het type data dat gelekt is, maar kan onderverdeeld worden tussen de gevolgen voor personen en de gevolgen voor bedrijven. Bij het lekken van persoonsgegevens kunnen de betreffende personen slachtoffer worden van identiteitsdiefstal. Bij identiteitsdiefstal is men uit op persoonlijk gewin door zich voor te doen als iemand anders. Het slachtoffer kan dan geassocieerd worden met acties welke hij of zij nooit heeft uitgevoerd. Voor bedrijven is het scala aan mogelijke gevolgen veel groter:

  • verlies van uitstraling en reputatieschade;
  • verlies van concurrentievoordeel;
  • vertrouwensverlies bij huidige en toekomstige klanten;
  • verlies in marktwaarde door vermindert aandeelhoudersvertrouwen;
  • boetes van privacyregulerende instanties;
  • compensatiekosten voor slachtoffers.

Buiten de directe gevolgen zijn er indirecte gevolgen. Door de opgelopen imagoschade hebben mensen minder vertrouwen in het bedrijf en zal het moeilijker zijn om nieuwe klanten te binden, hetgeen gepaard gaat met hogere marketingkosten. Het Ponemon Institute heeft in Amerika onderzoek gedaan naar de kosten per incident en kwam uit op een gemiddelde van $ 202 per gelekt record, waarvan $ 152 betrekking had op indirecte kosten ([Pone09b]).

Vanwege de wetgeving binnen de Verenigde Staten die het verplicht stelt om alle gevallen van data leakage waarbij persoonsgebonden informatie is gemoeid te melden, is het eenvoudig met voorbeelden uit Amerika te komen. Toch heeft ook een aantal incidenten in Nederland het nieuws weten te halen ([Spai08]).

C-2009-4-Vliet-t02

Tabel 2. Enkele voorbeelden van onbewuste data leakage incidenten binnen Nederland.

Uit de voorbeelden in tabel 2 valt op dat veel incidenten te maken hebben met persoonsgegevens of dat personen last van het lekken hebben ondervonden. Tevens valt het op dat enorme hoeveelheden gevoelige data onbewust worden gelekt en dat veel zaken aan het licht komen door goed oplettende burgers. In veel gevallen is het echter niet meer te achterhalen of er eerder al meer gegevens zijn gelekt.

Impact van de huidige economische crisis

Door het huidige economische klimaat waarbij meer mensen op straat komen te staan is de verwachting dat het aantal data leakage incidenten alleen maar verder zal toenemen. Onderzoek heeft uitgewezen dat ongeveer 59 procent van de vertrekkende werknemers bedrijfsdata steelt ([Pone09a]). Uit hetzelfde in de Verenigde Staten uitgevoerde onderzoek is gebleken dat slechts vijftien procent van de bedrijven een controle uitvoert op meegenomen papieren en elektronische documenten. De e-mailgeschiedenis en hardcopybestanden zijn het meest populair. Tevens wordt het risico tot lekken vergroot door bezuiniging op IT-kosten en IT-personeel ([OEDL09]).

Wetgeving en regulering

Ook wet- en regelgeving proberen meer grip te krijgen op het alsmaar groeiende probleem van data leakage. Het meest volwassen is de wet- en regelgeving in de Verenigde Staten. De belangrijkste regelgeving is gericht op incidenten waar persoonsgegevens mee gemoeid zijn of op bedrijven die werken met financiële of medische gegevens.

Hieronder is de belangrijkste wet- en regelgeving inclusief reguleringen vanuit de industrie zelf opgesomd.

  • Health Information Portability and Accountability Act (HIPAA). Wetgeving voor alle bedrijven die met medische gegevens te maken hebben, en die ook eisen aan de beveiliging van Protected Health Information (PHI) beschrijft.
  • Gramm Leach Bliley Act (GLBA). Wetgeving voor alle financiële organisaties inclusief bedrijven die financiële informatie ontvangen.
  • Data Breach Notification Laws. Wetgeving die het melden van data leakage incidenten waar persoonsgegevens mee gemoeid zijn, verplicht stelt. Momenteel van toepassing in 38 Amerikaanse staten.
  • Payment Card Industry Data Security Standard (PCI DSS). Wetgeving voor alle bedrijven die met creditcardgegevens werken of deze verwerken.

Op het gebied van de integriteit speelt ook de Sarbanes Oxley (SOx)-wetgeving, die deugdelijk bestuur van beursgenoteerde ondernemingen vereist, een rol. De SOx-wetgeving vereist onder andere een verantwoordelijke voor alle beschikbare informatie.

In Nederland is momenteel alleen de Wet bescherming persoonsgegevens (Wbp) ingevoerd, die omschrijft hoe organisaties moeten omgaan met persoonsgegevens en welke rechten de burgers hebben. Deze wet voorziet echter niet in het verplicht melden na het lekken van persoonsgegevens.

Onlangs is in de Europese Unie een voorstel gedaan om het melden van data leakage incidenten te verplichten. Dit voorstel, bekend onder de naam ‘the ePrivacy Directive’, is echter alleen van toepassing op elektronische communicatiediensten in publieke netwerken. Om deze reden heeft de Europese databeschermingstoezichthouder (EDPS) in een reactie laten weten de voorstellen niet ver genoeg te vinden gaan.

Hoe voorkom ik een data leakage incident?

Om het risico van het optreden van een data leakage incident te verkleinen dienen in eerste instantie organisatorische aanpassingen te worden gemaakt. De eerste stappen zijn het inventariseren welke data beschermd moeten worden, te bepalen hoe strikt het beleid moet worden en het beleggen van verantwoordelijkheden. Tevens is het van belang het beleid naar werknemers uit te dragen en werknemers te trainen om zo het informatiebeveiligingsbewustzijn te verhogen.

Naast het nemen van de juiste organisatorische maatregelen kunnen technische maatregelen zoals het aanschaffen en implementeren van een DLP-softwarepakket helpen bij het verkleinen van het risico tot het lekken van informatie.

De werking van een DLP-softwarepakket

Om het lekken van gevoelige informatie tegen te gaan richten DLP-softwarepakketten zich op data in drie verschillende stadia:

  • Data ‘in motion’. Alle data die zich over het netwerk verplaatsen, die ‘in beweging zijn’ zoals webverkeer, e-mail en Instant Messaging (IM)-berichten. De focus ligt hierbij op data die het bedrijfsnetwerk verlaten.
  • Data ‘at rest’. Alle data binnen het bedrijfsnetwerk die zijn opgeslagen op eindpunten, zoals op laptops, servers en databases.
  • Data ‘in use’. Alle data die in gebruik zijn, zoals het bewerken van een document of het kopiëren van een bestand naar een USB-stick.

De geanalyseerde data kunnen grofweg in twee categorieën worden ingedeeld. In het ideale geval betreft het ‘structured data’, data in een vooraf bekend formaat, zoals geboortedatum, creditkaartnummers en burgerservicenummers. Deze informatie kan met eenvoudige patroonherkenningstechnieken worden gedetecteerd. De meeste data zijn echter ongestructureerd, ‘unstructured data’, en zorgen voor een grotere uitdaging. Voor een stuk tekst in bijvoorbeeld een e-mail worden geavanceerdere technieken gebruikt, zoals conceptuele en taalanalyses, om de strekking van de tekst te achterhalen.

De meerwaarde van een DLP-softwarepakket

Er kunnen verschillende motieven ten grondslag liggen aan het besluit een DLP-softwarepakket aan te schaffen. De meest voor de hand liggende is het verlagen van het risico tot het openbaren van gevoelige informatie, maar ook op het gebied van kostenbesparing en het voldoen aan wet- en regelgeving kan een DLP-softwarepakket aanzienlijke meerwaarde leveren. Tevens kan het helpen bij meer zijdelingse aspecten zoals het ‘opvoeden’ van werknemers in het gebruik van en de omgang met (gevoelige) informatie. De belangrijkste gebieden waarop een DLP-softwarepakket meerwaarde aan een organisatie kan leveren zijn:

  • Compliancy met wet- en regelgeving. De meeste DLP-softwarepakketten bieden standaard de mogelijkheid templates (een set regels) te activeren die in lijn zijn met verschillende vanuit wet- en regelgeving gestelde eisen. Tevens kunnen er rapporten worden gegenereerd om de compliancy met de betreffende wet- of regelgeving aan te tonen.
  • Verhogen van het beveiligingsbewustzijn (trainen van medewerkers). Wanneer medewerkers het beveiligingsbeleid overtreden of dreigen te overtreden wordt de actie geblokkeerd en krijgt de medewerker hier melding van met uitleg van reden. Ook is het mogelijk een keuzemelding te genereren; medewerkers krijgen dan een waarschuwing waarna ze de betreffende actie kunnen annuleren of een keuze kunnen maken voor een vervolgactie zoals het versleutelen van het e-mailbericht of de bijlage. Op deze manier wordt het beveiligingsbeleid afgedwongen, leren werknemers van hun fouten en wordt beveiligingsbewustzijn onder werknemers verhoogd.
  • Kostenbesparing. Door de centrale managementinterface waar alle informatie wordt verzameld, is het veel gemakkelijker om het beleid af te dwingen en eventuele incidenten te analyseren. Tevens wordt het eenvoudiger om compliancy met wet- en regelgeving aan te tonen doordat compliancyrapporten eenvoudig gegenereerd kunnen worden.

DLP-softwarepakketten kunnen aanzienlijke meerwaarde bieden voor de informatiebeveiliging, maar kunnen niet alle incidenten voorkomen. Dergelijke softwarepakketten richten zich over het algemeen niet op aanvallen van hackers en bieden alleen bescherming tegen lekken van elektronische informatie.

Het implementeren van een DLP-softwarepakket

Het implementeren van een DLP-softwarepakket kan alleen succesvol worden wanneer eerst de noodzakelijke organisatorische aanpassingen worden doorgevoerd en wanneer realistische doelstellingen aan het DLP-product worden gesteld.

Op organisatorisch gebied dient begonnen te worden met het opstellen van een breed informatiebeveiligingsbeleid om dat vervolgens binnen de organisatie door te voeren. Bij het doorvoeren van het informatiebeveiligingsbeleid is het belangrijk de werknemers op de hoogte te brengen van het beleid, en nut en noodzaak om bewust met (gevoelige) informatie om te gaan kenbaar te maken. Binnen het informatiebeveiligingsbeleid dient te worden nagedacht over de waarde van verschillende typen informatie voor het bedrijf. Aan de hand van deze analyse kan dataclassificatie worden uitgevoerd en kunnen verschillende classificatieniveaus en overeenkomstige beveiligingsniveaus worden gedefinieerd. Per classificatie en beveiligingsniveau dienen autorisaties te worden gedefinieerd en autorisatietabellen te worden opgesteld. Belangrijk aspect hierbij is om niet alleen generieke autorisaties op te stellen; zo zullen de autorisaties op het bekijken en versturen (e-mailen) van contracten van werknemers binnen de afdeling Personeelszaken anders zijn dan op andere afdelingen. Na het in kaart brengen van het volledige informatiebeveiligingsbeleid en het definiëren van alle autorisaties kan worden begonnen met de implementatiefase.

Gedurende de implementatiefase van het DLP-product is de eerste stap het product te configureren aan de hand van het gedefinieerde beleid en de opgestelde autorisaties. Nadat het product enige tijd heeft gedraaid moet de werking worden geëvalueerd en waar nodig de configuratie worden bijgesteld. Dit proces wordt herhaald totdat het DLP-product naar wens werkt. Tevens is belangrijk ook bij de implementatiefase de medewerkers die mogelijk met meldingen van het DLP-product geconfronteerd worden, hiervan op de hoogte te stellen.

C-2009-4-Vliet-t03

Tabel 3. Overzicht van enkele DLP-softwarepakketproducenten.

Conclusie

De alsmaar groeiende hoeveelheid digitale informatie binnen bedrijven en tegelijkertijd de toename van (moderne) digitale communicatiemedia stelt bedrijven voor een grote uitdaging gevoelige informatie binnen hun grenzen te houden. Het nemen van maatregelen wordt enerzijds afgedwongen door de afschrikkende werking van de enorme (financiële) gevolgen die data leakage incidenten met zich mee kunnen brengen en anderzijds door toenemende wet- en regelgeving op het gebied van data retention en privacy.

Het huidige economische klimaat heeft de noodzaak tot het nemen van effectieve maatregelen alleen maar vergroot. Veel medewerkers die bedrijven verlaten nemen gevoelige informatie mee, en nu door de economische crisis meer medewerkers bedrijven verlaten is het risico tot het lekken van gevoelige informatie groter geworden. Tevens drukt de economische crisis op de beschikbare IT-budgetten en het IT-personeel.

De aanschaf van een DLP-softwarepakket kan een effectief middel zijn ter voorkoming van een data leakage incident. Deze softwarepakketten bieden bescherming door zich te richten op data die zich verplaatsen, opgeslagen zijn of in gebruik zijn. Deze data worden vervolgens met geavanceerde technieken geanalyseerd op overeenstemming met de vooraf ingestelde regels. Buiten het beschermen tegen data leakage incidenten bieden DLP-softwarepakketten tevens voordelen bij het voldoen aan wet- en regelgeving, het aantonen van compliancy en het verhogen van het informatiebeveiligingsbewustzijn onder de werknemers.

Ondanks alle voordelen dient men zich te realiseren dat ook DLP-softwarepakketten hun beperkingen hebben. Zij richten zich niet op kwaadaardige aanvallen van hackers en bieden alleen bescherming tegen het lekken van elektronische informatie. Desondanks kan een DLP-softwarepakket een effectief middel zijn tegen het ongewenst naar buiten komen van gevoelige informatie.

Literatuur

[EGDL09] The Executive Guide to Data Loss Prevention, Securosis LLC, March 2009.

[Herm09] Ing. J.A.M. Hermans en drs. J.W. de Jong, Information Leakage Prevention – Putting your information first, KPMG IT Advisory, 2009.

[Mars08] M. Marshall, M. Martindale, R. Leaning en D. Das, Data Loss Barometer, KPMG, September 2008.

[Mars09] M. Marshall, M. Martindale en R. Leaning, Data Loss Barometer; Review of 2008 and Predictions for 2009, KPMG, 2009.

[OEDL09] Outbound Email and Data Loss Prevention in Today’s Enterprise, Proofpoint, 2009.

[Oule09] E. Ouellet en P.E. Proctor, Magic Quadrant for Content-Aware Data Loss Prevention, Gartner, 2009.

[Pone09a] Dr. L. Ponemon, Data Loss Risks During Downsizing; As Employees Exit, so does Corporate Data, Ponemon Institute LLC, 2009.

[Pone09b] Dr. L. Ponemon, Fourth Annual US Cost of Data Breach Study; Benchmark Study of Companies, Ponemon Institute LLC, 2009.

[Spai08] K. Spaink, Dutch Data Breaches, http://www.spaink.net/dutch-data-breaches/, 2009.

[Vlie08] A.H.P. van Vliet, Data Leakage and It’s Prevention, TU Delft, September 2008.

Invoering van één toegangspas

In 2008 is binnen KPMG Nederland een nieuwe identiteitspas ingevoerd voor de fysieke toegangscontrole. Na de invoering van persoonsgebonden certificaten op de contactchip van de pas, de corporate identiteitspas, zijn daar begin 2009 IT-beveiligingstoepassingen aan toegevoegd.

De invoering van de kaart is nagenoeg uniek door de landelijke invoering voor alle medewerkers en voor alle kantoren. De leermomenten uit de praktijk bij invoering van deze hybride corporate identiteitspas met persoonsgebonden certificaten en met gebruikmaking van een Managed PKI, worden in dit artikel met u gedeeld.

Inleiding

In dit artikel wordt ingegaan op de invoering van de corporate identiteitspas binnen KPMG Nederland. Deze kaart is voor medewerkers zowel de fysieke toegangspas tot gebouwen en ruimten alsook de elektronische identiteitspas voor gebruik van IT-beveiligingsfuncties.

Voor de IT-beveiligingsfuncties is de kaart voorzien van een contactchip met certificaten en is een Managed Public Key Infrastructuur gerealiseerd ([Getr05]). Vanuit de IT Security dienstverlening van KPMG is dit artikel deels een voorbeeld van ‘Drinking Your Own Champagne’ ([KPMG07]).

Ten aanzien van de corporate identiteitspas verschilt KPMG niet van andere organisaties, met dezelfde interne issues bij het streven naar en de realisatie van verbeteringen in de interne bedrijfsvoering door inzet van informatietechnologie en door integratie van processen en diensten.

De interne beschikbaarheid van de juiste kennis en ervaring op dit gebied heeft de afgelopen jaren bijgedragen aan het huidige succesvolle resultaat, een geïntegreerde aanpak voor één identiteitspas voor fysieke én IT-beveiligingstoepassingen.

Allereerst wordt in dit artikel kort de voorgeschiedenis geschetst die leidde tot de uiteindelijke ontwikkeling en realisatie van de Public Key Infrastructuur (PKI) met de corporate identiteitspas als drager. Daarna wordt de ontwikkeling beschreven, eerst door kenmerkende werkwijzen en achtereenvolgens aan de hand van het invoeringstraject, de processen en de technologie. Enkele belangrijke leermomenten uit het interne ontwikkelingstraject volgen dan onder de kop ‘Lessons learned’. Afgesloten wordt met conclusies voor ontwikkelingen van vergelijkbare corporate identiteitspassen.

Historie en uiteindelijke business case

In het begin van dit millennium werd binnen KPMG al gewerkt aan de opzet van een eigen PKI. Net als de jaren daaropvolgend waren echter de business cases ieder afzonderlijk te klein om de noodzakelijke investering te rechtvaardigen en konden verschillende potentiële PKI-toepassingen – zoals de interne verwerking van gevoelige (HR-) gegevens, communicatie met externe partijen waaronder banken en de AFM en gebruik van extranetten – onvoldoende worden samengevoegd tot één sluitende overall business case.

Behalve de kosten beperkte ook het geringe aantal toepassingen waarbinnen gebruik kon worden gemaakt van certificaten de invoering. Ook de PKI-technieken en -diensten waren minder uitontwikkeld dan tegenwoordig, waardoor te veel specifieke aanpassingen nodig waren om applicaties eenvoudig geschikt te maken voor eindgebruikers.

Vanaf 2005/2006 werd één toepassing, beveiligd e-mailen, in toenemende mate een drijfveer voor ontwikkeling van de certificaatinfrastructuur binnen KPMG Nederland ([Meen01]). Deeloplossingen voor beveiligd e-mailen waren wel al voorhanden, maar aspecten als gebruiksgemak, digitale ondertekening en beveiliging tot en met de mailbox werden hiermee onvoldoende ingevuld.

In verschillende achtereenvolgende pilots is vervolgens kennis en ervaring opgebouwd over beveiligd e-mailen met verschillende technieken, wijzen van implementeren en het gebruik van certificaatdiensten binnen de eigen IT-omgeving. Daarbij werden behalve ondersteuning van de gebruikers voor naleving van het e-mailbeleid ook andere toepassingen bekeken, met name het ondertekenen van (pdf-)documenten en verbetering van interne processen waarbinnen strikt vertrouwelijke informatie wordt verwerkt.

IT-ontwikkelingen

Verschillende IT-ontwikkelingen vormden uiteindelijk – gecombineerd met beveiligde e-mail – de aanzet tot de finale ontwikkeling, de realisatie van de Managed PKI-dienstverlening met gebruikmaking van de toegangspas als drager voor de certificaten.

Belangrijke ontwikkelingen waren de invoering van draadloze netwerken en de uitvoering van het ICT/communicatiebeleid. Voor het gebruik van draadloze netwerken binnen kantoren is het gebruik van certificaten een vereiste vanuit dit beleid. Uitvoering van het communicatiebeleid – connectivity at any place, any where en Single Sign-On voor de werkplek – resulteerde in de wens tot één uniform authenticatiemiddel.

Door de toegenomen kennis van en ervaring met andere Managed PKI-diensten, zoals voor SSL/TLS-servicecertificaten voor beveiliging van e-mail tussen organisaties, was de jaren daarvoor ook de kennis en ervaring in de organisatie over PKI in de breedte toegenomen.

Een overkoepelend programma ter algehele verbetering van de IT-infrastructuur vormde tenslotte het organisatorische en financiële vehikel waarbinnen de plannen uiteindelijk werden uitgevoerd. Binnen dit programma werd de samenwerking tussen facilitaire dienst en de IT-organisatie verankerd binnen verschillende deelprojecten. De nieuwe dienst is duidelijk neergezet als onderdeel en uitbreiding van de basis IT-infrastructuur.

Als laatste, maar zeker niet de minst belangrijke reden voor de uiteindelijke ontwikkeling van de dienstverlening moeten de acceptabele prijsstelling voor de certificaten en de daling van de kosten voor realisatie worden genoemd. Dit laatste in het bijzonder door gebruik van zo veel mogelijk standaardsystemen en outsourced en/of managed services. In figuur 1 zijn de interne en uitbestede systeemcomponenten aangegeven.

C-2009-4-Veltmeijer-01

Figuur 1. Belangrijkste systemen voor productie van certificaten op de corporate identiteitspas.

Ontwikkeling

Zowel voor de ontwikkeling van een bedrijfsbrede PKI alsook voor de ontwikkeling van een identiteitspas waren de risico’s bekend ([Naza01], [Velt01]). Om bekende risico’s bij de ontwikkeling zoveel mogelijk te vermijden werden eerst de ervaringen uit voorgaande pilots vastgelegd in uitgangspunten, randvoorwaarden en verdere afbakening van de scope.

Deze werden vooraf besproken met de potentiële leverancier van de certificaatdiensten. Daarbij werden ook de visie en te volgen werkwijze definitief afgestemd. Hierdoor kon worden gewerkt met een ambitieuze tijdsplanning. Kernpunten van de gevolgde werkwijze daarbij zijn:

  • De toepassingen waarbinnen certificaten de eerste twee jaar zouden (kunnen) worden ingezet, werden expliciet benoemd. Tijdens de gehele ontwikkeling werd rekening gehouden met het (toekomstige) gebruik binnen deze toepassingen. Elk ander mogelijk gebruik werd resoluut buiten het project geparkeerd.
  • Enkel het volledige gebruik en beheer voor de eerste toepassing, beveiliging van e-mail, werd volledig uitgewerkt in het project. Ten aanzien van andere initieel bepaalde toepassingen werd in zoverre gekeken naar het gebruik en beheer dat de tijdens de ontwikkeling te maken keuzen daar geen negatieve invloed op zouden hebben.
  • Er werd een strakke fasering aangehouden waarin na realisatie van het ontwerp snel een basisinfrastructuur aanwezig moest zijn om certificaten op de identiteitspas geplaatst te hebben. Dit diende gerealiseerd te zijn voordat de nieuwe pas ten behoeve van de fysieke toegangscontrole aan gebruikers zou worden verstrekt.
  • Ten aanzien van het waarborgen van het betrouwbaarheidsniveau van de gehele PKI is het altijd bepalend geweest dat de uit te geven certificaten eenvoudig zouden moeten zijn op te waarderen tot gekwalificeerde certificaten (certificaten die voldoen aan eisen die vanuit de Wet Elektronische Handtekening worden gesteld om een elektronische handtekening te kunnen plaatsen die dezelfde rechtsgevolgen heeft als een handgeschreven handtekening).

    Duidelijk was dat een definitieve keuze voor gekwalificeerde certificaten financieel niet haalbaar zou zijn voor de beoogde brede uitrol. Afhankelijk van andere externe ontwikkelingen zouden gekwalificeerde certificaten in de toekomst wel een eis kunnen zijn voor bepaalde doelgroepen en nog te realiseren gebruik.

    Voorbeelden van keuzen die hieruit voortkomen zijn de keuze van de smartcard als SSCD (Secure Signature Creation Device) en de keuze van een provider die tevens gekwalificeerde certificaten kan leveren conform de eisen van de PKI-Overheid ([Wals02]).

Invoering

Toegangspas

Binnen het programma ter verbetering van de IT-infrastructuur waren onder andere de volgende twee deelprojecten gedefinieerd: 1. invoering van een nieuw toegangscontrolesysteem met de nieuwe toegangspas, en 2. invoering van de elektronische identiteitspas. Hierdoor konden op het juiste moment de eisen en wensen binnen de separate ontwikkelingstrajecten worden afgestemd. Voorbeelden waarbij de afstemming essentieel was zijn: de keuze om alle medewerkers te voorzien van de nieuwe kaart, de keuze voor embedding van de contactchip op de kaart en de initieel batchgewijze productie van de kaart en de certificaten.

Gedurende 2008 werd de nieuwe toegangspas per locatie uitgerold. De basisinfrastructuur was nog niet gereed op het moment dat de passen voor de eerste drie locaties werden uitgerold. Hierdoor waren separate terugroepacties nodig om de passen te voorzien van certificaten en sleutels.

Elektronische corporate identiteitspas

Op grond van eerdere ervaringen bij invoering van PKI voor beveiliging van e-mail, is er veel aandacht besteed aan de invoering bij de eindgebruikers. Voor gebruikers diende de invoering van de beveiligingsfuncties zo transparant mogelijk plaats te vinden, met een absoluut minimum aan verstoring van werkzaamheden en zo gebruiksvriendelijk mogelijk.

Zo is al in een zeer vroeg stadium een smartcardlezer toegevoegd aan de eisen voor nieuwe laptops. Hierdoor waren ruim voor de invoering de meeste gebruikers in stilte – via reguliere vervangingen van laptops – voorzien van een kaartlezer. Overige pc’s werden naderhand voorzien van losse smartcardlezers.

Bij de uitrol van de fysieke toegangspas – eventueel via separate terugroepacties – was deze pas (de nieuwe corporate identiteitspas) voorzien van persoonlijke certificaten. Pas nadat alle gebruikers waren voorzien van de nieuwe elektronische identiteitspas en nadat de laatste aanpassingen in de infrastructuur hadden plaatsgevonden, werden de pincodes verstuurd en werd breed gecommuniceerd over de ‘Corporate ID-Smartcard’ en de eerste toepassing, het beveiligen van e-mail.

Toepassingen

De uitrol vond plaats in het kader van de nieuwe functionaliteit, het beveiligd e-mailen met gebruikmaking van de certificaten op de corporate identiteitspas. De overige geplande toepassingen werden daarbij enkel kort benoemd.

De beveiligde e-mailapplicatie bepaalde het gezicht, en daarmee voor een groot deel de acceptatie, van de identiteitspas bij de gebruikers. Om een zo breed mogelijke acceptatie te realiseren is bij invoering veel aandacht uitgegaan naar ondersteuning van het gebruik voor de applicatie. Aspecten die daartoe bijdroegen waren:

  • Vrijwillig gebruik van de pas bij invoering en gebruik voor de eerste applicatie. Het accent lag op het ondersteunen van gebruikers bij invulling van het beleid ten aanzien van het beveiligd versturen van e-mail.
  • Gerichte communicatie over de nieuwe mogelijkheden met doelgroepen waarvan bekend was dat ze er veel voordeel bij konden hebben in hun dagelijkse werkzaamheden en voor verbetering van de interne processen.
  • Ondersteuning door het hoogste management in de vorm van een voortrekkersrol bij daadwerkelijk brede verspreiding van beveiligde interne e-mail.
  • Verbeterde communicatie over de verschillende mogelijkheden om e-mail te beveiligen. De pas is niet in alle situaties de optimale oplossing voor beveiliging van e-mail. Door per situatie alternatieven aan te reiken wordt voorkomen dat de pas als het nieuwe verplichte IT-middel of ‘speeltje’ van de IT-organisatie wordt gezien.

Door de wijze van geleidelijke invoering van de kaart is deze invoering in zekere zin pas afgerond als er binnen alle geplande toepassingen gebruik van kan worden gemaakt. Het begeleiden en stimuleren van gebruik binnen processen en toepassingen gaat tot die tijd door.

Processen

Het tijdspad bij invoering van de persoonlijke certificaten werd in grote mate bepaald door de invoering van de fysieke toegangspas. Dit was weliswaar voortgekomen uit de noodzaak om tot één identiteitspas te komen, maar bood in praktijk het voordeel van de juiste tijdsdruk om op tijd de basisinfrastructuur gereed te hebben (zie ook ‘Lessons learned’).

Daardoor was er onvoldoende tijd om de processen in detail uit te werken en te integreren in bestaande levenscyclusprocessen van de toegangspas. De processen voor de certificaatdiensten werden separaat opgezet – met kennis over de bestaande smartcard levenscyclusprocessen – en naderhand gecombineerd met de reeds bestaande processen binnen de facilitaire dienst. Door de centrale benadering van beide processen en fysiek nabije huisvesting van beide organisatieonderdelen verliep dit zonder al te veel problemen. Hierdoor is wel – uit noodzaak – een gescheiden ontwikkeling van de productie en processen voor de fysieke toegangspas en voor de certificaten ontstaan. In de praktijk is dit een succesfactor gebleken voor een efficiënte en effectieve opzet, realisatie en invoering van de gecombineerde CID-Smartcard. Voor regulier beheer van de gecombineerde kaart is dit echter geen wenselijke situatie.

Met de toename van de kennis en ervaring van de processen en systemen bij beide organisatieonderdelen wordt daarom voorzien dat de reguliere kaartprocessen geheel door één dienst (facilitair) zullen worden uitgevoerd. Door de benodigde specialistische kennis van informatiesystemen en certificaatdiensten zal voor de tweedelijnsondersteuning de IT-organisatie verantwoordelijk blijven. Gepland staat dan ook een uitvoering van het gehele productieproces onder één verantwoordelijk organisatieonderdeel. Op termijn zal de volgende integratiestap, combinatie van de twee verschillende productiesystemen in één systeem, eenvoudig te realiseren zijn door de opgedane ervaring.

De afstemming binnen het gehele proces tussen alle betrokken partijen, intern en extern, zal de komende periode vooralsnog een belangrijk aandachtspunt blijven om het proces verder te verbeteren.

Technologie

In deze paragraaf worden de belangrijkste technische kenmerken van de geïmplementeerde corporate identiteitspas opgesomd. Enige basiskennis van PKI is daarbij handig maar niet noodzakelijk voor begrip van het gehele artikel.

  • De identiteitspas is voorzien van twee antennes ter ondersteuning van diverse systemen voor fysieke toegangscontrole en een contactchip voor de IT-beveiligingsfuncties. De pas is verder voorzien van een pasfoto, de naam van de pashouder en een holografische laag.
  • Op de contactchip van de identiteitspas bevinden zich drie certificaat/private key paren: voor digitaal ondertekenen (signing), voor versleutelen (encryption) en voor authenticatie (client authentication / smartcard-logon). In figuur 2 is de PKI-hiërarchie weergegeven.
  • De signing- en encryptioncertificaten worden uitgegeven binnen één publieke PKI (Getronics/Verisign). Doordat de root Certificate Authorities (CA’s) van deze PKI door de meeste systemen als trusted worden aangemerkt, is daarmee geborgd dat er voor externe uitwisseling van beveiligde e-mail en documenten geen extra trustrelaties hoeven te worden gerealiseerd. Het wel of niet functioneren van de externe uitwisseling wordt verder bepaald door de ondersteuning van (persoonlijke) certificaten binnen de specifieke toepassing in de externe IT-omgeving.
  • Het authenticatiecertificaat wordt uitgegeven binnen een private PKI. Aanloggen met de corporate identiteitspas op willekeurige informatiesystemen is immers enkel wenselijk indien de trust expliciet is aangebracht. Publicatie van revocations (intrekking of herroeping van de geldigheid van een certificaat) voor externe partijen is ook niet noodzakelijk, in tegenstelling tot de onder een publieke PKI uitgegeven certificaten.
  • De certificaat/sleutelparen worden alle drie in alle lifecycle- en beheerprocessen als één geheel verwerkt. Zo worden ze alle drie bij productie gelijk op de kaart geplaatst en heeft een intrekking van de kaart een revocation van alle drie de certificaten tot gevolg. Het enige punt waarbij een certificaat individueel wordt verwerkt, is de recovery van het encryptiecertificaat. Voor specifieke recoveryverzoeken kan het encryptiecertificaat op een blanco kaart worden geplaatst volgens strikte procedures.
  • Bij vervanging van de pas worden de certificaten automatisch vernieuwd en worden oude encryptiecertificaten op de pas bijgeplaatst.
  • De geldigheidstermijn van de certificaten is gelijkgesteld aan de vervangingsperiode van de fysieke pas om de overlast van extra verwerkingen voor gebruikers te minimaliseren.
  • De essentiële PKI-componenten zoals alle CA’s en het certificaatbeheersysteem worden gehost en beheerd door Getronics. KPMG heeft een Registration Authority (RA)-deelrol die technisch wordt ingevuld met een dedicated werkstation voor het certificaatbeheersysteem. Dit werkstation is verder voorzien van de nodige kaartlezers, een kaartprinter voor productie van de certificaten en een printer voor de pinmailers.
  • Binnen het Certificaat Management Systeem zijn naast de gebruikersrol – voor productie van de certificaten – onder andere rollen gedefinieerd voor het resetten van pincodes door de helpdesk en rollen voor het verwerken van vertrouwelijke informatie en het uitvoeren van specifieke beheerhandelingen.

C-2009-4-Veltmeijer-02

Figuur 2. De PKI-hiërarchie met signing- en encryptioncertificaten uitgegeven onder een public PKI en authentication/smart card-logoncertificaten uitgegeven onder een private PKI.

Lessons learned

Hieronder worden enkele leermomenten aangegeven uit het ontwikkelings- en invoeringstraject van de corporate identiteitspas bij KPMG.

Het feit dat op veel deelgebieden de kennis en ervaring binnen de organisatie aanwezig is betekent niet automatisch dat genoemde punten en gerelateerde risico’s konden worden voorzien of konden worden voorkomen. Daarvoor zijn er te veel omgevingsfactoren en relaties met andere (interne) ontwikkelingen die niet konden worden beïnvloed, zoals het ontstaan van een economische crisis gedurende het project.

De totale opzet en invoering van de elektronische identiteitspas had uiteindelijk een doorlooptijd van ruim één jaar. Met de juiste aandacht voor de hieronder opgesomde punten is het zeker mogelijk om binnen één jaar tijd, vanaf scratch, een volledige public key infrastructuur – gecombineerd met een smartcard als drager van de certificaten – op te zetten en in gebruik te nemen.

Scoping

Definieer vooraf een duidelijke scope en baken deze verder af met duidelijke uitgangspunten en randvoorwaarden. Definieer ook de voorwaarden waaronder hiervan mag worden afgeweken. Dit punt is een grote open deur maar des te belangrijker gebleken door de wijze waarop het project voordeel heeft gehad bij de gezamenlijke visieontwikkeling met de leverancier, de duidelijke afspraken vooraf en de daardoor vliegende start.

Projectfasering, projectteam en samenwerking

Breng een projectfasering aan waarin eerst de basis-PKI wordt gerealiseerd waarin wel in grote lijnen de processen en toepassingen worden bepaald, maar waarin deze nog niet in detail worden uitgewerkt.

Voorwaarde voor succes hierbij is wel dat in het projectteam de juiste expertise – technisch, organisatorisch, en processen – aanwezig is om de (nadelige) gevolgen van keuzen in deze fase voor latere fasen te kunnen inschatten. Tevens dient het projectteam de juiste beslissingsbevoegdheid te hebben om snel adequate keuzen te kunnen maken.

Beschikbaarheid van de basisinfrastructuur was een noodzaak om de certificaten te kunnen produceren voordat deze werden verstrekt aan de gebruikers. Deze tijdsafhankelijkheid noodzaakte het project geheel te focussen op de technische realisatie en om op tal van punten snel keuzen te maken met de in het project beschikbare kennis.

Hierdoor werden discussies over onderling afhankelijke infrastructurele, proces- en applicatie-issues beperkt tot de essentie. In daaropvolgende fasen werden vervolgens de processen en het gebruik binnen de applicaties gedetailleerd ingevuld en geïmplementeerd.

De standaardisatie, en daarmee de koppeling van verschillende PKI-technieken is de laatste jaren sterk toegenomen. Desondanks vergde de ontwikkeling van de interfaces naar de verschillende componenten op het laatst – vlak voor uitrol – meer tijd dan gepland. Korte beslissingslijnen waren daarbij essentieel voor goede communicatie naar het project, de beheerorganisatie en de gebruikers.

Uitbesteding / Managed dienstverlening

In de aanloop van het project in 2007 werd in andere internationale onderdelen van de organisatie gewerkt aan een interne PKI, voornamelijk voor gebruik binnen de eigen IT-infrastructuur. Met name door de bredere toepasbaarheid van de certificaten en snellere implementatiemogelijkheden is toch gekozen voor het uitbesteden van de PKI-diensten. Deze keuze, en de keuze voor de aanbieder van Managed PKI-diensten is essentieel geweest voor het succesvolle resultaat ([Getr05]).

Het binnen het project samenvoegen van de ervaring, expertise en kunde van eigen medewerkers en die van de leverancier in het project heeft geleid tot een managed service die met de beschikbare middelen niet binnen de eigen organisatie gerealiseerd en beheerd had kunnen worden. Net als bij outsourcing van andere IT-diensten dient de eigen organisatie wel over de juiste kennis te beschikken om de regie te blijven voeren tijdens de ontwikkeling en om in control te blijven over de beheerdiensten.

Behalve de voordelen van tijdwinst en kosten zijn de mogelijkheden voor aanpassingen en uitbreiding van de PKI-diensten, met behoud van betrouwbaarheidsniveau van certificaten, een voordeel gebleken van de uitbestede dienst.

Aanvraag-, uitgifte- en beheerprocessen

Niet nieuw, maar toch zinvol om hierbij te benoemen zijn de volgende, meest opvallende leermomenten:

  • Blijf altijd streven naar een eenvoudig en uniform aanvraag- en distributieproces, ook als dit tijdelijk, tijdens ontwikkeling, niet zo kan worden opgezet.
  • Ga ervan uit dat wat er in het gehele proces van aanleveren van kaarten en productie van kaart en certificaat mis kan gaan, ook een keer mis gaat.
  • Blijf de kaart- en applicatieprocessen conceptueel altijd als separate processen beschouwen en breng scheiding en controles aan daar waar dat mogelijk is. Hoezeer de fysieke toegangscontrole ook is gekoppeld aan de identiteitspas, het blijft een applicatie net als bijvoorbeeld het beveiligen van e-mail.
  • Richt de productie van de kaart en die van de certificaten in binnen één proces. Gescheiden opzet kan wenselijk zijn bij ontwikkeling maar voor het reguliere beheer is het inefficiënt en een bron van verstoringen.
  • Doe de initiële uitrol en/of invoering in één keer. Eventueel noodzakelijke uitzonderingen blijven de beheerorganisatie zeer lange tijd achtervolgen, zijn een bron van verstoringen en een groot acceptatierisico.

Conclusies

Gerelateerd aan de in dit artikel genoemde aspecten en onze interne projectervaringen kunnen de volgende conclusies worden getrokken ten aanzien van de opzet, realisatie en invoering van een corporate identiteitspas en managed PKI voor persoonsgebonden certificaten op die kaart:

In een samenwerkingsverband met een Managed PKI-leverancier en met de juiste aandacht voor scoping en gefaseerde realisatie is het mogelijk binnen één jaar tijd, vanaf scratch, een volledige public key infrastructuur – gecombineerd met een smartcard als drager van de certificaten – op te zetten en in gebruik te nemen.

Door geleidelijke invoering van de elektronische corporate identiteitspas – geleidelijk in de zin van niet direct noodzakelijk voor gebruik van de IT-infrastructuur en niet direct toepasbaar voor alle uiteindelijk te ondersteunen toepassingen – is invoering mogelijk met een sterk beperkt budget.

Om tegen acceptabele kosten beveiligde uitwisseling van elektronische gegevens tussen organisaties op grote schaal mogelijk te maken, is er behoefte aan een ‘sub-qualified’ en/of de-facto PKI-standaard. Met deze standaard moet het voor organisaties eenvoudig zijn om bilateraal afspraken te maken over wat en hoe er informatie wordt uitgewisseld en met welke juridische betekenis.

Literatuur

[Getr05] Getronics PinkRoccade Nederland BV, Managed PKI Service; Introduction, 2005.

[KPMG07] KPMG IT Advisory, Public Key Infrastructure Implementatie en Audit; Betrouwbare en veilige elektronische communicatie, 2007.

[Meen01] Drs. W.J.P. van de Meent, Het ontwikkelen van e-mailconventies, Compact 2001/5.

[Naza01] Noel Nazario en Martijn van Oosten, Real-world Application of Public Key Infrastructures Deployment Methodology, Compact 2001/1.

[Velt01] Ir. A.J.M. Veltmeijer, Beheeraspecten van technisch complexe omgevingen, Compact 2001/2.

[Wals02] Drs. P.A. van Walsem en ir. A. van Zanten CISA, Is ETSI TS 101456 geschikt voor gebruik bij een certificeringsonderzoek?, Compact 2002/4.

De Payment Card Industry – Data Security Standard

Berichten over grote aantallen gecompromitteerde creditcardgegevens komen regelmatig in het nieuws. Indien met deze gestolen gegevens vervolgens ook fraude wordt gepleegd, kan dit invloed hebben op het vertrouwen dat gebruikers in het gebruik van creditcards hebben en dus uiteindelijk resulteren in mogelijk lagere opbrengsten voor creditcardmaatschappijen door het verminderde gebruik. Daarom is al enige tijd geleden de Payment Card Industry – Data Security Standard in het leven geroepen die moet voorkomen, dan wel tijdig detecteren, dat creditcardgegevens worden gecompromitteerd. In dit artikel wordt beschreven wat deze standaard inhoudt, welke problemen er kunnen optreden bij de implementatie en hoe deze kunnen worden aangepakt en wat de gevolgen kunnen zijn als men niet compliant is.

Inleiding

De leden van de Payment Card Industry (PCI) Security Standards Council (American Express, Discover, JCB, MasterCard en Visa) monitoren continu gevallen van het compromitteren van creditcardgegevens. Een beveiligingsincident en vervolgens het compromitteren van creditcardgegevens kan verstrekkende gevolgen hebben voor de betrokken organisaties, inclusief mogelijke notificatievereisten ten aanzien van het incident (in bijvoorbeeld de Verenigde Staten[Hoewel in Europa ook wordt gesproken over zogenaamde ‘security breach notification’, wil men op dit moment dat zo’n notificatie alleen van toepassing zal zijn op telecomproviders en niet op bijvoorbeeld online banking.]), reputatierisico, verlies van klanten, mogelijke financiële verplichtingen en rechtszaken.

Uit analyse achteraf is gebleken dat veelvoorkomende beveiligingszwakheden die door de Payment Card Industry Data Security Standard (PCI DSS) worden geadresseerd, niet waren geïmplementeerd door organisaties ten tijde van het beveiligingsincident. De PCI DSS werd opgezet en bevat gedetailleerde vereisten om exact deze reden – om de kans op en de gevolgen van een beveiligingsincident te minimaliseren. De PCI DSS is opgezet door de oprichters van de PCI Security Standards Council (PCI SSC) om de brede globale acceptatie van consistente databeveiligingsmaatregelen te bewerkstelligen. De standaard bevat onder andere vereisten voor security management, policies, procedures, netwerkarchitectuur en softwareontwikkeling.

Heartland Payment Systems processes payments for over 250,000 mostly small and mid-size businesses and merchants in the U.S. and is considered to be the sixth-largest payment processor in the country. On 20 January 2009, the company announced that, during an internal audit prompted by a Visa warning, it had discovered that transaction data passing through its network had been intercepted and a significant number of credit cards had been compromised.

RBS WorldPay offers payment-processing solutions that cover credit, debit, Electronic Bank Transfers, gift cards, customer loyalty cards, checks, ATM, and tailored solutions for retail, restaurant, petroleum, convenience stores, grocery, hospitality, transport, and cardholders not present in these sectors. On 23 December 2008, the company announced that, at the beginning of November, unidentified parties had illegally obtained access to its computer systems and potentially compromised the personal information of 1.5 million customers.

RBS also noted that 100 payroll cards had been fraudulently used and had, subsequently, been disabled. It was later revealed that these cards had been employed in one of the most complex and well-coordinated fraud schemes to have ever been instrumented. Over 130 different ATM machines in 49 cities worldwide were hit in a 30-minute period, the crooks successfully withdrawing a whooping $9 million.

(Bron: news.softpedia.com)

PCI DSS

Welke data moet worden beschermd?

Creditcardgegevens kunnen worden gedefinieerd als het zogenaamde Primary Account Number (PAN) en andere gegevens die worden verkregen als onderdeel van een betaaltransactie, waaronder de volgende gegevens vallen:

  • naam van kaarthouder;
  • vervaldatum;
  • servicecode;
  • gevoelige authenticatie-informatie, zoals:
    • de volledige ‘magnetic stripe’-gegevens (op magnetische strip, op een chip of elders opgeslagen);
    • zogenaamde card validation codes;
    • pingegevens.

Het PAN is de factor die bepaalt of de PCI DSS en de PA DSS (Payment Application Data Security Standard) van toepassing zijn. Indien het PAN niet wordt opgeslagen, verwerkt of verstuurd, dan zijn de PCI DSS en de PA DSS ook niet van toepassing.

In dit artikel zal overigens verder niet worden ingegaan op de PA DSS. Het is wel goed om te weten dat de standaard bestaat om de beveiliging van third party payment applicaties te beoordelen. De beveiliging van zelfontwikkelde applicaties wordt door de PCI DSS afgedekt. Een lijst van gecertificeerde applicaties is beschikbaar via de PCI SSC.

Naam van kaarthouder, vervaldatum en servicecode moeten beschermd worden indien deze worden opgeslagen samen met het PAN, conform de PCI DSS. Tevens zouden op deze gegevens nog additionele (wettelijke) regels van toepassing kunnen zijn, zoals privacyregels.

De gevoelige authenticatie-informatie mag volgens de PCI-standaard nooit worden opgeslagen nadat autorisatie voor een betaling al is verkregen.

C-2009-4-IJkel-t01

Tabel 1. Overzicht creditcardgegevens en vereisten ten aanzien van opslag en beveiliging (ofwel versleuteling).

Zoals boven vermeld is het niet toegestaan gevoelige authenticatie-informatie op te slaan. Dit is om de eenvoudige reden dat indien deze gegevens samen met het PAN kunnen worden verkregen, er grote risico’s ontstaan dat deze gegevens worden misbruikt voor het uitvoeren van frauduleuze transacties.

C-2009-4-IJkel-01

Figuur 1. Visuele weergave elementen creditcardgegevens, voor- en achterzijde.

Indien een crimineel de ‘magnetic stripe’-gegevens in handen zou krijgen, dan zou er zelfs een volledige kopie van de creditcard gemaakt kunnen worden. De figuren 2 en 3 laten zien welke informatie op de magnetic strip van een creditcard staat.

C-2009-4-IJkel-02

Figuur 2. Visuele weergave gegevens op track 1 van de magnetic stripe.

C-2009-4-IJkel-03

Figuur 3. Visuele weergave gegevens op track 2 van de magnetic stripe.

Voor wie en waarop is de PCI DSS van toepassing?

In principe dient eenieder (met uitzondering van de eindgebruiker) die creditcardgegevens opslaat, verwerkt of verstuurt te voldoen aan de PCI DSS. Dit geldt dus voor zowel grote partijen, bijvoorbeeld Equens, als kleine partijen, zoals een webwinkel met maar enkele creditcardtransacties per jaar. De wijze waarop compliance moet worden aangetoond verschilt echter, enerzijds op basis van de rol die men heeft (serviceprovider of merchant) en anderzijds op basis van het volume van transacties per jaar.

C-2009-4-IJkel-t02

Tabel 2. Merchantniveaus en compliance-validatievereisten Visa; andere creditcardmaatschappijen hanteren een gelijksoortige indeling.

C-2009-4-IJkel-t02

Tabel 3. Serviceproviderniveaus en compliance-validatievereisten Visa.

De scope waarvoor compliance moet worden aangetoond, wordt in de PCI DSS gedefinieerd als alle systeemcomponenten die onderdeel zijn van of een connectie hebben met de zogenaamde ‘cardholder data’-omgeving. De ‘cardholder data’-omgeving is dat gedeelte van het netwerk waar cardholder data of gevoelige authenticatiegegevens zich bevinden, inclusief netwerkcomponenten, servers en applicaties. Uiteindelijk zou deze regel vanuit de PCI DSS kunnen resulteren in het toepasbaar zijn van de PCI DSS op het gehele interne netwerk van een bedrijf en niet alleen de ‘cardholder data’-omgeving zelf!

Hoe moet de data worden beschermd?

De PCI DSS bevat min of meer 6 onderwerpen, 12 gebieden en 62 hoofdvereisten. Deze 62 hoofdvereisten bestaan op hun beurt weer uit een aantal meer gedetailleerde vereisten waaraan men moet voldoen om aan de hoofdvereisten te kunnen voldoen. In tabel 4 zijn de onderwerpen en gebieden weergegeven, inclusief een korte uitleg over wat deze betekenen.

C-2009-4-IJkel-t04

Tabel. 4. Onderwerpen en gebieden van de PCI DSS, met korte toelichting.

In principe moet men aan alle vereisten voldoen om PCI-compliant te worden. Hoewel veel van deze vereisten kunnen worden gezien als normale good practices om een IT-omgeving te beveiligen en te beheren, is er toch een aantal gebieden die het moeilijk (kunnen) maken om compliant te geraken.

Wat zijn veelvoorkomende problemen bij implementatie?

Op basis van de ervaringen die zijn voortgekomen uit het recente verleden bij bedrijven die reeds de PCI DSS hebben geïmplementeerd en ook zoals KPMG deze is tegengekomen bij haar klanten, kan een aantal implementatieproblemen worden gedefinieerd. Inmiddels is het ook tot creditcardmaatschappijen doorgedrongen dat compliancy niet altijd binnen korte tijd is te realiseren en daarom is het van belang om constant in contact te blijven met deze maatschappijen om afspraken te maken over het pad om uiteindelijk wel volledige compliancy te bereiken.

Locatie van cardholder data

Aan het begin van een PCI DSS-traject is vaak niet exact bekend waar cardholder data precies is opgeslagen en of deze opslag ook werkelijk noodzakelijk is. Een inventarisatie zal dus moeten worden gemaakt van alle systemen (inclusief eindgebruikersystemen) en er zal moeten worden bepaald of het aantal locaties waar data wordt opgeslagen niet kan worden teruggebracht.

Zonder inventarisatie kan ook niet worden vastgesteld of men PCI-compliant is, aangezien er geen informatie beschikbaar is over de scope. Het niet terugdringen van het aantal locaties waar cardholder data zich bevindt kan mogelijk resulteren in kostbare maatregelen die op meer systemen moeten worden geïmplementeerd (zoals de versleutelingseisen).

Scoping

De PCI DSS schrijft voor dat alle systeemcomponenten die onderdeel zijn van of een connectie hebben met de ‘cardholder data’-omgeving compliant moeten worden gemaakt. Indien geen netwerkscheiding wordt aangebracht tussen de ‘cardholder data’-omgeving en de rest van het interne netwerk van een bedrijf, dient het gehele interne netwerk PCI-compliant te worden gemaakt, wat een onmogelijke, dan wel zeer tijdrovende en kostbare taak kan blijken te zijn.

Het is daarom van het grootste belang om te trachten de ‘cardholder data’-omgeving af te scheiden van het interne netwerk via interne firewalls. Hierdoor kan de scope worden beperkt en dus ook de inspanning om de PCI DSS te implementeren.

Veranderingen in bedrijfsprocessen

Het invoeren van de PCI DSS, inclusief het beperken van de locaties waar cardholder data zich bevindt en overige pogingen om de scope te beperken, kan tevens resulteren in de noodzaak om bepaalde bedrijfsprocessen dan wel IT-beheerprocessen te wijzigen.

Organisatorische veranderingen kunnen soms rekenen op weerstand en tevens hebben nieuwe processen vaak een aanlooptijd nodig voordat deze volledig werken zoals voorzien.

Monitoring

De PCI DSS bevat aanzienlijk uitgebreide vereisten ten aanzien van logging en monitoring. Ten eerste moet worden nagegaan in hoeverre bestaande applicaties en systemen wel voldoende mogelijkheden bieden om aan de vereisten te voldoen en wat er exact zou moeten worden gemonitord binnen de applicaties en systemen. Voorts dient mogelijk nieuwe software te worden geïmplementeerd en personeel te worden aangenomen om ook de monitoring goed te kunnen uitvoeren.

Versleuteling cardholder data

Het voldoen aan de vereisten van versleuteling van cardholder data is soms moeilijk te implementeren, bijvoorbeeld:

  • omdat gebruik wordt gemaakt van legacy draadloze netwerken (met zwakke of geen versleuteling) in bijvoorbeeld winkels waar creditcardgegevens van ‘point of sale’-systemen naar centrale systemen worden verstuurd;
  • omdat er sprake is van legacy applicaties waarin het niet mogelijk is zodanige veranderingen in de software door te voeren dat de software versleuteling van en naar de database met de cardholder data ondersteunt.

Voortdurende compliance

Nadat de initiële PCI-compliance is gerealiseerd, is het noodzakelijk dat aandacht wordt besteed aan het compliant blijven. Nieuwe systemen en applicaties die worden geïntroduceerd zullen aan dezelfde eisen moeten voldoen als de initiële omgeving, daarnaast kunnen er ook updates plaatsvinden op de PCI DSS-vereisten die moeten worden opgevolgd. Tot slot zijn er ook bepaalde eisen in de PCI DSS die een bedrijf waarschijnlijk niet zelf kan en/of mag uitvoeren. Een voorbeeld hiervan zijn de vereisten in tabel 4 onder punt 11, die het minimaal jaarlijks uitvoeren van interne en externe penetratietests verplicht stellen en daarbij een mate van onafhankelijkheid eisen van degene die de penetratietest uitvoert ten opzichte van de organisatie die het beheer van de PCI-omgeving uitvoert.

Samenvatting en conclusie

De PCI DSS dient de kans op beveiligingsincidenten in de ‘cardholder data’-omgeving te verkleinen en de detectie van (mogelijke) incidenten te verhogen, om uiteindelijk fraude met creditcardgegevens te voorkomen. Indien bedrijven die in principe verplicht zijn de PCI DSS te implementeren dit niet (goed) doen, kan dat tot onder andere boetes en het verlies van klanten leiden en dus negatieve financiële consequenties hebben of misschien zelfs wel de continuïteit schaden. In de Verenigde Staten zijn er zelfs staten (Minnesota) die compliance met de PCI DSS wettelijk verplicht hebben gesteld).

Het is dus van belang dat bedrijven zorgen dat ze compliant zijn. Hiertoe dient wel een aanpak te worden gehanteerd die efficiënt en effectief is en dus te hoge compliancekosten vermijdt. Hiervoor is het vooral van belang dat rekening wordt gehouden met de scope waarop de PCI DSS van toepassing is en die trachten zo klein mogelijk te maken. Tevens dient open communicatie plaats te vinden met de creditcardmaatschappijen, of de partij waaraan compliance moet worden aangetoond, om de voortgang van compliance te bespreken en eventueel te kunnen uitleggen waarom het voldoen aan bepaalde eisen meer tijd vergt.

Data Retention: Opportunity or Burden in Times of Economic Downturn?

This article is a case study of the data retention project at Unibail-Rodamco. It describes the project approach Unibail-Rodamco has chosen for their data retention project and it sets out the related business case for the project which goal was to phase out their legacy systems[A legacy system is an old computer system or application program that continues to be used, typically because it still functions for the users’ needs, even though newer technology is available. (source: http://en.wikipedia.org/wiki/Legacy_system)] retaining their business data in a way that complies to legal and operational requirements.

Introduction

Unibail-Rodamco has rolled out SAP to several of their European entities. The legacy systems in use in the countries where this migration occurred were kept live. Partly this was due to operational requirements for continuity and partly this was due to data-retention requirements. Unibail-Rodamco wanted to close down these systems to reduce costs and to prevent the use of the legacy systems. However, before discontinuing the obsolete systems, Unibail-Rodamco wanted to ensure that all local data-retention requirements would be met as they related to what historical data needed to be retained as well as the accessibility and storage requirements of this data. This article is a case study of the approach Unibail-Rodamco has chosen to phase out their legacy systems. The following subjects will be discussed: Project goal and project scope; Business case; Approach; Conclusion

Project Definition – Defining the Objective and Scope of the Project

Clearly defined objectives determine the project approach and project result. The objective of this project was defined as “Investigate what data needs to be retained according to legal and regulatory requirements and, consequently, determine which systems can be phased out.” Two criteria were used to determine what data and systems came within the scope of the project. The first criteria was to focus on legacy systems that became obsolete as result of the SAP roll-out. The second criteria was to focus on the primary business processes.

Business Case – Where to Start?

Defining a clear (quantitative) business case is usually difficult because information regarding future costs and benefits is not easily determined or obtained. For this reason Unibail-Rodamco chose to start with an initial business case outlining high-level costs and benefits, and to further detail the business case at later stages of the project. This resulted in a business case where as many specifications as possible were added at each phase of the project. At the start of the project benefits were mainly qualitative, and costs were limited to project costs specified in man days (internal and external) and travel expenses. During the project this has been augmented with other costs like maintenance costs, license costs, hosting costs and hardware costs.

C-2009-3-Wilpshaar-t01

Table 1. The business case.

Approach

Activities were categorized in phases for improved project management. Each phase had its own specific objective, deliverables and timeline. The total project was planned to be finished in eighteen months for a European organization operating in twelve countries. In the following paragraphs each phase is described.

Phase 0 “Establish Foundation”

The objective of the preliminary phase was to establish a foundation for the project by outlining the business case and timelines, then obtaining approval to commence the project. This phase includes activities such as drafting the business case, writing the project plan and obtaining approval of the management board to commence the project. It started off with a video conference in which the ICT Director, Board member responsible for IT, Head of Risk Management and members of the project team participated. This phase took one month.

Phase 1 “Current State Assessment”

The objective of the first phase was to determine the current state of existing data-retention policies, to identify legacy applications (and related costs) and to study legal and regulatory requirements. There were questions that needed to be answered within this phase: What policies regarding retention of data, procedures and controls have already been implemented? What does the IT infrastructure (hardware, software, interfaces) look like? Which applications can be identified as legacy applications? What are the terms and costs regarding software and hardware licenses? What hardware technology is being used? How do the applications support business processes? Has data ownership been allocated? Which systems can be phased out and which local legal and regulatory requirements are applicable?

The starting point was to ask all local IT managers from the European entities which applications could be identified as legacy systems. Then questions were asked on a per-application basis regarding the environment (supporting operating systems, databases), costs (licenses, maintenance fees) and risk management. Table 2 shows the categories and examples of questions per application that have been included in the questionnaire.

C-2009-3-Wilpshaar-t02

Table 2. Current state assessment – questionnaire.

A detailed version of this questionnaire was sent to all the IT managers of the countries that were within the project’s scope. It revealed which European ICT systems were identified as legacy applications, since there was no need for actual use of these applications. Second, it showed the expenditures on legacy applications, thereby creating awareness of the costs of legacy systems whose benefits were no longer always clear.

Unibail-Rodamco has indicated that this exercise proved very valuable. The results of the survey are still used to evaluate IT contracts and IT costs, and are also used in the budget rounds to control costs of maintenance and license fees of IT systems. The identified cost savings qualify as significant because the annual savings alone already outweighed the project costs. The results of the survey have been used to further quantify the business case.

During this phase Unibail-Rodamco wanted to reduce expenses on their projects. For this reason it was decided to continue with the project but to limit its scope to the corporate legacy systems and to non-critical business applications that were identified as legacy. The critical business applications that were identified as legacy were kept out of the project’s scope because in some way these were used in daily operations (for example, for processing of service charges for older contracts). Obviously, the time and effort saved through this decision will be expended once Unibail-Rodamco continues with a data-retention project for the critical business applications that are regarded as legacy systems.

Phase 2 “Desired State Design”

The objective of the second phase was to define a desired future design: i.e., determine how Unibail-Rodamco should deal with the identified legacy applications and identified legal and regulatory requirements. To do this, a workshop was organized to determine in what way the identified data-retention requirements could best be dealt with. During this session priorities had to be set regarding what data needed to be retained. This was done based on the results of a gap and risk analysis showing to what extent the organization presently complied with legal requirements but also where the organization failed to comply with these requirements. The results of the workshop led to an understanding of how the organization should best deal with data-retention requirements based on the triangle of risk, cost and effort. Based on the results of the workshop, a data-retention strategy describing the intended solutions is written.

The project made clear to corporate and local management that know-how and expertise in local regulations was required. Therefore at corporate level it was determined which systems needed to be retained from a legal perspective and those decisions were subsequently communicated to the European entities. For other legacy systems, local IT managers were allowed to determine themselves whether the systems needed to be retained based on business needs or legal requirements. Most of the research has been performed regarding corporate-transaction systems, consolidation systems and data-warehouse systems that were identified as legacy at that moment, or as soon-to-be legacy, because most of the potential cost savings (e.g. for housing, hosting, contracts and maintenance) could be realized for these systems.

Initially, the duration of this phase was estimated at two months. However because the scope had been reduced and the analysis of legal requirements could be performed at corporate level in an efficient way, this phase was finished in a couple of days.

Phase 3 “Implementation”

In this phase the data-retention strategy needed to be implemented. The first step in this phase was to write the implementation plan for each entity. These plans explained how solutions had to be implemented, by whom and when.

Unibail-Rodamco has indicated that several corporate and local systems containing data that did not have to be retained for business and legal reasons have been switched off and phased out. Data is retained for some corporate legacy systems which must be retained from a business and legal perspective. For other systems, this is under investigation, because occasionally the system and data is necessary for business reasons.

Depending on the type of data, Unibail-Rodamco has chosen virtualization technologies or storage on different media (like tape and DVD) to retain data in a way that assures availability and accessibility. License fees and contracts have been revised in case just read-only access was required. The duration of this phase took four months. This phase started three months after phase two was finished because from this moment all systems identified as legacy were no longer required for operational use.

Phase 4 “Operations and Review”

The objective of the fourth phase was to assess whether controls have been implemented effectively and to determine corrective actions if necessary. The duration of this phase was three days.

Table 3 shows an overview of the objectives, main activities and deliverables.

C-2009-3-Wilpshaar-t03

Table 3. Objectives, main activities and deliverables.[Klik hier voor grotere afbeelding]

Conclusion

This project shows that a data-retention project has several advantages for an organization. Most importantly, significant cost savings can be realized by phasing out corporate legacy systems and non-critical business applications. In the case of Unibail-Rodamco, these cost savings were realized by reducing the number of servers, interfaces and applications; in turn, these reductions have significantly lowered the costs of maintenance and licensing. Furthermore, the overview of identified legacy systems showed the costs that were related to these systems and made IT management reconsider whether they needed to keep these systems running, which has led to internal agreements to phase out other legacy systems in the near future. The case with Unibail-Rodamco proves that an organization can significantly cut IT spending by phasing out legacy systems and at the same time can avoid risks of non-compliance with legal and regulatory requirements. In this way it can definitely be regarded as an opportunity instead of a burden in these times of economic downturn.

About Unibail-Rodamco

Unibail-Rodamco is the leading listed European commercial property operator, investor and developer. With a property portfolio valued at €22.8 billion at June 30, 2009, Unibail-Rodamco is active in three major business lines: shopping centres, offices and convention-exhibition centres. The Group has a clear focus on high-quality assets in Europe which have a leading competitive edge in their respective markets in terms of footfall, size, specifications, location and reputation. The Group targets segments of the real estate market where demand exceeds supply. For each core business, Unibail-Rodamco aims to maximize shareholder value and return on investment through proactive management, a dynamic acquisition and disposal policy, and a high level of expertise in the management of major development and refurbishment projects. Unibail-Rodamco is one of Europe’s most liquid listed property investment stocks, is part of the French CAC 40, Euronext 100 and Dutch AEX Index, and benefits from an “A” rating from Standard & Poor’s.

Tax Control Framework (TCF): Nut en noodzaak van IT bij het opzetten van een TCF

Veel Compact-lezers zijn wellicht op de een of andere manier geconfronteerd met begrippen als Tax Control Framework, horizontaal toezicht en handhavingsconvenant. Dit artikel licht deze begrippen toe. Vervolgens worden het nut en de noodzaak van IT en specifiek ERP-systemen beschreven bij het opzetten van een Tax Control Framework, dat ervoor moet zorgen dat de fiscale risico’s van een bedrijf bekend zijn en beheerst worden.

Inleiding

De aandacht voor risicomanagement is mede door de kredietcrisis flink toegenomen. Dit geldt ook voor fiscale risico’s. Werden fiscale risico’s voorheen niet of nauwelijks meegenomen binnen risicomanagement, de tijden veranderen en daarmee ook de aandacht voor het beheersen van de fiscale component binnen de organisatie.

De toenemende aandacht voor fiscaliteit van wettelijke organen en investeerders wordt mede veroorzaakt door de impact die fiscaliteit heeft op de financiële positie van bedrijven. Belanghebbenden, zoals investeerders, de Belastingdienst en andere toezichthoudende organisaties, vragen organisaties om een gewijzigde aanpak van fiscaliteit. Het is niet alleen belangrijk dat de juiste stappen gezet worden om te kunnen voldoen aan belastingwet- en -regelgeving, ook transparantie, inzicht in fiscale risico’s en een adequate implementatie van maatregelen om deze risico’s te beheersen worden steeds belangrijker. Dit zal er overigens niet alleen toe leiden dat organisaties hun fiscale risico’s beter kunnen beheersen, maar creëert daarnaast ook meer inzicht in de mogelijkheden om fiscale kansen te benutten.

Naast de zekerheid dat organisaties ‘in control’ zijn ten aanzien van hun fiscale positie, is het van belang dat organisaties dit kunnen aantonen aan hun belanghebbenden, zoals het audit committee, het management en de fiscale autoriteiten.

Bij de fiscale autoriteiten is een vergelijkbare trend waarneembaar. Zij zien in toenemende mate af van uitgebreide boekenonderzoeken van oude jaren en leggen, meer en meer, de focus op werken in de actualiteit, processen, fiscale strategieën en fiscaal risicomanagement. Deze zienswijze wordt ook door de Organisation for Economic Co-operation and Development (OECD) ([OECD08]) gepromoot.

In dit artikel worden de begrippen horizontaal toezicht en handhavingsconvenant kort toegelicht, en wordt het begrip Tax Control Framework nader uitgewerkt. Deze begrippen hebben hun oorsprong gevonden in de toegenomen aandacht voor fiscaliteit.

Horizontaal toezicht en handhavingsconvenant

De Belastingdienst ([Bela08]) beschrijft in zijn notitie het volgende over horizontaal toezicht: ‘Wroeten in oude belastingjaren was voor ondernemers onbevredigend, maar ook voor de Belastingdienst, die als één van de doelstellingen heeft zo actueel mogelijk te werken. Bij fiscale geschilpunten werden soms uiterste standpunten ingenomen. Er was weinig vertrouwen tussen de partijen waardoor er weinig informatie werd gedeeld. Het oplossen van geschilpunten leidde tot lange doorlooptijden en hoge kosten voor beide partijen. En dat was op zijn beurt niet compliance bevorderend, terwijl dat één van de hoofddoelstellingen van de Belastingdienst was. Om toch de hoofddoelstelling te kunnen realiseren heeft de Belastingdienst Horizontaal toezicht geïntroduceerd‘.

Horizontaal toezicht houdt kort gezegd in dat belastingplichtigen en de Belastingdienst elkaar op een andere manier gaan benaderen. Vertrouwen, openheid, transparantie en wederzijds respect vormen de basis. Horizontaal toezicht sluit hiermee aan bij corporate governance ontwikkelingen.

Het handhavingsconvenant is de ultieme vorm van horizontaal toezicht. In een handhavingsconvenant worden afspraken gemaakt over de wijze waarop beide partijen samenwerken. Wil een bedrijf in aanmerking komen voor een handhavingsconvenant, dan verwacht de Belastingdienst dat de onderneming een adequaat werkend Tax Control Framework (TCF) heeft, dan wel serieuze stappen onderneemt om binnen afzienbare tijd een TCF te implementeren.

Door horizontaal toezicht is de aandacht voor het TCF sterk toegenomen. Vaak wordt zelfs – ten onrechte – aangenomen dat het TCF een gevolg daarvan is. Ook ondernemingen die geen handhavingsconvenant hebben of ‘convenantachtig werken’ met de Belastingdienst, zouden een TCF moeten implementeren. Niet omdat de fiscale autoriteiten dat wensen, maar omdat zij zélf van mening zijn dat het beheersen van de fiscaliteit in de onderneming essentieel is voor een goede bedrijfsvoering. Een TCF zou dan ook niet beperkt moeten worden tot de Nederlandse fiscaliteit.

Tax Control Framework

Een Tax Control Framework (TCF) is een samenstel van processen en interne beheersingsmaatregelen (verder in dit artikel ook controls genoemd) dat ervoor moet zorgen dat de fiscale risico’s van een bedrijf bekend zijn en beheerst worden. Een TCF is een belangrijk middel om de totale fiscaliteit binnen een organisatie te beheersen.

Een TCF omvat in beginsel alle op de betreffende organisatie van toepassing zijnde belastingen, bijvoorbeeld vennootschapsbelasting, loonheffing, omzetbelasting, invoerrechten en accijnzen. Maar ook regulerende energiebelasting, kansspelbelasting, milieubelastingen, verpakkingenbelasting, BPM, vliegticketbelasting, etc. zouden in voorkomende gevallen in een TCF een plaats moeten krijgen. Ook het volledig, juist en tijdig doen van aangiften en betalingen valt binnen de scope van een TCF.

De hiervoor genoemde belastingsoorten hebben raakvlakken met nagenoeg alle bedrijfsprocessen. Het afsluiten van een verkooptransactie en het uitreiken van een factuur vindt plaats in het primaire bedrijfsproces en kan invloed hebben op de vennootschapsbelasting, omzetbelasting en af te dragen invoerrechten en accijnzen. Een TCF dient dan ook integraal onderdeel te zijn van een overkoepelend Business Control Framework (BCF).

Omdat de controleaanpak van de Belastingdienst in hoge mate wordt bepaald door de manier waarop een onderneming haar (fiscale) processen beheerst, zal de Belastingdienst het TCF beoordelen op ontwerp, bestaan en werking. De Belastingdienst stelt geen minimumeisen aan het TCF, maar reikt wel een handvat aan om tot een goed TCF te komen. Het COSO-model wordt door de Belastingdienst als logisch uitgangspunt genoemd omdat dit de internationale standaard is op het gebied van het opzetten van een intern beheersingssysteem en door veel bedrijven al gebruikt wordt voor het opzetten van het BCF.

Een TCF stelt de onderneming in staat haar fiscaal operationele en financiële doelen te bereiken en de fiscale strategie uit te voeren op een beheersbare en controleerbare wijze. Een TCF helpt de onderneming helder over fiscaliteit te communiceren met haar externe en interne belanghebbenden.

Voordelen TCF

Een TCF moet leiden naar een optimaal functionerende fiscale functie. Dit heeft verschillende voordelen:

  • werken in de actualiteit;
  • zekerheid over fiscale positie (geen ‘verrassingen’ meer);
  • imagoverbetering, toename van vertrouwen van stakeholders;
  • efficiëntere en effectievere inrichting van het beheersingssysteem rondom fiscaliteit:
    • verbeterde kwaliteit van de fiscale data;
    • snellere fiscale rapportages;
    • meer inzicht in de fiscale mogelijkheden door beter inzicht in de fiscale situatie;
  • minder correcties bij fiscale controles en lagere controlekosten.

Overigens is een TCF niet alleen nuttig bij het afsluiten van een handhavingsconvenant. Een handhavingsconvenant wordt gesloten met de Nederlandse Belastingdienst en heeft een Nederlandse reikwijdte, een TCF kan echter ook internationaal worden ingezet (als integraal onderdeel van een BCF) waardoor de totale fiscaliteit van een organisatie ‘in control’ is.

Het ontwikkelen van een Tax Control Framework

In de voorgaande paragraaf is beschreven dat een TCF de totale fiscaliteit van een organisatie omvat en dat de meeste bedrijfsprocessen, veelal ondersteund door verschillende IT-systemen, direct van invloed hierop zijn. Veel beheersingsmaatregelen om risico’s te mitigeren worden in IT-systemen ingericht. De rol van IT (en hiermee de betrokkenheid van IT-adviseurs en -auditors) is dan ook essentieel in een TCF.

Voor het opzetten, implementeren en onderhouden van een TCF kan de in tabel 1 gegeven fasering worden gehanteerd. De rol van IT is per fase weergegeven.

C-2009-3-Peters-t01

Tabel 1. TCF-methodiek.

Fase 1 Planning

In fase 1 worden de doelstellingen en de reikwijdte van het TCF vastgesteld. Hierbij komen vragen aan de orde als: waar wil de organisatie het TCF voor gebruiken, op welke belastingsoort(en) wil de organisatie zich in eerste instantie richten, wordt het een TCF alleen voor Nederland of ook voor andere landen. Een ander belangrijk aspect is het opzetten van een projectteam en het creëren van de randvoorwaarden om het TCF-project te beheersen (o.a. projectmanagement en verkrijgen resources). Het is verstandig om eerst een beperkte pilot te draaien. In deze fase worden geen specifieke IT-activiteiten uitgevoerd.

Fase 2 Inzicht

In fase 2 wordt bij wijze van ‘nulmeting’ een groot aantal zaken in kaart gebracht. Zonder volledig te willen zijn noemen we de fiscale strategie, de juridische en fiscale structuur, de belangrijkste producten/diensten en markten, de fiscale organisatie, de taken en verantwoordelijkheden met betrekking tot belastingen, de belangrijkste belastingmiddelen, de relevante bedrijfsprocessen, IT-systemen (inclusief autorisatie-inrichting) en overige registraties. Deze brede oriëntatie op de organisatie is nodig om te onderkennen waar en op welke manier de fiscaliteit ingrijpt op de processen in de organisatie, zodat een gedegen fiscale risicoanalyse kan worden gemaakt. Tevens kan worden beoordeeld of en zo ja, in hoeverre deze risico’s door (geautomatiseerde) beheersingsmaatregelen worden afgedekt.

Omdat de ‘soft controls’ van grote invloed zijn op het adequaat werken van de ‘hard controls’, wordt ook hieraan aandacht besteed. Hierbij kan gedacht worden aan de ‘tone at the top’, de motivatie en scholing van medewerkers, de bedrijfscultuur, de aanwezigheid van een gedragscode, de beloningsstructuur, stijl van leidinggeven, normen en waarden en fiscaal bewustzijn. Ook de Belastingdienst zal – in het kader van het eventueel sluiten van een handhavingsconvenant – de soft controls bij de beoordeling van het TCF betrekken.

Uiteindelijk monden de werkzaamheden in deze fase uit in het benoemen en beschrijven van gebreken in het interne beheersingssysteem en een prioritering van de vervolgstappen in het project om deze gebreken weg te nemen.

IT heeft een actieve rol in deze fase bij het analyseren van processen en IT-systemen. Bij het uitvoeren van een risicoanalyse kan een IT-auditor of adviseur ook zijn ruime ervaring inbrengen.

Fase 3 Ontwerp

De ontwerpfase richt zich op het (her)ontwerpen van beheersingsmaatregelen. Uiteraard wordt daarbij aangesloten bij al bestaande maatregelen. Waar mogelijk zullen de maatregelen in de automatiseringsomgeving worden neergelegd, omdat geautomatiseerde beheersingsmaatregelen veelal efficiënter en effectiever zijn dan handmatige beheersingsmaatregelen. Dit geldt dan vooral voor maatregelen gericht op risico’s in de routinematige processen. Voor de niet-routinematige processen, zoals fusies, overnames, IPO of herfinancieringen, ligt een organisatorische, procedurele benadering meer voor de hand.

IT heeft een actieve rol bij het inventariseren van bestaande en het bepalen van toekomstige beheersingsmaatregelen in de fiscaal relevante IT-systemen.

Fase 4 Implementatie

Nieuwe en/of aangepaste beheersingsmaatregelen worden in deze fase gerealiseerd. Echter niet eerder dan nadat in samenspraak met het management een prioritering is gemaakt en een planning is neergelegd voor het verbetertraject. ‘Key controls’ en evidente ‘control gaps’ worden het eerst opgepakt, zodat met een eerste inspanning een grote vooruitgang kan worden geboekt. Communicatie met alle betrokken medewerkers en afdelingen is cruciaal in deze fase: indien nodig moeten medewerkers worden voorgelicht, geïnstrueerd en/of getraind. Het spreekt voor zich dat de rol van IT in deze fase ook belangrijk is om een praktisch werkend TCF te implementeren.

Fase 5 Monitoring

Het beoordelen van de opzet, het bestaan en de werking van de voor het TCF getroffen beheersingsmaatregelen wijkt niet wezenlijk af van het beoordelen van het bestaan en de werking van andere beheersingsmaatregelen die onderdeel uitmaken van het BCF. Voor zover mogelijk wordt deze toetsing geïncorporeerd in de management-controlprocessen (selfassessment), het controleplan van de internecontroleafdeling en/of meegenomen in de controle van de externe accountant.

Hoewel het bestaan en de werking voor een groot deel kunnen worden getoetst door directe waarneming, het opnieuw uitvoeren van maatregelen, proceduretests, lijncontroles, etc., hechten wij tevens veel belang aan het op onderdelen uitvoeren van gegevensgerichte bestandsanalyses en (mathematische) steekproeven. Daarmee kunnen op efficiënte wijze kritische posten worden geïdentificeerd en gecontroleerd. De Belastingdienst is bekend met deze methodieken en zal deze op waarde weten te schatten. Ook in deze fase zal IT een belangrijke rol vervullen.

Interessant in dit kader is de discussie over materialiteit. De materialiteit van de Belastingdienst is doorgaans veel lager dan de materialiteit voor de jaarrekening. De Belastingdienst wijst in dit kader echter op het feit dat op het ‘lage’ niveau van de bedrijfsprocessen materialiteit nauwelijks een rol speelt: beheersingsmaatregelen worden immers niet zo ingericht dat alleen materiële posten aan controle worden onderworpen. De lage materialiteitsnormen van de Belastingdienst lijken redelijk hanteerbaar als tevens de werking van de interne beheersingsmaatregelen in ogenschouw wordt genomen. De uit te voeren hoeveelheid gegevensgerichte (monitoring)werkzaamheden wordt dan sterk gereduceerd, omdat voor een groot deel kan worden gesteund op de getroffen interne beheersingsmaatregelen.

De bevindingen die voortvloeien uit de toetsing van het bestaan en de werking van het TCF vormen samen met wijzigingen in de interne en externe omgeving de basis voor continue aanpassingen en verbeteringen van het TCF.

Integratie TCF en BCF tot één platform

In zijn notitie schrijft de Belastingdienst dat het TCF moet worden gezien als onderdeel van het Business Control Framework (BCF). Veel bedrijven hebben met een BCF ervaringen opgedaan als gevolg van regelgevingen zoals de code-Tabaksblat en Sarbanes-Oxley.

In de praktijk zien wij dat het voor bedrijven (nog steeds) een uitdaging is om aan al deze regelgevingen te voldoen en dit aan te kunnen tonen. Om de werkdruk voor het uitvoeren van ‘test’- en ‘monitoring’-werkzaamheden op een – voor de business – acceptabel niveau te brengen is het noodzakelijk om een geïntegreerde BCF op te zetten met uiteindelijk een zogenaamd ‘single view of risk’ ([KPMG08]). Deze geïntegreerde BCF (figuur 1) omvat alle controls die noodzakelijk zijn om te voldoen aan de relevante wet- en regelgeving. Op deze manier worden controls die voor verschillende doeleinden zijn gedefinieerd, effectief en efficiënt toegepast.

C-2009-3-Peters-01

Figuur 1. Geïntegreerde aanpak van BCF en TCF ([KPMG08]).

Ondersteuning door geautomatiseerde tools

Een volledig geïntegreerd BCF is vaak een complex geheel. Een geautomatiseerde controls monitoring tool kan hier uitkomst bieden. Op de markt zijn veel softwareapplicaties op het gebied van Governance, Risk en Compliance verkrijgbaar. Specifieke TCF-tooling is in opkomst.

KPMG Meijburg & Co ([KPMG09]) heeft in samenwerking met een risk-managementsoftwarebedrijf een applicatie ontwikkeld waarin een TCF volledig kan worden opgezet en beheerd (in eigen beheer van de organisatie) en dat volledig kan worden geïntegreerd of uitgebreid met (de aanwezige) risk-managementapplicaties. Deze applicatie is gebaseerd op COSO en bevat voorbeeldrisico’s en -controls voor nagenoeg alle fiscale middelen. Ook liggen de eisen en wensen van een groot aantal cliënten en ruime eigen praktijkervaring aan deze applicatie ten grondslag. Figuur 2 biedt een overzicht van de tax risk-managementsectie van de applicatie. Figuur 3 geeft één van de rapportagemogelijkheden weer, waarbij per entiteit, per belastingsoort en per proces de ‘in control’-status wordt getoond.

C-2009-3-Peters-02

Figuur 2. Tax risk-managementsectie.[Klik hier voor grotere afbeelding]

C-2009-3-Peters-03

Figuur 3. Rapportagesectie.[Klik hier voor grotere afbeelding]

De rol van ERP-systemen

Met het opzetten van een BCF is de afgelopen jaren binnen bedrijven veel ervaring opgedaan, en is in vele gevallen ook een volgend volwassenheidsniveau bereikt. Hiermee bedoelen wij, dat waar controls binnen de initiële BCF’s vooral manuele controls betroffen, deze zich steeds verder hebben ontwikkeld naar geautomatiseerde en daarmee vaak efficiëntere controls. Op deze ontwikkeling zou een TCF meteen kunnen aansluiten, zonder die leercurve opnieuw te hoeven doorlopen.

Je zou kunnen stellen dat fiscale controls zich uitsplitsen in controls die de kwaliteit van de aangifteprocessen moeten waarborgen en controls binnen de primaire bedrijfsprocessen die de input vormen voor het aangifteproces (zie figuur 4). Dit zijn dan vooral maatregelen die de juistheid en volledigheid van deze input moeten waarborgen. Zo kunnen er controls worden benoemd die ervoor moeten zorgen dat voor de diverse landen op tijd en met voldoende ‘checks and balances’ een btw-aangifte naar de autoriteiten wordt gestuurd. Dat betrekt zich op het aangifteproces. Binnen de bedrijfsprocessen zou met het oog op de foutenkans gewaarborgd kunnen zijn dat bij het opvoeren van een verkooporder btw-codes nooit handmatig kunnen worden ingevoerd, maar altijd automatisch door het systeem op basis van beslissingsregels worden bepaald. Hierdoor wordt de juistheid en volledigheid van de input voor de btw-aangifte via beslissingslogica gewaarborgd. Tabel 2 bevat een aantal voorbeelden van btw-risico’s en applicatiecontrols.

C-2009-3-Peters-04

Figuur 4. Speelveld van fiscale controls.

C-2009-3-Peters-t02

Tabel 2. Voorbeelden van specifieke SAP btw-risico’s en applicatiecontrols[Klik hier voor grotere afbeelding] ([Zege07]).

In de meeste moderne ERP-systemen is het opzetten van deze logica een kwestie van parametriseren en masterdata-management. Het vaststellen van de kwaliteit van deze beslissingslogica is in dit geval een belangrijke control. Staat door testen of data-analyses eenmaal vast dat deze beslissingslogica goed werkt, dan kan hierop worden gesteund. Daarvoor zal wel moeten worden vastgesteld dat het change-managementproces binnen een ERP Competence Center voor het ERP-systeem in het algemeen en de beslissingslogica in het bijzonder van voldoende kwaliteit is. Een bijzonder aandachtspunt daarbij is, dat er bij de impactanalyse van een wijzigingsverzoek voldoende aandacht is voor de consequentie van de wijziging op fiscale compliance. Wat dat betreft is er ook niets nieuws onder de zon. Dit principe kennen we natuurlijk al lang uit de BCF’s.

Praktische tips voor het succesvol opzetten van een TCF

De auteurs hebben ruime praktijkervaring opgedaan met het ontwerpen, implementeren, onderhouden en optimaliseren van Business Control Frameworks en Tax Control Frameworks. Voor het succesvol opzetten van een TCF (of BCF) willen wij u graag de volgende praktische tips meegeven:

  • Dynamisch. Een TCF moet dynamisch zijn, geen foto maar een film! Een TCF gaat verder dan een quick scan op fiscale risico’s en interne beheersingsmaatregelen. De afdeling fiscale zaken moet weten wat er binnen de organisatie gebeurt en hierbij betrokken worden. Geen kast vol papieren checklists.
  • Klein beginnen. De kunst is om een werkbaar en beheersbaar TCF op te zetten. Afbakenen is noodzakelijk. Later uitbreiden kan altijd nog. Begin met één belastingmiddel, één divisie en een beperkte hoeveelheid risico’s. Zorgen voor draagvlak binnen de organisatie.
  • Integratie. In tegenstelling tot wat velen denken, wordt een TCF juist niet alleen door de fiscale afdeling gebruikt. Maak gebruik van de andere afdelingen, zoals de riskmanagers, controllers, internal audit en IT. Samenwerken met deze afdelingen is een must om tot een goed en werkbaar TCF te komen, als onderdeel van het totale risk management van het bedrijf.
  • Platform. Zorg voor een integraal platform voor (fiscaal) risicomanagement. Onze ervaring leert dat een organisatie doorgaans heel erg veel beheersingsmaatregelen en procedures heeft ontwikkeld voor business control frameworks, die nog niet als onderdeel van een TCF worden herkend en die in (papieren) procedures zijn vastgelegd. Eén geïntegreerd platform brengt dynamiek in het geheel. Integratie met een BCF is belangrijk.
  • Geautomatiseerde tools. Een volledig geïntegreerd BCF is vaak een complex geheel. Een geautomatiseerde controls monitoring tool kan hier uitkomst bieden.
  • Structuur. Een gestructureerde aanpak en vastlegging zorgt ervoor dat een TCF zich richt op de belangrijkste risico’s en processen.
  • Communicatie. Organisaties zijn doorgaans in control. Wat moeilijker is, is om aan te tonen dat zij in control zijn. Het gaat om communicatie met andere afdelingen, in- en externe auditors, het bestuur, de fiscus en commissarissen. Een helder TCF met gestructureerde overzichten en rapportages is voor deze communicatie naar onze mening onontbeerlijk.

Verder willen wij graag tot slot nog een keer benadrukken dat de aandacht voor een TCF weliswaar sterk is toegenomen door horizontaal toezicht, maar dat het beheersen van de fiscaliteit in de onderneming van essentieel belang is voor een goede bedrijfsvoering. Een TCF zou dan ook niet beperkt moeten worden tot de Nederlandse fiscaliteit. Dit zal er overigens niet alleen toe leiden dat organisaties hun fiscale risico’s beter kunnen beheersen, maar creëert daarnaast ook meer inzicht in de mogelijkheden om fiscale kansen te benutten.

Literatuur

[Bela08] Tax Control Framewok; Van risicogericht naar ‘in control’: het werk verandert, Belastingdienst, maart 2008.

[KPMG08] Governance, Risk, and Compliance, Driving Value through controls monitoring, KPMG Advisory, 2008.

[KPMG09] Total TAX Control, Tax Accounting & Control Services, KPMG Meijburg & Co, 2009.

[OECD08], Study into the Role of Tax Intermediaries, Fourth OECD Forum on Tax Administration, Cape Town, South Africa, January 2008.

[Zege07] A.T.M. Zegers, Omzetbelastingwetgeving en ERP-systemen – een overbrugbare kloof?, Master’s Thesis, Eindhoven University of Technology, The Netherlands, 2007.

E-factureren: efficiënt én betrouwbaar?

Het elektronisch versturen en ontvangen van facturen heeft sinds de introductie van het internet en fiscale wet- en regelgeving in 2001 en 2004 een minder snelle groei doorgemaakt dan door marktvorsers verwacht. De meeste e-facturen zijn momenteel zowel elektronisch als op papier verstuurde facturen en gescande op papier ontvangen facturen. De stringente eisen en het gebrek aan standaarden maakten de drempel hoog. Enkele maanden geleden is door de afkondiging van de staatssecretaris van Financiën verlichting van de administratieve verplichtingen in werking getreden, die deze drempel significant verlaagt. Althans voor e-factureren in Nederland; internationaal zijn er nog aanzienlijke verschillen aanwezig. Dit artikel gaat aan de hand van onder andere een casus in op de eisen en mogelijkheden in beide situaties.

Introductie

Elektronisch factureren[Onder elektronisch factureren verstaan we in dit artikel het op elektronische wijze uitwisselen (overzenden of ontvangen), verwerken en bewaren van facturen.] is eindelijk in opmars, nadat het sinds 1992 in Nederland expliciet is toegestaan. Uiteraard zal kostenbesparing in deze tijd van economische crisis een belangrijke drijfveer zijn, maar daarnaast zijn er ook andere oorzaken die de toepassing stimuleren (voor een uitgebreid overzicht van voor- en nadelen zie onder andere [Koor03]). Ook de aankondiging van de minister van Economische Zaken dat de overheid in plaats van de huidige zes procent in 2010 tien procent en in 2014 tachtig procent van de facturen elektronisch wil ontvangen en verwerken en het door het ministerie van EZ aanstellen van een e-factureringsambassadeur (Marco Pastors) hebben een positieve bijdrage geleverd.

Niet in de laatste plaats speelt natuurlijk het besluit van de staatssecretaris van Financiën van 16 februari 2009 een rol bij de toename. Tekenend voor de daadkracht van het kabinet is die administratieve verlichting reeds per 12 februari ingegaan. In het besluit is voor Nederland een aantal vereenvoudigingen geregeld, vooruitlopend op het voorstel van de Europese Commissie om de verschillen tussen papieren en elektronische facturen weg te nemen ([Bcpp09]). Hoewel in Nederland daardoor een aantal drempels is weggenomen, blijven de vigerende regels in een internationale context vooralsnog onverkort van kracht. Het is ongewis of en zo ja, wanneer alle EU-landen een lichter regime voor e-facturen invoeren; onderhandelingen daarover waren in september 2009 nog volop gaande. Voor bedrijven die elektronisch factureren met partijen buiten Nederland liggen er vooralsnog nog voldoende ‘uitdagingen’ in het verschiet – ook al zijn ook andere EU-landen bezig met het vereenvoudigen van hun wettelijke eisen aan e-factureren.

C-2009-3-Koorn-FokkeSukke-080416

In Nederland heeft de staatssecretaris elektronisch factureren voor organisaties eenvoudiger en daarmee aantrekkelijker willen maken. Welke eisen zijn per 12 februari 2009 komen te vervallen? Het transportvehikel van de factuur is vorm- en middelvrij geworden en mag door de organisatie zelf worden bepaald. Als de staatssecretaris geen expliciete eisen meer stelt aan de integriteit en authenticiteit van facturen[Volgens artikel 52 lid 1 AWR.], waar moeten bedrijven zich dan aan conformeren? Neem het voorbeeld van een valse factuur in de administratie, zoals recentelijk vele organisaties overkwam met valse KvK-facturen. Een bedrijf heeft deze factuur volledig betaald en de btw in aftrek gebracht. Wat zijn de gevolgen als deze factuur bij een interne controle of boekonderzoek wordt gelicht en gecontroleerd? Zeker als het om substantiële btw-bedragen handelt zullen er op zijn minst discussies volgen, zowel intern bij het betreffende bedrijf als met de Belastingdienst. Geen eisen betekent daarom niet noodzakelijkerwijs: geen probleem.

Elektronisch factureren kan bovendien niet als losstaand onderwerp worden beschouwd. Het maakt onderdeel uit van een speelveld waarin ook elektronisch inkopen (e-procurement), elektronisch archiveren en scanning (van papier naar digitaal) en elektronisch betalen een rol (kunnen) spelen. In veel gevallen betekent het introduceren van elektronisch factureren dat er tevens elektronisch moet worden gearchiveerd. Al deze onderwerpen hebben bovendien hun eigen raakvlakken met bedrijfsprocessen, ICT en (inter)nationale belastingwetgeving. E-facturering is hierdoor alleen met een multidisciplinair team goed op te zetten.

In dit artikel willen wij na een korte introductie van een aantal e-factureringsontwikkelingen en de vereisten in de Europese Unie ingaan op de business case van elektronisch factureren en een aantal van onze praktijkervaringen bespreken. Vervolgens schetsen we de te onderkennen trends en ontwikkelingen en de wijze waarop de beheersing en audit van elektronisch factureren gestalte kan krijgen. Uiteraard sluiten we af met een conclusie.

Trends en ontwikkelingen

Hieronder volgt een beknopte uiteenzetting van een aantal relevante trends en ontwikkelingen op e-factureringsgebied die een positief effect hebben op de toepassing ervan:

  • De toepassing van het internet voor primaire handelstransacties neemt sterk toe, inclusief het gebruik van elektronisch factureren. Tevens gaan multinationals en overheidsorganisaties over tot de vorming van shared service centers die op basis van een ERP-systeem de gehele (financiële) administratievoering en facturering voor alle landenorganisaties uitvoeren.
  • De initiatieven tot Europese standaardisatie en harmonisatie dragen positief bij aan de adoptie van elektronisch factureren.
  • De groeipercentages verschillen nog sterk per land. Noordwest-Europese landen kennen de hoogste groeipercentages, Zuid- en Oost-Europa zijn wat dat betreft in opkomst. Afgezien van het innovatieklimaat hangt het succes sterk af van de stimulans die uitgaat van sectorale en/of overheidsimpulsen. In een sector of gesloten gebruikersgroep kan eenvoudiger worden overgegaan tot één standaardformaat voor e-facturen. Meestal spelen serviceproviders hierop in met een gestandaardiseerde oplossing[Voorbeeld hiervan betreft de autobranche, waar leasemaatschappijen, schadeherstelbedrijven, dealers en dergelijke e-facturering succesvol hebben ingezet.]. Ook het verplichten of financieel bevoordelen van elektronische uitwisseling van facturen door overheden kan het benodigde zetje in de rug geven.
  • De groei ziet vooral op binnenlandse, business-to-business of organisatie-interne elektronische facturen. Verder zijn de meeste e-facturen momenteel nog gescande op papier ontvangen facturen. Door onzekerheden op wettelijk en fiscaal terrein blijft de groei van de business-to-consumer en grensoverschrijdende elektronische facturen hierbij sterk achter.
  • Technische belemmeringen worden in toenemende mate weggenomen, vooral door de opkomst van gespecialiseerde dienstverleners (Billing Service Providers) en pakketleveranciers die de mogelijkheid van elektronisch factureren aanbieden. Ook hebben diverse ERP- en financieel-pakketleveranciers in het afgelopen jaar een gestandaardiseerde koppeling met enkele Billing Service Providers gerealiseerd. Voorts zijn er meerdere pdf-varianten beschikbaar gekomen, die geautomatiseerd kunnen worden verwerkt (pdf-inhoud als XML-factuurbericht) of goed kunnen worden gearchiveerd (pdf/A).
  • Het aanbod van de dienstverlening is nog vrij gefragmenteerd en het is de vraag of alle potentiële gebruikers worden bereikt. Instellingen als het ministerie van EZ, ECP.nl, banken en administratiekantoren kunnen een essentiële intermediairsrol spelen bij het breed introduceren van e-factureren in het mkb. Organisaties met één of enkele gecentraliseerde factureringsplatformen, grote zakelijke klanten en/of gebruikmaking van één Billing Service Provider zijn in het voordeel voor een snelle overgang naar e-facturen. Wel geeft het gebruik van kleine Billing Service Providers het risico dat sommige niet zeven jaar zullen voortbestaan en diens klanten niet gegarandeerd zijn van het voldoen aan de verplichte bewaartermijnen.
  • Ondanks Europese standaardisatie en harmonisatie zijn er verschillen in de invoering van de Europese richtlijnen in de lidstaten ontstaan, hetgeen in de praktijk heeft geleid tot landspecifieke eisen. De belangrijkste verschillen liggen op het terrein van btw, elektronische handtekeningen, meldings/vergunningsplicht, archivering (bewaartermijn en locatie) en toegankelijkheid van externe factuuropslag. Dit is op Europees niveau onderkend en recentelijk aangepakt. Het uiteindelijke doel is om te komen tot een ‘Single European Electronic Market’.

Zoals hiervoor aangegeven zijn in Nederland de administratieve en factureringsverplichtingen op het gebied van de omzetbelasting vervangen. In dat kader zijn de regels voor elektronisch factureren vereenvoudigd. De wijze van opmaak en het versturen van elektronische facturen kan vorm- en middelvrij plaatsvinden en de elektronische factuur heeft nu dezelfde status als een papieren exemplaar. Dit betekent dat voor zowel de papieren als de digitale factuur de verzending niet meer is gebonden aan wettelijke eisen of vaste methoden. Navolgend zal worden ingegaan op de generieke vereisten die tot februari jl. in Nederland en momenteel nog in de meeste Europese landen van toepassing zijn.

Vereisten e-factureren

EU-vereisten

In de EU bestaat er de richtlijn elektronisch factureren[Richtlijn 2006/112/EC (waarin de eerdere richtlijn 2001/115/EC is opgenomen).] waarop iedere lidstaat zijn eigen wetgeving moest baseren. Het doel van de richtlijn betreft het vereenvoudigen, moderniseren en harmoniseren van de voorwaarden waaraan de lidstaten moeten voldoen ten aanzien van elektronische facturatie binnen de Europese Unie. Hoewel elke lidstaat deze richtlijn binnen zijn eigen wetgeving heeft geïmplementeerd, bestaan er inhoudelijke verschillen tussen de manier waarop de lidstaten dit hebben gedaan. Zo eisen sommige landen een geavanceerde elektronische handtekening op basis van een gekwalificeerd certificaat, waar andere landen deze methode niet volledig accepteren en juist andere eisen stellen aan het vaststellen van de authenticiteit van de verzender.

Als gevolg hiervan kan het zo zijn dat een elektronische factuur in het ene land wel en in het andere land niet wordt geaccepteerd. Een potentieel risico hierbij is het in gevaar komen van het aftrekrecht van de btw voor de factuurontvanger. Dit maakt het voor bedrijven erg lastig om concreet inzichtelijk te hebben of men compliant is aan de landspecifieke vereisten voor e-facturering in de landen waar men actief is. Bedrijven willen zekerheid verkrijgen dat bij een fiscale controle de btw-aftrek over meerdere jaren niet in de waagschaal wordt gesteld.

Een belangrijk punt hierbij is de bepaling van het land waarvan men moet nagaan welke eisen gelden ten aanzien van e-facturering. In beginsel speelt de plaats van levering of dienst hierin een cruciale rol. De regels hieromtrent zijn vastgelegd in de Europese richtlijn voor btw-wetgeving en betreffen één van de lastigste aspecten voor het correct bepalen van btw-vereisten. Dit heeft tot gevolg dat het per type levering, zoals rechtstreekse levering of indirecte levering, kan verschillen wat de landspecifieke vereisten voor e-facturen zijn. Andere eisen die per lidstaat kunnen verschillen zijn onder meer:

  • factuurvorm en -inhoud;
  • bewaarplicht van facturen;
  • controleerbaarheid.

Aandachtsgebieden van het e-factureringsproces

Het proces van elektronisch factureren en factuurverwerking verschilt in een aantal processtappen van het ‘klassieke’ factureringsproces. Er wordt uiteraard geen papieren factuur meer opgemaakt en er worden processtappen onderscheiden voor het kunnen borgen van authenticiteit van de factuur. In figuur 1 is dit proces schematisch weergegeven, waarbij al dan niet sprake is van een tussenpersoon zoals een zogenoemde Billing Service Provider (zoals value added netwerken als Billington, JP Morgan, Anachron, OB10, Certipost, Bluem en Isabel).

C-2009-3-Koorn-01

Figuur 1. Generieke e-factuuruitwisseling.

Binnen deze processen kunnen de belangrijkste aandachtsgebieden met betrekking tot e-factuurvereisten worden afgezet tegen de volgende aandachtsgebieden:

  • generieke eisen;
  • elektronisch ondertekenen;
  • archivering.
Generieke eisen

Deze betreffen algemene zaken als:

  • Is e-facturering überhaupt toegestaan?

    Dit betreft een vrij triviale eis, maar er zijn nog steeds landen in de wereld waar (louter) e-factureren niet is toegestaan. Hier is het noodzakelijk ook facturen op papier beschikbaar te maken, veelal naast het tevens uitwisselen van e-facturen. Bij het ontstaan van een parallelle stroom aan e-facturen is het identiek houden van de fysieke en elektronische factuurstroom lastig in het geval van dubbele betalingen van zowel papieren als e-factuur, latere factuurwijzigingen, creditfacturen, en dergelijke.
  • Moeten de lokale Belastingdiensten op de hoogte worden gesteld?

    In de EU is het sinds 1 januari 2006 niet meer toegestaan de lokale Belastingdienst in kennis te stellen, tenzij deze EU-lidstaat aanvullende eisen had gesteld, zoals verplicht vooroverleg of expliciete toestemming voor het toepassen van een andere e-factureringsmethode dan via EDI of via publieke netwerken met elektronische ondertekening.
  • Zijn uitzonderingen toegestaan?

    Mag bijvoorbeeld self-billing in een bepaald land worden toegepast, waarbij de afnemer de facturen voor de leverancier opstelt? Ook zaken als de verleggingsregeling en het moeten meesturen van een papieren factuur met een internationale goederenzending kunnen om afwijkende oplossingen vragen.
  • Eisen aan afspraken met derden?

    Wanneer het factureringsproces is uitbesteed aan een derde partij, moet zekerheid worden verkregen of de Billing Service Provider een voldoende beheerst proces heeft dat voldoet aan het scala aan landspecifieke eisen omtrent e-facturering. In sommige EU-landen worden bepaalde eisen gesteld aan de detailafspraken die bedrijven maken met dergelijke partijen waaraan (een deel van) het factureringsproces is uitbesteed.
Elektronisch ondertekenen: authenticiteit en integriteit van de afzender

De doelstelling is het waarborgen van de authenticiteit en integriteit van de factuurafzender en de onweerlegbaarheid van factuurgegevens. De factuur moet authentiek zijn: de afnemer moet er zeker van kunnen zijn dat de factuur werkelijk van de leverancier afkomstig is. De factuur moet ook integer zijn: de leverancier en de afnemer moeten er zeker van kunnen zijn dat de factuur onveranderd blijft gedurende de gehele levenscyclus, inclusief bij langdurige archivering.

Wettelijke eisen hieromtrent hebben betrekking op:

Geavanceerde elektronische handtekening

Een geavanceerde handtekening bestaat uit gegevens over de ondertekenaar (de factuurafzender) en een certificaat van een interne Public Key Infrastructure (PKI) of van een certificaatdienstverlener. Aan de geavanceerde handtekening wordt een aantal vereisten gesteld boven op de eisen die aan een ‘gewone’ elektronische handtekening worden gesteld. Enkele van die eisen betreffen:

  • unieke verbondenheid aan de ondertekenaar;
  • mogelijkheid tot identificatie van de ondertekenaar;
  • gebaseerd op een gekwalificeerd certificaat dat voldoet aan eisen uit de telecommunicatiewet.

In [Besl03] en [Koor03] wordt uitgebreider ingegaan op de eisen aan en invulling van het elektronisch ondertekenen van facturen.

Electronic Data Interchange (EDI)

In tegenstelling tot de (geavanceerde) elektronische handtekening wordt bij EDI de authenticiteit en integriteit van een elektronische factuur niet gewaarborgd door de kenmerken van het bericht zelf. Bij gesloten EDI-netwerken wordt een waarborg gecreëerd door de procedures omtrent geauthenticeerde deelname van bedrijven en de verwerking van het bericht. Het is daarom noodzakelijk dat de factuurafzender en factuurontvanger afspraken maken over deze procedures. Het is gebruikelijk om dit te doen via een zogenoemde Interchange Agreement. Een Interchange Agreement bevat onder andere de namen van de betrokken partijen en contactpersonen, het doel waarvoor de gegevens gebruikt mogen worden en afspraken rond levering van gegevens en leverings- en bewaartermijnen.

Door het ontstaan van hybride vormen van EDI en internetuitwisseling van facturen is niet altijd duidelijk of de eisen gesteld aan gesloten EDI-netwerken of die gesteld aan open publieke netwerken van toepassing zijn. Een aantal EU-landen beschouwt EDI-transport via het internet echter niet als pure EDI, waardoor de aangesloten bedrijven genoodzaakt zijn een elektronische handtekening of andere maatregelen toe te passen.

Archivering: authenticiteit en integriteit van opgeslagen factuur

De doelstelling is het waarborgen van de authenticiteit en integriteit van de opgeslagen factuur, het vastleggen van de audit-trail en eisen aan leesbaarheid van de factuur. Specifieke eisen bij archivering kunnen betrekking hebben op:

  • Locatie van opslag

    Mogen servers waarop facturen zijn opgeslagen die door externe ICT-serviceproviders worden beheerd, zich in elk willekeurig land bevinden? Enkele EU- en niet-EU-landen stellen hierin eigen eisen en verplichten bijvoorbeeld om facturen fysiek op te slaan in het land van de facturerende partij of factuurontvanger. Duitsland is een voorbeeld van een EU-land waar e-facturen verplicht binnen de EU opgeslagen dienen te worden.[Voorheen was bewaring van e-facturen op eigen grondgebied zelfs vereist.]
  • Wettelijke bewaartijd van opgeslagen facturen

    Ook hiervoor gelden landspecifieke eisen. In Nederland geldt dat facturen minimaal zeven jaar moeten worden bewaard. Een tot zeven jaar oude e-factuur gestructureerd kunnen opvragen kan de achilleshiel vormen door fusies, overnames en periodieke wijzigingen in informatiesystemen, hardware, tapesystemen en dergelijke. Het verdient aanbeveling om te onderzoeken welk land in scope de langste bewaartermijn heeft en daarop de bewaartermijn te baseren. Voor bepaalde typen transacties gelden overigens afwijkende bewaartermijnen, zoals bijvoorbeeld bij vastgoedtransacties. In [Ecpnl07] staan de eisen aan bewaartermijnen voor verschillende typen informatie en documenten vermeld.
  • Formaat waarin de factuur moet worden opgeslagen

    Hierbij wordt onderscheid gemaakt tussen leesbaarheid voor mensen zoals een pdf of leesbaarheid voor computers (XML of anders gestructureerd dataformaat). Veel landen eisen het kunnen reproduceren van menselijk leesbare facturen, maar in toenemende mate worden computer-leesbare vormen toegestaan. Diverse organisaties bewaren nu zowel de papieren als de overeenkomstige elektronische facturen, terwijl dit bij een goede inrichting ook alleen elektronisch zou mogen.
  • Snelheid van ontsluiting

    Bij een fiscale controle is het vereist dat facturen uit voorgaande jaren binnen redelijke termijn beschikbaar kunnen worden gesteld. Fiscale autoriteiten in een aantal EU-landen hanteren daarbij soms vuistregels, bijvoorbeeld dat online bewaarde facturen binnen twee dagen (bijvoorbeeld in een ERP-systeem) en offline facturen binnen twee weken (bijvoorbeeld op tapes) reproduceerbaar zijn.

Ondanks het feit dat wettelijke vereisten aan e-facturen gespiegeld ook van toepassing zijn op ontvangen e-facturen, laat het overzicht zien dat er een onderscheid bestaat tussen inkomende en uitgaande facturen. Inkomende facturen hoeven uiteraard niet meer te worden voorzien van een elektronische handtekening. Wel moet er een proces worden ingericht om de authenticiteit en integriteit van de inkomende factuur te controleren of de e-factuur te voorzien van een tijdsindicatie (‘timestamping’).

Bedrijven die overwegen om een e-factureringsproces in te richten zullen voor het in kaart brengen van de wettelijke vereisten na moeten gaan vanuit welke landen facturen worden ontvangen en naar welke landen facturen worden verstuurd, aangezien voor het opstellen van de factuur dezelfde eisen aanzienlijk strenger worden gehanteerd dan voor het ontvangen van facturen. Het zou onnodige inspanning en overeenkomstige kosten met zich meebrengen om compliant te zijn aan landspecifieke eisen in gevallen waarin dat geen vereiste is. Alhoewel het voor multinationals efficiënter kan blijken één generieke e-factureringsoplossing dan allerlei landspecifieke oplossingen te ontwikkelen en te beheren. Mede vanwege deze verschillende vereisten wordt ook vaak overgegaan tot uitbesteden.

Business case e-facturering

De klassieke vorm van factureren is alleen efficiënter dan e-facturering indien sprake is van uitwisseling met partijen in veel verschillende landen, met lage volumes, met veel factuurbijlagen en/of met lage standaardisatiegraad van factuurvorm en -inhoud. In andere gevallen kan e-factureren efficiëntievoordelen bieden, bij lage volumes veelal met gebruikmaking van gespecialiseerde Billing Service Providers.

E-facturering biedt de mogelijkheid om de verwerking van uw inkomende facturen te optimaliseren. Een en ander is natuurlijk afhankelijk van de manier waarop het in- en uitgaande factureringsproces binnen organisaties organisatorisch, operationeel en technisch gerealiseerd is. Bottom-up kan een succesvolle implementatie van een e-factureringsproces leiden tot:

  • Procesoptimalisatie:
    • Kostenbesparing: lagere personeelskosten voor inboeken en verwerking van facturen. Ook het gebruik van een digitaal archief verlaagt de administratieve kosten.
    • Kwaliteitsverbetering: lagere foutgevoeligheid bij invoer en verwerking van facturen.
    • Verhoging processnelheid: sterke reductie handmatige afhandeling voor twee- of drieweg-matching van factuur met order en/of levering.
    • Gedragsverbetering: betere beheersing betalingsgedrag en een snellere verwerking.
  • Managementinformatie:
    • Verhoogd inzicht in het in- en verkoopproces: betere rapportages over leveranciers- en klantkarakteristieken.
    • Adequaat inzicht in factuurstatus: facturen zijn digitaal opgeslagen en raken daardoor niet meer kwijt.
  • Kostenbesparing voor meerdere partijen in de keten. Hiermee wordt een netto lastenverlichting gerealiseerd.

Besparingsmogelijkheden

In recente onderzoeken wordt geschat dat de kosten voor ontvangst, verwerking en betaling van een inkomende factuur gemiddeld € 30 à € 50 bedragen ([Hels08] en [Foru07]). Voor inkomende facturen kunnen deze kosten worden gereduceerd tot € 10 respectievelijk € 1 per factuur bij toepassing van een semi-geautomatiseerd of volledig geautomatiseerd e-factureringsproces. In het algemeen kan worden gesteld dat besparingsdoelstellingen van tientallen procenten van de factureringskosten en van één tot twee procent van de totale omzet realistisch zijn ([Koch09]).

Om een goede business case te kunnen maken voor de keuze voor implementatie van e-facturering, moeten de volgende aandachtspunten in ogenschouw worden genomen ([Koch09]):

C-2009-3-Koorn-t1

Belangrijke succesfactoren met betrekking tot e-factureringsprojecten hebben met name betrekking op een hoge mate van betrokkenheid van enerzijds het senior (financieel) management om deze processen te digitaliseren en het proces van e-facturering te beheersen, en van anderzijds ketenpartijen om de potentiële besparingsmogelijkheden ook te kunnen effectueren. De business case van een dergelijk project omvat meer dan reductie van print- en postzegelkosten. Met name het bereiken van een betere efficiëntie voor administratieve en vaak tijdrovende processen leidt tot de belangrijkste kostenbesparingen. Vaak wordt er nauwelijks stilgestaan bij de sterke toename van interne beheersing door verhoging van ICT-afhankelijkheid. Dit terwijl in grote mate gesteund wordt op ICT-controls bij ontvangst, verwerking en afhandeling van in- en uitgaande facturen.

Een andere belangrijke succesfactor is de aanwezigheid van een meerjarendoelstelling en -strategie. Hieraan moet een implementatiestrategie worden gekoppeld waarin stap voor stap naar de einddoelstelling toe wordt gewerkt. Al tijdens stap 1 moeten quick wins worden behaald om zo op korte termijn al de voordelen en kostenbesparingen van e-facturering te realiseren. Wanneer dit ook intern zichtbaar gemaakt wordt zal dit leiden tot sterkere commitment van alle betrokken belanghebbenden. Een veelgekozen eerste stap is het kanaliseren naar één factuurstroom binnen een grote divisie van het bedrijf. Hiermee kan gemakkelijk een key focus worden gerealiseerd op een primaire factuurstroom.

Door middel van een efficiëntere inrichting van het facturerings- en betalingsproces kunnen tevens procesmatige kostenbesparingen op het gebied van werkkapitaal worden gerealiseerd. Behoudens bestaande betalingsafspraken met leveranciers en afnemers kan beter worden gemonitord op het handhaven van de geplande days payables outstanding (DPO) en days sales outstanding (DSO). Er kan tevens sterker worden gestuurd op het voorkomen van onnodige renteverliezen door te vroeg betalen of het te laat ontvangen van betalingen, alsmede op het voorkomen van onnodig mislopen van kortingen en bonussen als gevolg van te laat betalen. Zeker in deze tijd van economische recessie zijn dit kostenbesparingen die eenvoudig te realiseren zijn.

Casus

KPMG heeft recent een aantal projecten uitgevoerd met betrekking tot het in kaart brengen van wettelijke en fiscale landspecifieke eisen op het gebied van e-facturering en de implicaties hiervan voor veelal complexe ICT-omgevingen. Dergelijke haalbaarheidsstudies zijn noodzakelijk om aard en omvang van implementatie van een e-factureringsoplossing te kunnen realiseren. Een belangrijke vraag is hierbij welke landen in scope zijn voor de in- en uitgaande kant van de factuurstroom. Dit bepaalt voor een groot deel de complexiteit van de gewenste oplossing. De huidige vorm van het IT-landschap kan tot extra implicaties leiden. Wanneer bijvoorbeeld wereldwijd databaseservers worden gehost via externe ICT-serviceproviders en op deze servers vindt opslag plaats van facturen die betrekking hebben op meerdere landen, is het maar de vraag of dit vanuit e-factureringsperspectief (a) wel toegestaan is en (b) het meest efficiënt is.

E-factureringstrajecten (zie figuur 2) bestaan normaliter uit twee hoofdfasen:

  • eisenspecificatie & impactanalyse;
  • realisatie & on-boarden.

C-2009-3-Koorn-03

Figuur 2. De twee hoofdfasen van e-factureringstrajecten.

Eisenspecificatie & impactanalyse

Stap 1 van een e-factureringstraject betreft het concretiseren van de wijze waarop de organisatie in haar ketens wil opereren en welke stappen in de inkoop-, facturerings- en betalingsprocessen te digitaliseren zijn. Op basis van dit specifieke businessmodel valt de impact op de organisatie en de set met functionele eisen aan de e-factureringsoplossing af te leiden. Essentieel is dat de belangrijkste klanten en/of leveranciers e-facturen willen versturen of ontvangen – of dat dit als marktleider bij hen af te dwingen is.

Stap 2 betreft het in kaart brengen van fiscale en juridische vereisten gegeven het huidige businessmodel. Deze stap moet antwoord geven op vragen zoals:

  • Hoe lopen de factuurstromen?
  • Welke landen stellen welke eisen aan in- en uitgaand elektronisch factuurverkeer?
  • Kunnen we kiezen voor één of enkele complianceniveau(s) om diverse landspecifieke oplossingen te vermijden?
  • Wat is onze risicotolerantie, met andere woorden accepteren we situaties die niet overal aan alle vereisten voldoen of niet?

Deze stap resulteert in een definitie van de grootste gemene deler van de eisen waaraan de organisatie moet voldoen om tot een compliant e-factureringsoplossing te komen. Eisen die van land tot land verschillen kunnen worden samengevoegd tot een pakket van eisen waarmee de verplichtingen binnen elk land worden afgedekt. Het is complexer om tien verschillende bewaartermijnen te handhaven dan één bewaartermijn voor alle landen (veelal de strengste).

Een ander voorbeeld betreft het geavanceerd elektronisch ondertekenen van e-facturen met gekwalificeerde certificaten ten behoeve van buitenlandse afnemers. Hiermee wordt ook tegemoetgekomen aan de eisen van de op dit punt strengste EU-landen. In figuur 3 is ter illustratie een globaal schema opgenomen van een bedrijf dat gebruikmaakt van het webportaal van een Billing Service Provider, een afzonderlijke Certificate Service Provider en elektronisch getekende facturen.

C-2009-3-Koorn-03

Figuur 3. Voorbeeld systeeminrichting bij gebruik Billing Service Providers.

Stap 3 maakt een vertaling van deze resultaten uit stap 1 en stap 2 naar de implicaties voor de procesketen en het huidige ICT-landschap. Dit leidt meestal tot de beschrijving van een aantal oplossingsscenario’s met bijbehorende invoeringsaanpak van een eindoplossing, zowel in de organisatie als bij de ketenpartijen aan klant- en leverancierszijde. Deze afzonderlijke scenario’s moeten op kosten en haalbaarheid worden getoetst om tot de meest realistische en efficiënte oplossing te komen.

Realisatie & on-boarden

Stap 4 behelst het opstellen van een functioneel (her)ontwerp van de desbetreffende processen en ICT-oplossing. Vervolgens kan een organisatie kiezen voor het aanpassen van de bestaande factureringssystemen, het gebruiken van functionaliteit voor e-facturering in financiële softwarepakketten of het uitbesteden aan een Billing Service Provider. De gekozen oplossingsrichting met implementatieplan bepaalt of vervolgens nog een technisch ontwerp noodzakelijk is. Het is hierbij van belang dat continu wordt getoetst op de opgestelde wettelijke eisen uit de specificatiefase.

Dergelijke e-factureringsprojecten vereisen specialistische kennis van zowel applicaties als wetten en regels omtrent e-facturering. Maar belangrijker, een goede samenwerking tussen fiscale, juridische en ICT-disciplines. We zien in de praktijk nogal eens dat er veel miscommunicatie optreedt tussen fiscalist en juristen en ICT-medewerkers die moeten zorg dragen voor de daadwerkelijke implementatie. Een succesvol e-factureringstraject valt of staat met een samenwerking tussen disciplines waarbij buiten de kaders van het eigen specialisme wordt gedacht en gewerkt. Op deze manier wordt de kenniskloof tussen beide overbrugd en worden kansen op begrips- en communicatiefouten geminimaliseerd.

In stap 5 kan – zo nodig na een pilot met een paar ‘launching customers’ – de verdere uitrol plaatsvinden. Veelal blijkt dat het synchroniseren van implementatieplannen bij diverse organisaties voor het gebruikmaken van e-facturen lastig is; iedere organisatie heeft een eigen prioriteitstelling en planning.

Beheersen e-facturering

Zoals eerder aangegeven zijn door het besluit van de staatssecretaris niet alle eisen aan een betrouwbare toepassing van e-facturering vervallen, alleen het transportmiddel is vorm- en middelvrij geworden. Gedegen AO/IB[Administratieve Organisatie & Interne Beheersing.] is voor e-facturen nog immer van belang. In tabel 1 zijn de belangrijkste aandachtsgebieden, vereisten en mogelijke beheersingsmaatregelen opgenomen; deze gelden als voorbeelden en zijn niet limitatief. Hierbij is vrijwel geen onderscheid gemaakt tussen debiteuren- en crediteurenfacturen.

C-2009-3-Koorn-t2

Tabel 1. Aandachtsgebieden, eisen en voorbeeldmaatregelen.

In NIVRA/NOvAA-verband[NIVRA: Koninklijk Nederlands Instituut van Registeraccountants; NOvAA: Nederlandse Orde van Accountants-Administratieconsulenten.] wordt momenteel geschreven aan twee publicaties[De auteurs van dit artikel zijn bij de totstandkoming van beide publicaties betrokken.] waarvan in de ene de administratieve verwerking en in de andere de accountantscontrole van e-facturering wordt behandeld. Hierbij wordt aangesloten bij de recente e-factureringspublicatie van het mkb ([Ecpnl09]). In de publicatie over administratieve verwerking zal nader worden ingegaan op de beheersingsmaatregelen die een organisatie kan treffen voor een betrouwbare verwerking van elektronische facturen. Beide publicaties zullen eind 2009, begin 2010 door NIVRA/NOvAA worden verspreid.

Conclusie

Een lang artikel heeft een beknopte conclusie nodig. Wij verwachten dat eindelijk de sterke groei van e-facturering zich zal voordoen. De overheidsstimulering en wettelijke verlichting zullen hieraan bijdragen. Het wegvallen van wettelijke eisen betekent geen vrijhaven, maar het bepalen van een evenwichtige inrichting van de e-factureringsoplossing. De pakketten van softwareleveranciers en diensten van service providers kunnen hieraan een nuttige bijdrage leveren, maar niet in de gehele (geprogrammeerde) interne controle en interne beheersing rond e-facturering voorzien. Een multidisciplinair – en zo mogelijk internationaal – team is vereist om de gekozen oplossing voor e-facturering operationeel én compliant te krijgen. Gelukkig kan de reeds opgedane praktijkervaring worden benut voor een gedegen implementatie en toepassing.

Literatuur

[Besl03] Besluit van 8 mei 2003, houdende de vaststelling van eisen voor het verlenen van diensten voor elektronische handtekeningen (Besluit elektronische handtekeningen). Jaargang 2003.

[Bcpp09] Belastingdienst/Centrum voor Proces- en Productontwikkeling. Omzetbelasting. Administratieve en factureringsverplichtingen. Besluit van 12 februari 2009, nr. CPP2009/263M, Stcrt. nr. 32.

[CEN09] CEN Workshop Agreement. E-Invoicing Compliance Guidelines, working draft, 28 mei 2009.

[Ecpnl07] ECP.nl, Bewaren en Bewijzen, maart 2007.

[Ecpnl09] ECP.nl-EPN, E-factureren voor het bedrijfsleven, september 2009.

[Foru07] Forum Standaardisatie, Verkenning elektronisch factureren, 20 maart 2007.

[Hels08] Helsinki School of Economics, Electronic Invoice initiatives in Finland and in the European Union, 2008.

[Inno08] Gilbert Lichter (EBA) en Douwe Lycklama (Innopay), E-invoicing 2008. European market description and analysis, 2008.

[Koch09] Bruno Koch (Billentis), E-Invoicing / E-Billing in Europe – Taking the next step towards automated and optimised processes, 10 februari 2009.

[Koor03] R.F. Koorn, J. ter Hart en L. Yap, Efficiëntievoordelen behalen met elektronisch factureren?, Compact 2003/4.

[Mull03] M. Muller, R.J.M. van Langen en M.A. van Ginderen, De rol van de IT-auditor bij factureerprocessen, Compact 2003/1.

[NIVR95] NIVRA-geschrift 64, Electronic Data Interchange (EDI); beheersing en controle, 1995.

[Wolt04] E.J. Wolters en C.F.J. Hoffman, De evolutie van het inkoopproces, Management Executive, september/oktober 2004.

Testen van informatiesystemen en het gebruik van (geanonimiseerde) persoonsgegevens

Ten behoeve van het testen van de juiste werking van informatiesystemen worden gegevens vaak in hun geheel vanuit de database van een bestaand informatiesysteem naar de database van het te testen systeem gekopieerd. Hierbij worden ook bestaande persoonsgegevens gebruikt. De Wet bescherming persoonsgegevens (Wbp) maakt onderscheid tussen ‘normale’ persoonsgegevens en bijzondere persoonsgegevens. Onder de bijzondere persoonsgegevens vallen alle gegevens die informatie kunnen geven over godsdienst, ras, politieke gezindheid, gezondheid, lidmaatschap van een vakvereniging of strafrechtelijk verleden van een persoon. Deze wet geeft aan dat, in het geval van bijzondere persoonsgegevens, bij voorkeur fictieve persoonsgegevens dienen te worden gebruikt. Om te voldoen aan de Wbp hebben organisaties een aantal mogelijkheden. Verreweg de meest eenvoudige (en goedkoopste) is het anonimiseren van bestaande persoonsgegevens. Dit artikel gaat in op de risico’s van het testen van de juiste werking van informatiesystemen met behulp van bestaande persoonsgegevens en legt uit hoe organisaties ten behoeve van testdoeleinden bestaande persoonsgegevens eenvoudig kunnen anonimiseren.

Inleiding

Consumenten en organisaties kunnen bankzaken tegenwoordig via internet regelen. Zorgverzekeraars bieden mogelijkheden om declaraties online in te dienen. Paspoorten en rijbewijzen kunnen bij gemeenten digitaal worden aangevraagd. De hiervoor genoemde diensten worden mogelijk gemaakt door informatiesystemen[Onder een informatiesysteem verstaan we in dit artikel een set aan elkaar gerelateerde bedrijfsmiddelen die informatie verzamelen (zoeken), verwerken, opslaan en verspreiden ter ondersteuning van besluitvorming, coördinatie en controle binnen een organisatie.] die via internet worden ontsloten dan wel aangeboden. Voordat een dienst, zoals internetbankieren, daadwerkelijk in gebruik kan worden genomen gaat hier een uitgebreid systeemontwikkelingstraject aan vooraf, grofweg: het ontwerpen, ontwikkelen en testen van het informatiesysteem.

Voor het ontwikkelen en testen van informatiesystemen zijn testgegevens nodig. In de praktijk worden hiervoor, om praktische redenen, vaak bestaande (tot natuurlijke personen herleidbare) gegevens gebruikt. Er wordt, ten behoeve van één of meer testomgevingen, simpelweg een kopie van een ‘productiedatabase’ met bestaande gegevens beschikbaar gesteld. Het kopiëren van een bestaande databaseomgeving is relatief eenvoudig te realiseren en te onderhouden. Daarnaast bevat een kopie van een productiedatabase alle relevante gegevens en is zij derhalve representatief voor alle bestaande situaties. Deze methode kent echter twee belangrijke nadelen:

  • Het gebruik van een veelheid aan kopieomgevingen kan leiden tot aanzienlijke kosten voor opslag, beheer, lange testdoorlooptijden, testinzet, et cetera.
  • De Wbp verbiedt weliswaar het testen met bestaande persoonsgegevens niet expliciteit, maar het College bescherming persoonsgegevens (Cbp) is helder voor wat betreft het testen met persoonsgegevens. In het document ‘Achtergrondstudies en verkenningen Nr. 23’ stelt het dat voor het testen van informatiesystemen met bijzondere persoonsgegevens uitsluitend gegevens van fictieve personen mogen worden gebruikt.

De problematiek van de kosten voor opslag is op te lossen door een subset uit de productiedatabase in plaats van de gehele database beschikbaar te stellen. Het maken van een consistente en representatieve subset is voor organisaties vaak lastig te realiseren, maar hiervoor zijn (technische) oplossingen beschikbaar. Dit artikel gaat verder in op de problematiek van het testen van informatiesystemen met persoonsgegevens.

Allereerst wordt ingegaan op de eisen die vanuit de Wbp worden gesteld aan het testen met persoonsgegevens. Vervolgens wordt toegelicht op welke wijze een consistente en representatieve set fictieve persoonsgegevens kan worden gegenereerd door gebruik te maken van anonimisering. Het artikel wordt afgesloten met een conclusie.

C-2009-3-Kikkers-01

Figuur 1. Bescherming persoonsgegevens is een actueel thema.

Wbp en testen met persoonsgegevens

Wet bescherming persoonsgegevens

Sinds 1 september 2001 is de Wet bescherming persoonsgegevens (Wbp) van kracht. De Wbp verving de Wet persoonsregistraties (Wpr) en is gebaseerd op de privacyrichtlijn van de EU. De wet verschilt, onder invloed van de Europese richtlijn, op belangrijke punten van de Wpr. Het grootste verschil met de Wpr is wel, dat het bereik van de Wbp aanzienlijk is verruimd. Zo is het criterium van toepasselijkheid van privacyregelgeving niet meer de aanleg of het houden van een persoonsregistratie als zodanig, maar elke (afzonderlijke) verwerking van persoonsgegevens van één of meer geregistreerden. De termen van de Wbp, met name de begrippen persoonsgegevens en gegevensverwerking, zijn ruimer gedefinieerd. Een persoonsgegeven heeft betrekking op alle informatie over een geïdentificeerde of (direct of indirect) identificeerbare natuurlijke persoon. Elke theoretische mogelijkheid om een gegeven te herleiden tot een persoon geeft dit gegeven een karakter van een persoonsgegeven.

Natuurlijke personen waarvan gegevens worden verwerkt zijn bijvoorbeeld identificeerbaar als hun NAW-gegevens bekend zijn. In beginsel zijn alle gegevens die over identificeerbare personen worden verwerkt persoonsgegevens, denk aan:

  • naam, adres, postcode, woonplaats, telefoon- en faxnummers, e-mailadressen;
  • leeftijd, opleiding, werkervaring, gezondheid;
  • strafrechtelijke antecedenten;
  • schulden, vorderingen, kenmerken/kentekens van eigendommen en videobeelden.

Onder verwerking verstaat de Wbp: elke operatie of geheel van operaties die al dan niet worden uitgevoerd met behulp van geautomatiseerde procedures die worden toegepast op persoonsgegevens, zoals verzameling, vastlegging, bewaring, ordening, aanpassing, raadplegen, gebruik, verspreiding of elke andere vorm van gebruik of beschikbaarstelling van persoonsgegevens. Let wel, de Wbp is dus van toepassing op alle geautomatiseerde verwerkingen van persoonsgegevens, alsmede op alle niet-geautomatiseerde verwerkingen waarbij de persoonsgegevens zijn opgenomen in een gestructureerd geheel, zoals kaartenbakken.

Volgens de Wbp mogen persoonsgegevens alleen voor welbepaalde uitdrukkelijk omschreven en gerechtvaardigde doeleinden worden verkregen. De ‘voor de gegevensverwerking verantwoordelijke’ moet een duidelijk doel omschrijven waarvoor de gegevensverwerking nodig is.

De Wbp bepaalt in het algemeen dat persoonsgegevens in overeenstemming met de wet en op behoorlijke en zorgvuldige wijze moeten worden verwerkt. Gedoeld wordt op het principe van doelbinding, waarborging van rechten van geregistreerden en rechtmatigheid van de gegevensverwerking (c.q. de gronden waarop gegevens mogen worden verwerkt). Vervolgens wordt een aantal gronden opgesomd op basis waarvan persoonsgegevens mogen worden verwerkt, namelijk slechts indien:

  1. de betrokkene (van wie gegevens worden verwerkt) daarvoor ondubbelzinnige toestemming heeft verleend, of
  2. de verwerking noodzakelijk is voor de uitvoering van de overeenkomst waarbij de betrokkene partij is, of
  3. verwerking noodzakelijk is om een wettelijke plicht waaraan de verantwoordelijke is onderworpen na te komen, of
  4. de gegevensverwerking noodzakelijk is ter bestrijding van ernstig gevaar voor de gezondheid van de betrokkene, of
  5. de gegevensverwerking noodzakelijk is voor de vervulling van een publieke taak door een bestuursorgaan, of
  6. de verwerking noodzakelijk is voor de behartiging van het gerechtvaardigde belang van de voor de gegevensverwerking verantwoordelijke of van een derde aan wie de gegevens worden verstrekt, tenzij het belang van de betrokkene (het recht op privacy) prevaleert.

Ook de Wbp kent naast de bovenstaande regels voor het gebruik van gegevens, verplichtingen voor de verantwoordelijke, bijvoorbeeld een meldingsplicht. Geautomatiseerde gegevensverwerkingen dienen doorgaans te worden gemeld bij het Cbp. Belangrijk is, in het licht van dit artikel, dat de Wbp de ‘verantwoordelijke’ een beveiligingsplicht oplegt. De verantwoordelijke moet passende technische en organisatorische maatregelen nemen om de persoonsgegevens te beschermen tegen een onwettige verwerking.

Testen met persoonsgegevens

De Wbp bepaalt dat persoonsgegevens niet mogen worden gebruikt voor andere doeleinden dan waarvoor deze gegevens zijn verstrekt. De wet verbiedt het testen met persoonsgegevens van informatiesystemen niet expliciet. Aan de andere kant: het testen van informatiesystemen met persoonsgegevens is over het algemeen geen doel waarvoor persoonsgegevens worden verwerkt. Het is niet altijd te voorkomen dat persoonsgegevens voor andere doeleinden worden gebruikt zoals het testen van de juiste werking van een informatiesysteem met tot natuurlijke personen herleidbare gegevens.

Het Cbp is echter helder voor wat betreft het testen met persoonsgegevens. In het document ‘Achtergrondstudies en Verkenningen Nr. 23’ stelt het college dat voor het testen van informatiesystemen met bijzondere persoonsgegevens[Het gaat om persoonsgegevens in risicoklasse II en hoger.] uitsluitend gegevens van fictieve personen mogen worden gebruikt. Wanneer afgeweken wordt van het gebruik van fictieve persoonsgegevens, dient invulling te worden gegeven aan de algemene eisen, zoals aldaar beschreven in hoofdstuk 2, en bovendien aan de aanvullende richtlijnen, zoals beschreven in het document. Het is van het grootste belang dat ervoor gezorgd wordt dat het testen geen nadelige invloed kan hebben op de beschikbaarheid, integriteit en vertrouwelijkheid van productiesystemen en/of productiegegevens.

Kader 1. Eisen aan testen met persoonsgegevens.

Samengevat zijn de belangrijkste eisen voor het testen van informatiesystemen met persoonsgegevens:

  • In beginsel mogen bijzondere persoonsgegevens niet voor testdoeleinden worden gebruikt.
  • Wijzigingen in het systeem moeten voordat deze wijzigingen in productie worden genomen, worden getest.
  • Indien mogelijk wordt bij het testen gebruikgemaakt van geanonimiseerde (fictieve) gegevens.
  • In beginsel mag niet worden getest in de productieomgeving.
  • De toegang tot testgegevens moet worden beperkt.
  • Voor het verlenen van toegang gelden dezelfde autorisatieprocedures als in de productieomgeving.
  • Toegang tot testgegevens dient te kunnen worden herleid tot natuurlijke personen.
  • De gegevens van de test- en productieomgeving zijn (logisch) van elkaar gescheiden.
  • In het geval testactiviteiten zijn uitbesteed aan een derde partij dienen contractuele afspraken over het gebruik van productiegegevens voor testdoeleinden te worden gemaakt (onder meer over verantwoordelijkheid en geheimhouding).

Het gebruik van productiegegevens voor testdoeleinden brengt een aantal risico’s met zich mee. Een belangrijk risico is dat door het gebruik van productiegegevens in testomgevingen onbevoegde personen toegang hebben tot gegevens die zij uit hoofde van hun functie niet nodig hebben. Denk aan salarisgegevens of gegevens over ziekteverzuim. Een andere belangrijk risico is bijvoorbeeld dat de testgegevens, in het geval de ontwikkeling van een informatiesysteem is uitbesteed, op straat komen te liggen. Onzorgvuldig gebruik of misbruik van deze gegevens kan zowel de organisatie als de betreffende persoon schaden. Daarnaast stelt het Cbp zoals gezegd dat voor het testen van informatiesystemen met bepaalde persoonsgegevens uitsluitend gegevens van fictieve personen mogen worden gebruikt. Als een organisatie deze regel overtreedt kan het Cbp een boete als sanctie opleggen.

Desondanks gebruiken veel organisaties veelal bestaande (tot natuurlijke personen herleidbare) gegevens voor testdoeleinden. De reden hiervoor is vaak een economische: er doen zich situaties voor waarin er simpelweg geen tijd is, of de kosten niet opwegen tegen de baten om fictieve gegevens te gebruiken. Door het anonimiseren van persoonsgegevens kan dit probleem worden opgelost.

Anonimiseren en filteren van persoonsgegevens

Anonimiseren van persoonsgegevens

Het anonimiseren van persoonsgegevens houdt in dat (persoons)gegevens zodanig worden gemanipuleerd, dat deze niet meer te herleiden zijn tot de oorspronkelijke (natuurlijke) persoon. We geven hier enkele voorbeelden van.

Verwisselen van gegevens

Bestaande gegevens worden verwisseld, zodat een oorspronkelijk identificerend gegeven niet meer herleidbaar is naar dezelfde natuurlijke persoon. Een nadeel van deze methode kan zijn dat de verwisselde gegevens herkenbaar zijn als bestaande gegevens.

C-2009-3-Kikkers-Vb1

Voorbeeld – verwisselen van naamsgegevens

Maskeren van gegevens

Bestaande gegevens worden (deels) onleesbaar gemaakt. Dit kan bijvoorbeeld door karakters te vervangen door een standaardwaarde (bijvoorbeeld een ‘x’). Een groot voordeel van deze methode is dat – bij voldoende maskering – de gegevens niet te herleiden zijn tot de oorspronkelijke persoon. Een mogelijk nadeel van deze methode is dat software hiermee niet overweg kan. Denk hierbij aan banknummers, waarbij maskering zal leiden tot invalide bankrekeningnummers (een dergelijk nummer moet onder meer voldoen aan de zogenaamde 11-proef).

C-2009-3-Kikkers-Vb2

Voorbeeld – maskeren van e-mailadressen

Retoucheren van gegevens

Bestaande gegevens worden enigszins aangepast. Een numerieke waarde wordt bijvoorbeeld aangepast door deze maximaal tien procent te laten afwijken van de oorspronkelijke waarde. Een belangrijk voordeel is dat trends in de gegevens nagenoeg identiek blijven, maar de individuele gevallen niet exact gelijk zijn aan het oorspronkelijke gegeven.

C-2009-3-Kikkers-Vb3

Voorbeeld – retoucheren van maandsalaris

In situaties waarbij berekeningen plaatsvinden op basis van een datum, is het in dit geval goed denkbaar om een willekeurige datum te genereren, die valt binnen dezelfde maand. Dit zou toegepast kunnen worden bij berekeningen die afhankelijk zijn van de geboortedatum van een persoon. Een nadeel van deze methode kan zijn dat de gegevens in grote mate gelijkenis vertonen met de oorspronkelijke gegevens.

C-2009-3-Kikkers-Vb4

Voorbeeld – retoucheren van datum

Genereren van gegevens

Gegevens kunnen op basis van regels gegenereerd worden. Zo kan bijvoorbeeld een bankrekeningnummer worden gegenereerd dat voldoet aan de 11-proef.

C-2009-3-Kikkers-Vb5

Voorbeeld – genereren van banknummers

Verwisselen van sleutelvelden

Een bijzondere manier van anonimiseren is het verwisselen van (onderdelen van) sleutelvelden. In bepaalde situaties komt het voor dat in databases een betekenisvolle en identificerende sleutel (bijvoorbeeld burgerservicenummer) wordt gebruikt als verwijzende sleutel naar een andere tabel. Indien deze sleutel wordt geanonimiseerd, bijvoorbeeld door die te verwisselen met andere waarden in dezelfde kolom, worden hiermee ook de koppelingen tussen gegevens uit verschillende tabellen gewijzigd. Indien deze koppeling in stand gehouden moet worden, dient hetzelfde gegeven in de tabel waarnaar verwezen wordt volgens dezelfde regels verwisseld te worden. Voordeel van deze methode is dat betekenisvolle sleutels verwisseld kunnen worden en de database consistent blijft.

C-2009-3-Kikkers-Vb6

Voorbeeld – verwisselen van sleutelgegevens (BSN) over twee tabellen

Filteren van persoonsgegevens

Stel dat alle salarisinformatie van eigen personeelsleden is overgenomen van de productieomgeving naar de testomgeving en dat de persoonsgegevens zijn versleuteld. Dan zou nog steeds achterhaald kunnen worden hoeveel de directie verdient. Of stel dat bepaalde situaties een beperkt aantal malen voorkomen, dan nog zou na anonimisering achterhaald kunnen worden welke personen dit betreft. In beide voorbeelden is het dan mogelijk om de (geanonimiseerde) persoon alsnog te identificeren. Daarom is het in dergelijke gevallen gewenst de eenvoudig herleidbare gegevens uit de testset te filteren.

Technische en organisatorische inrichting

In deze paragraaf wordt een drietal mogelijke inrichtingen beschreven om een representatieve testset met fictieve persoonsgegevens te genereren. Voor alle inrichtingen wordt gebruikgemaakt van zowel subsetgeneratie als anonimisering.

De eerste variant betreft een enkelvoudige inrichting. Hierbij wordt slechts één productiesysteem gebruikt als basis om een consistente subset aan gegevens te extraheren en te anonimiseren richting een testomgeving. De tweede variant betreft een keteninrichting, waarbij consistente subsets en anonimisering plaatsvinden ‘over de keten heen’. De derde variant is een uitbreiding op variant 2, waarbij de keten-testomgeving als bron voor specifieke afgeleide testomgevingen dient.

Variant 1. Enkelvoudige inrichting

In de enkelvoudige inrichting wordt op basis van een productieomgeving een representatieve en consistente subset aan gegevens geëxtraheerd (zie figuur 2). Deze subset wordt geanonimiseerd en kan worden ingezet als testomgeving. Deze testomgeving is vanwege de subsetgeneratie van beperkte omvang en kan door het toepassen van anonimiseringsregels worden gebruikt als basis voor de uitvoering van diverse tests.

C-2009-3-Kikkers-02

Figuur 2. Enkelvoudige inrichting.

Aangezien de testers slechts kunnen beschikken over de testomgeving, zijn de productiegegevens (en dus de persoonsgegevens) afgeschermd.

Variant 2. Keteninrichting

Indien er zich meerdere systemen in het productielandschap bevinden, kan het wenselijk zijn om een testomgeving in te richten die de ketentest kan ondersteunen. In deze variant worden representatieve en consistente subsets ‘over de keten heen’ geselecteerd (zie figuur 3). Indien bepaalde gevallen worden geselecteerd uit het CRM-systeem en overgezet naar de CRM-testomgeving, dan worden eveneens de gerelateerde gegevens van die klanten uit het ERP- en HRM-systeem geselecteerd en overgezet naar de bijbehorende testomgevingen. Ondanks dat er een selectie aan gegevens uit de bronsystemen is gehaald, is deze subset toch consistent over de systemen heen.

C-2009-3-Kikkers-03

Figuur 3. Keteninrichting.

Daarnaast kan in deze variant anonimisering plaatsvinden ‘over de keten heen’. Indien een anonimiseringsregel wordt toegepast om een bepaald gegeven uit het CRM-systeem te manipuleren en over te zetten naar de CRM-testomgeving, dan zal hetzelfde gegeven uit het ERP- en HRM-systeem op basis van exact dezelfde manipulatie worden geanonimiseerd. Hierdoor zijn de gegevens in de testomgevingen geanonimiseerd, maar toch consistent over de systemen heen. Ook in deze variant geldt dat de testers slechts kunnen beschikken over de keten-testomgeving, waarbij de productiegegevens (en dus de persoonsgegevens) zijn afgeschermd.

Variant 3. Keteninrichting met informatiebeveiliging

Deze variant is een uitbreiding op variant 2. De ingerichte keten-testomgeving kan als basis dienen voor het flexibel kunnen extraheren van specifieke testsets. Aangezien de keten-testomgeving is geanonimiseerd, kunnen testers zelf hun eigen specifieke testsets samenstellen, zonder toegang te hebben tot en inzicht te hebben in productiegegevens.

In figuur 4 is een virtuele informatiefirewall getekend. Hierbij is het mogelijk om tijdens het samenstellen van de keten-testsets een pseudo-identificatie uit te reiken. Aan de ‘linkerkant’ van de muur is de oorspronkelijke identificatie wel bekend, terwijl deze aan de ‘rechterkant’ niet bekend is.

C-2009-3-Kikkers-04

Figuur 4. Keteninrichting met informatiebeveiliging.

Kader 2. Case landelijke verzekeraar.

Praktijkvoorbeeld

Een landelijke verzekeraar maakt gebruik van een in eigen beheer ontwikkeld geïntegreerd polis- en schadesysteem. In de polis- en schadeadministratie zijn gegevens vastgelegd over verzekerden. Het betreft niet alleen NAW-gegevens maar ook bijzondere persoonsgegevens. Het systeem ondergaat met grote regelmaat grote (releases) en kleine wijzigingen (updates/emergency fixes). Voor het testen van de juiste werking van het polis- en schadesysteem maakt de zorgverzekeraar zowel bij het testen van een nieuwe release als bij het testen van updates gebruik van productiegegevens waaronder bijzondere persoonsgegevens. Er zijn twee belangrijke redenen waarom gebruik wordt gemaakt van productiegegevens voor testdoeleinden. Ten eerste heeft de ontwikkelafdeling aangegeven dat een representatieve set testgegevens met fictieve persoonsgegevens niet eenvoudig is te realiseren maar vooral ook erg kostbaar is. De tweede reden heeft met tijd en snelheid te maken. In het geval van updates/emergency fixes ontbreekt de tijd om een representatieve testset te genereren. De zorgverzekeraar heeft wel een richtlijn geïmplementeerd om de risico’s die samenhangen met het gebruik van productiegegevens voor testdoeleinden te beheersen. De belangrijkste uitgangspunten zijn:

  • Productiegegevens die persoonsgegevens van risicoklasse II of hoger bevatten zoals beschreven in het document ‘Achtergrondstudies en Verkenningen Nr. 23’ van het College bescherming persoonsgegevens mogen onder voorwaarden worden gebruikt voor testdoeleinden.
  • Productiegegevens mogen worden gebruikt voor testdoeleinden na expliciete toestemming van de systeemeigenaar. De security officer heeft hierbij een adviserende en toetsende rol. Bij het gebruik van testgegevens zijn de minimale eisen zoals beschreven in kader 1 onverkort van toepassing.
  • Productiegegevens die voor testdoeleinden zijn gebruikt worden na afloop van de testactiviteiten vernietigd.

In de praktijk blijkt de implementatie en naleving van de richtlijn kostbaar. Ook ontstaan problemen met het beheer van de productie- en testgegevens. Dit betreft aan de ene kant de beheerkosten en aan de andere kant de integriteit van de productiegegevens in de testomgeving. In samenwerking met een gespecialiseerde dienstverlener is de verzekeraar daarom productiegegevens gaan anonimiseren en filteren. Deze dienstverlener beschikt over software waarmee eenvoudig en geautomatiseerd representatieve testsets kunnen worden aangemaakt. Via de software kunnen de testgegevens automatisch worden geanonimiseerd. Het samenstellen, onderhouden en gebruiken van testsets is op deze wijze voor de verzekeraar veel eenvoudiger, betrouwbaarder, goedkoper en veiliger geworden.

Conclusie

Door de digitalisering en strikte wetgeving op het gebied van persoonsgegevens wordt het steeds moeilijker om informatiesystemen goed te testen. De vraag naar representatieve en consistente testgegevens is groot. Hiervoor productiegegevens gebruiken lijkt aantrekkelijk, maar kent een aantal knelpunten.

Het gebruik van bestaande persoonsgegevens voor het ontwikkelen en testen van informatiesystemen is niet expliciet bij wet verboden, maar is sterk af te raden. De risico’s van imagoschade bij verlies of oneigenlijk gebruik zijn erg groot. Daarnaast brengt een kopie van productiegegevens hoge kosten met zich mee. Adequate maatregelen kunnen gezocht worden in enerzijds het extraheren van een representatieve subset van productiegegevens en anderzijds het anonimiseren van privacygevoelige informatie.

Deze maatregelen bieden grote kostenbesparingen op gebied van testhardware en doorlooptijden van tests. Tevens bieden zij een goede bescherming tegen oneigenlijk gebruik van productiegegevens, waarmee wordt voldaan aan de wet- en regelgeving op het gebied van bescherming persoonsgegevens.

Het is aan te bevelen om alle risico’s te inventariseren rondom het gebruik van gegevens. Welke gegevens worden op welke plek in de organisatie vastgelegd en gebruikt en met welk doel? Stel vervolgens organisatorische en technische maatregelen vast om het oneigenlijk gebruik van productiegegevens tegen te gaan. Hierbij kan gedacht worden aan een striktere functiescheiding, het aanstellen van een functionaris voor gegevensbescherming, technische beperkingen en het beschikbaar stellen van geanonimiseerde productiegegevens voor het ontwikkelen en testen van software. Voor het anonimiseren van persoonsgegevens moet worden bepaald op welke wijze geanonimiseerd moet worden.

Door deze maatregelen kan er efficiënter worden getest, kunnen kosten worden bespaard en blijft de privacy van persoonsgegevens gewaarborgd.

Literatuur

Wet bescherming persoonsgegevens, 2001.

G.W. van Blarkom en J.J. Borking, Beveiliging van persoonsgegevens, Achtergrondstudies en Verkenningen Nr. 23, 2001.

Information and Privacy Commissioner, 2001, Privacy-enhancing technologies: The path to anonymity, Achtergrondstudies en Verkenningen Nr. 11, 2001.

Witboek Privacy Enhancing Technologies voor beslissers, ministerie van BZK en KPMG, 2004.

Geraadpleegde bronnen

Website College bescherming persoonsgegevens, www.cpbweb.nl

Transformational Records Management: Minimizing Risk and Liability

Many organizations today are coming to terms with the fact that the huge growth in information has created risk exposure in terms of the accessibility and integrity of data. That exposure is increasingly realized through litigation where data records are considered “discoverable” by courts. This article sets out some of the risks and challenges facing organizations today in the realm of Records Management.

Introduction

As the nature of business information becomes more complex and compliance issues multiply, every organization, large or small, regardless of its line of business, must analyze how it controls information within the enterprise, across the globe, and between product/service offerings. Sometimes corporate compliance departments and legal departments find themselves in contention with their IT departments as the former demand processes that can deliver the right information at the right time to the right person. When that repeatedly fails to happen, organizations begin re-assessing their records management programs.

Most organizations today have, in practice, a records management program based upon physical paper. They may also have an archiving strategy for electronic information. Frequently, the first is performed by a Records Management or Legal Compliance Department; the second is managed by an IT Department. The Records Management/Compliance Department concentrates on producing documents for regulatory, tax, and litigation reasons; the IT Department wants to save costs on storage and improve network performance. Getting these two groups to align their strategies is the first step toward a comprehensive global records management program that ensures safe harbor from risk and provides verifiable, defensible practices.

The development of a Global Records Management program and policy is an opportunity to set out the vision and role of enterprise-wide Records Management within an organization, as well as to create a framework for the ancillary policies. Ancillary policies need to be established to treat specific types of data content, but they must still adhere to the guiding principles of the overall policy. Ancillary policies create requirements that meet the different needs of physical records, inactive records, vital records, e-mail, records shared across multiple regions, and electronic records for long-term archival storage. The result is an organization that mitigates risk, meets compliance demands, and realizes tangible business benefits.

Records Management Risks

Records are information created, received or used as part of a firm’s transactions, processes or business activities and legal obligations (ISO15489). Records contain information created, received, and maintained as evidence by an organization or person, in pursuance of legal obligations or in the transaction of business. They include documentation pertaining to a transaction or business event that may have legal ramifications or historical value. Guided by regulations, each organization must determine the definition of what a record is and, often more importantly, what it is not.

Good records management can:

  • Aid more effective disclosure and help laywers make faster decisions as to the extent of a reasonable search for documents in accordance with disclosure rules. Being able to identify relevant or privileged material quickly will also save significant costs in the event of litigation.
  • Provide evidence of compliance in keeping with legal requirements as regulators pay more attention to data retention.
  • Reduce time and expense incurred through document production activities associated with litigation, and increase speed and efficiency in meeting regulatory requests for documentation.

The complexity of records management has increased exponentially in recent years. Massive information production along with the complexity of processing this amount of data frequently has every level of management perplexed when the full gambit of risks are considered. For instance, a subset of this massive information contains personal information about individuals, and therefore requires increased control and recognition of how the use of data protection rights such as Subject Access Requests, interact with non-privacy related litigation, such as discrimination.cases.

Organizations are capturing information using an increasing variety of methods, including scanners, notebooks, printers, removable devices and storage area networks. The records containing this information are subject to multiple regulatory requirements, including for instance MiFID, national implementations of Directives 95/46/EC & 02/58/EC, provincial and national employment law, Federal Rules of Civil Procedure (FRCP), American Bar Association (ABA) Civil Discovery Standards, Gramm-Leach-Bliley, Health Insurance Portability and Accountability Act (HIPPA), Securities and Exchange Commission (SEC) Rule 17a-4 and National Association of Securities Dealers (NASD) Rule 3010. Failure to produce records and information to meet these regulations can be costly and damaging to an organization’s reputation.

More recently, improvement programs for records management have been driven by Litigation Readiness concerns over e-discovery costs. Those costs have steadily risen as businesses deal with numerous and constant disclosure requests. The task of sifting through vast archives of e-mail and electronic data has become increasingly complex and taxing. Litigation Readiness programs hold the promise of reducing these costs. Their aim is to give companies the knowledge of precisely where and how their records are stored and over what period of time, plus the comfort of knowing they are stored in accordance with the discovery obligations of each jurisdiction in which they operate.

C-2009-3-Kenny-01

Figure 1. The Bounded Control of Key Business Functions.

Nothing is growing as fast as the production of information. Much of this information is linked to individuals, and some of this personal data is sensitive. At the same time, the complexity associated with processing data is also growing. These three factors are the primary constituents of privacy risk (shown here), and hence the privacy risk function is exponential. Because records management encapsulates and extends beyond personal data, a similar escalation in risk applies to records management. No single business function is equipped to manage this risk in its entirety. There can be little doubt that severe exposure is likely for those with the greatest value at stake. This is certainly the case where the legal aspects of regulation are dealt with in isolation, without also ensuring alignment with IT, assurance through audit and full integration with prevailing operational risk frameworks.

To help organizations realize potential benefits that could be gained from proactive programs, KPMG has designed a process called Transformational Records Management (TRM), a process that aligns records management practices with legal and business objectives. TRM can deal with widely deployed responsibilities and help gain acceptance across multiple functional lines. TRM moves processes towards broadly stated business and regulatory objectives. Technology is leveraged to address both the past (where the vast majority of exposure resides) and the future, to support long-term value preservation.

TRM aims to help organizations realize the benefits of good records management by adopting strategies across the following areas:

  • Reputational risk management arising from inefficient records management processes.
  • Litigation and regulatory readiness.
  • Compliance transparency.
  • Effective data retention.
  • Controled storage costs.

Through the orchestration of these five elements TRM provides organizations with the ability to achieve business benefit from the effective and efficient management of records.

Improved management of reputational risk

Losing face can trigger a crisis of confidence in shareholders, customers, business partners and regulators, constraining a company’s ability to do business. Many adverse court decisions have been publicized where findings were made against companies unable to produce admissible records. But the issue is broader. Poor records management is the cause of many failures to deal effectively with customer queries and complaints. It is directly correlated to falling customer retention rates and affects customer acquisition.

Fragmented approaches tend to fail. Success depends on establishing a consistent view of information lifecycles across the organization focusing on retention, disposition and discovery. Consistency can be achieved by adopting a model centered on business activities, with similar rules applied to the records for each activity. Taking an integrated view of the approaches across several business functions can help to ensure that a consistent approach is taken to defining the categorization scheme for retention and disposition. Business users will have made decisions in the past around retention, as part of business continuity planning, and these can serve as precedents for the design and implementation of functional taxonomies that will enable category and custodial identification standards to be applied.

Litigation and Regulatory Readiness

It is a growing and significant challenge for institutions to manage the growth of data held within their systems in order to identify, preserve and manage information effectively for future use. Corporate and public bodies are increasingly subject to information requests by regulators, government institutions and the general public, whilst there is a continuing obligation to disclose electronically stored information (ESI) in legal proceedings. Having simple and immediate access to relevant information in advance of competition enquiries, regulatory investigations, Freedom-of-Information requests or litigation can save organizations time, money and inconvenience should such scenarios materialize.

Poor records management can lead to poor preparedness for the challenges of e-discovery in the US and e-disclosure in the UK. There have been various examples of records management failures that have led to heavy fines as part of legal proceedings. These include Nationwide being fined £980k by Financial Services Authority for information breaches (information security lapses), the SEC fining 5 broker-dealers $8.25M for violation of record-keeping requirements regarding e-mail and Morgan Stanley being ordered to pay $1.45 billion in a civil lawsuit, due in large part to failure to properly produce electronic documents.

The courts in the UK have started to take a greater interest in e-disclosure: for example, in the recent case of Digicel the defendants were found not to have properly searched back-up tapes. As such it is clear that proper records management can aid more effective e-disclosure and help lawyers make faster decisions on the extent of a reasonable search for documents in accordance with disclosure rules. Being able to identify relevant or privileged material quickly will also save significant costs in the event of litigation.

Some questions to consider:

  • Are you ready to handle an information request, enquiry or raid?
  • Do you have a comprehensive and consistently applied information retention strategy?
  • Do you know where your business critical information is stored?
  • Can you access and extract it quickly?
  • Are your information systems effectively organized to ensure disclosure?
  • Can you measure the cost of collecting, processing and producing ESI?
  • Do you have a documented, defined, defendable and repeatable process for processing litigation and regulatory requests?

In litigation, internal counsel needs to understand precisely which records opposing counsel will receive in response to a discovery request. Predictability in these cases directly affects litigation success. For records to be admissible and defendable in court there must be evidence of their authenticity and chains of custody. Legal certainty here is entirely dependent upon the ability of the IT organization to align its records control framework to a prescribed set of legal and regulatory requirements. Legal certainty represents significant value at risk for many corporations that absorb sizeable litigation exposure each year.

The alignment of IT and legal functions needs to be conceptualized, planned, executed, measured, monitored and assured. Aligning them is not a simple task and can require significant rethinking, but it is vital that both parties understand the rationale for the linkage between them and the roles they play. For example, the Legal Department’s understanding of the types of data, subject to legal holds and destruction must be connected with IT’s understanding of the affected underlying data. Legal will determine the records stored and deleted, but IT will need to provide evidence that retention rules have been implemented. Such evidence creates legal certainty. Legal needs to be aware of current data organization, location and accessibility, and IT should be capable of establishing a chain of custody with provable authenticity. Allegations of delinquent response can be avoided by establishing, and consistently executing, precise communication protocols between Legal and IT.

Getting this alignment right requires methodology and process. Methodology is often overlooked, but is necessary in precisely translating legal requirements into traceable operational requirements, which can be broad and deep. Process can be substantiated through a formalized Responsible, Accountable, Consulted and Informed (RACI) framework, which articulates actions and allocates roles. As an example, policy approval is a role connecting Legal and IT, with Legal formally endorsing regulatory taxonomies. This provides legal certainty and assurance for the IT function so that retention and disposition rules can be applied to all storage devices.

Compliance transparency

In general, it is becoming more important for an organization to be able to quickly provide evidence of their compliance with regulations. Expectations are rising and there is a cultural shift in many organizations away from control frameworks dedicated to how a company dealt with exposure, toward more organic frameworks which seek to measure how risk events are controlled and how problems can be averted before exposure is realized.

The vast majority of records exposure a company faces resides in the past. The first step towards achieving compliance transparency is to make a conceptual split between the past and the future.

A technology roadmap is a logical starting point for considering past exposure. Roadmaps serve to baseline existing records technology capabilities against prevailing regulatory, business and technical requirements. Roadmaps include governance, alternative solution architectures (such as a records shared-service paradigm), implementation strategies and appropriate standards to reduce the cost and complexity of the current environment. All roadmap requirements should be derived from expected benefits, such as improved discoverability. In the case of regulatory requirements, effort is well spent in establishing traceability from legal rules to functional requirements that will withstand the scrutiny of substantive audit testing as a proxy for court scrutiny.

Selecting a robust records management application (RMA) is critical. RMA’s should be capable of locating data outside the network topological map, as are SharePoint servers and online collaboration tools such as Google Docs. They should be able to sift through unstructured content with text analysis and apply ontological classification enabling the information to be coherently indexed and classified. RMA’s should be capable of categorization. This enables retention and disposition rules to be applied and enforced. It also supports legal holds by searching for relevant data then moving that data to a “legal hold categorized” repository.

In terms of the future, the vehicle of IT Governance is of particular use. Control Objectives for IT (COBIT) processes related to system development, technical change management and the service level management are worthy of focus as recipients of records management requirements. Development and implementation of records risk controls in these three areas invariably creates leading indicators of control, rather than traditional lagging indicators of exposure event trends. This directly supports the realization of compliance transparency.

Data retention

Data retention is becoming a real focus for Privacy Commissioners in Europe. This is due to rapid technological development in the areas of data mining supported by personal data fueled business models, and an increasing awareness of the impact this has on privacy rights. What many organizations are also beginning to realize is that data retention can have a substantial impact on the level of trust that exists between businesses and their customers.

One systematic weakness in information lifecycle management, impacting upon data retention, is that in many cases the “time factor” of user access is still not given sufficient attention by organizations. The “time factor” means that there are different people with varying business needs who access information throughout the information lifecycle.

Increasing volumes of new and unique information are being generated by organizations every year. This data, in all its media forms, held within corporate groups and their business partners, needs to be retained for a finite period of time. Not surprisingly, this is presenting organizations with both practical and legal challenges.

There are two main reasons for retaining the data. Firstly, it can serve useful purposes in addition to the reason for which it was originally collected, typically including customer profiling and meeting new legislative requirements. Secondly, storing the data is often a more pragmatic solution than destroying it.

What we know from our member firms’ work in this area is that search tools have improved (in particular, search technologies for unstructured text/data – a high-growth area in the Business Intelligence market), making it far easier to efficiently access large amounts of data. Furthermore, systems rarely enable the user to delete selected fields; it is often all or nothing. This results in whole data sets being retained when only subsets can be stored compliantly.

In managing the information lifecycle, many organizations still repeatedly fail to pay sufficient attention to user access, which has an impact on retention. KPMG firms often see inadequate processes, and the time factor is typically not considered when determining levels of access. However, time is an important consideration, as many users do not need access throughout the entire information lifecycle. Many staff do not need to access stored data at all in order to fulfill their business roles. For example, front-end customer support staff can comply with applicable bookkeeping regulations without the need to call up stored data. Similarly, account staff do not have a business need to access information about customers stored in CRM systems.

Insufficient access controls and deletion routines frequently lead to fundamental privacy principles being contravened, as large volumes of personal information become accessible to people with little or no business need to use the information. In the days of paper storage, this was not a problem. Records were physically moved into archives. But with data stored electronically, inappropriate access to information is now a major concern.

C-2009-3-Kenny-02

Figure 2. Data Retention Staircase

The Data Retention Staircase is neither a solution nor a methodology, but illustrates the challenge of access controls and data retention., assisting an organization in mitigating the risks of potentially illegal storage.

The vertical axis of the Data Retention Staircase in Figure 2 depicts the volume of personal data. The horizontal axis depicts time. The employees in dark blue are those with an actual need to access the data. The employees in grey have access, but no business need. Importantly, this model illustrates that legitimate access to data is required by fewer people over time, so that in planning storage and access, regular re-assessments of both employee needs and storage requirements should be made.

Data retention can be managed effectively, without the need for systems overhaul, by following a six-step process:

  1. Create an overview of the personal information being processed in the company. In some cases, Operational Risk process definitions are well suited to establish information lifecycles.
  2. Map all relevant legal requirements (including business needs, if they contribute to the rationale) relating to data storage and any additional purposes identified in Step 1.
  3. Assess current retention levels and policies against requirements throughout the information lifecycle.
  4. Identify the staff with access to information and map them against the purpose for processing the data.
  5. Provide a view of all gaps:
    1. Information kept without a defined purpose
    2. Individuals with access but no established need.
  6. Close gaps:
    1. Delete excess information
    2. Embed and enforce appropriate access controls.

Controlling storage costs

Nothing is growing as fast as the production of information to the extent that associated storage costs have outstripped falling per-gigabyte storage costs, improvements to drive capacity and disk performance. The “save everything” approach does not make economic sense (and neither is it a recommended litigation management strategy), while storage reduction solutions such as de-publication can create problems with legal admissibility of records. A typical organization holds between 10 and 30 copies of each document. Many of these are no longer needed; some are misplaced or even unknown. Storage optimization and process efficiency have become important business objectives.

Process improvements and a well thought-out infrastructure strategy are key factors in controlling storage growth. Records requirement, in many cases, needs to be incorporated into business processes through automatic content analysis, identification and classification.

Infrastructure strategy encompasses many elements. Duplicate management, e-mail filtering and archiving, backup, data center approach, tape restoration and data classification all play a part. But infrastructure strategy also considers the presentation layer. Records functionality will need to become abstracted into common user interfaces, particularly e-mail, providing users with support for identification and categorization. Consequently, employees will become increasingly responsible for identifying and classifying records.

In computing, virtualization is a broad term that refers to the abstraction of computer resources typically at the platform, storage, resource or network layer. In virtualization, users do not necessarily know what resources they are using. In enterprise environments those resources usually are controlled by the company, but the resources can also be external, which means that it is difficult to know where that data will be stored, processed and transferred.

Virtualization of storage helps achieve location independence by abstracting the physical location of the data. The virtualization system presents the user with a logical space for data storage and handles the process of mapping data to its actual physical location. This means that the data can reside at several locations and in locations unknown to the user. In virtual storage the host only deals with the logical space. Any changes to the meta-data mapping are transparent to the host, meaning the data can be moved or replicated to another physical location without affecting the operation of any client.

In storage virtualization the physical storage resources are aggregated into storage pools, which can be added as and when needed, with the virtual storage space scaling up by the same amount. Many data retention policies state that data must not be stored beyond the end of its lifecycle. When the data is scattered in different physical disks in the storage pool, it is difficult to physically destroy the disk containing the record. Therefore these records need to be erased from the virtual storage using other means, such as specific software that is designed to reliably erase data from disks. On the more positive side, since multiple independent storage devices appear to be a single monolithic storage device they can be managed centrally, which can help in data lifecycle management. Although a virtual storage infrastructure benefits from a single point of logical disk and replication service management, the physical storage must still be managed. For example, faulty disks need to be identified, properly destroyed and replaced.

Meta-data is a key component in virtualization, since once the data has been virtualized, the meta-data is the only thing making it possible to access the information. If the meta-data is lost, so is all the actual data, since it is virtually impossible to reconstruct the logical drives without the mapping information. Hence it is important to be able to reconstruct the meta-data in the event of a failure. Meta data has also been admissible in US court proceedings.

Conclusion

As structured and unstructured records grow in both the volume and the risk they represent, it becomes more important for organizations to re-think the processes by which they manage records. Are they adequate today and will they suffice for tomorrow are questions well worth asking.

Case studies

Case Study 1 – Global Financial Services Company

For a global financial services company, KPMG created an inventory of all electronic record types, defined a compliance framework in accordance with the company policy and standard operating procedures, established the internal controls for record repositories and processes, and conducted risk and gap analysis by determining nonconformity with the company’s e-compliance framework. KPMG worked closely with senior management to develop a remediation strategy and a plan to correct the gaps.

Case Study 2 – Retail Correspondent Clearing Firm

KPMG performed a records retention process improvement program specifically for account records for a large retail and correspondent clearing firm. Current state policies, processes, and documentation were identified and desired state polices and processes developed with operations and technology management. The team prepared process-improvement observations with recommendations for change, and provided a roadmap for addressing open issues.

Case Study 3 – Manufacturing Company

KPMG managed the development of the regulatory and legal requirements for a corporate retention schedule for a manufacturing company. KPMG led a risk appetite workshop with key stakeholders to understand the organization’s “risk appetite” and designed a corporate-wide program to meet regulatory compliance demands.

Case Study 4 – Insurance Company

As part of an overall legal and compliance process review, KPMG assessed an insurance company’s policies, processes, and procedures for creating, maintaining, accessing, and destroying pertinent company records. Of particular concern were records relating to policy forms and producer licensing information, thus a comprehensive program was developed.

Case Study 5 – Utilities Company

For a large southeastern U.S. utilities client, KPMG was tasked with

  1. developing an enterprise information security program,
  2. developing a dynamic and sustainable compliance program,
  3. developing performance metrics to be utilized in assessing operational and business performance, and
  4. designing, implementing, and managing an enterprise information management and protection program.

Macht en belang bij ERP-implementaties

Macht en belang hebben impact op het slagen van een ERP-implementatie. Toch krijgen zachte factoren als macht en belang weinig aandacht bij ERP-implementaties. Maar als we er wel aandacht aan willen besteden, wat is dan macht, wat is dan belang? Hoe kunnen deze factoren gemeten worden? Dat komt in dit artikel aan bod. Daarnaast wordt de Quality Assurance-rol beschreven en wordt aangegeven in hoeverre deze rol aandacht moet en kan schenken aan de factoren macht en belang.

Inleiding

Ondanks alle ervaringen uit het verleden en de toenemende kwaliteit van systemen zijn er nog steeds veel ERP-implementaties die niet goed gaan c.q. niet opleveren wat ervan werd verwacht. Projectmanagementmethodieken zijn verfijnd en uitontwikkeld, net als implementatiemethodologieën. Toch blijkt dit geen garantie voor succesvolle implementaties. Welke factoren zijn er nog meer van belang bij implementaties? Eén factor kan de onderschatting van de wijzigingen in de machts- en belangenpositie in een organisatie zijn. De machts- en belangenpositie in een organisatie verandert als gevolg van de implementatie van een ERP-systeem. Partijen krijgen meer en andere informatie en worden voor het uitoefenen van hun functie meer of minder afhankelijk van anderen, ofwel de mate van interne beheersing zal veranderen. In dit artikel wordt ingegaan op de factoren macht en belang bij een ERP-implementatie. Vervolgens wordt de link gelegd in hoeverre de Quality Assurance-rol deze factoren kan meenemen in zijn werkzaamheden. Eerst worden de kaders geschetst rondom de factoren macht en belang.

Macht en belang: kaders

Enterprise Resource Planning is ontstaan vanuit de goederenstroombesturing. Voorheen was het zo dat bedrijven voor de ondersteuning van elk deel van de productieketen een apart geautomatiseerd systeem hadden, bijvoorbeeld aparte systemen voor inkoop, opslag, productie en verkoop. Dit leidde tot inconsistenties en inefficiënties (zoals het meerdere malen moeten invoeren van gegevens). Vervolgens ontstonden zogenoemde Manufacturing Resource Planning (MRP)-softwarepakketten, waarbij rekentechnieken werden gebruikt waarmee de goederenstroom integraal kon worden aangestuurd en informatie beschikbaar werd gesteld voor productiecapaciteitplanning. De behoefte tot het eenmalig invoeren van gegevens en de integratie van systemen leidde tenslotte tot het ontstaan van ERP-softwarepakketten, waarbij de administratieve ondersteuning werd gecombineerd met de aansturing van de goederenstroom.

De implementatie van een ERP-systeem raakt in de praktijk vaak vrijwel alle processen en heeft daarmee een grote impact op de organisatie. Meestal blijkt dat ook de organisatie aangepast moet worden, waardoor de implementatie niet alleen een technisch, maar ook een organisatieveranderkundig karakter heeft. Veel ERP-implementaties leveren niet het gewenste resultaat op, dan wel worden vroegtijdig afgebroken. Bekende voorbeelden uit de pers zijn de ERP-implementatie bij keukenproducent ATAG en de ERP-implementatie bij containeroverslagbedrijf Vopak.

Behalve dat een ERP-implementatie vrijwel alle processen raakt heeft zij ook invloed op de hiërarchische en functionele verhoudingen binnen een organisatie. Kennis wordt meer verspreid binnen een organisatie, afhankelijkheden van elkaar worden vergroot (of juist verkleind). Ofwel er vinden belangrijke wijzigingen plaats in de machts- en belangpositie van de stakeholders. Deze wijzigingen hebben grote invloed op het gebruik van het nieuwe ERP-systeem. Bij de implementatie van een nieuw ERP-systeem wordt vaak weinig rekening gehouden met de belangen van de diverse stakeholders. Een implementatie is met name gericht op processen en functionaliteiten, niet zozeer op de menselijke factor. Macht is zelfs zodanig van belang dat onderschatting hiervan kan leiden tot het falen van de ERP-implementatie. Wie kent niet de trajecten waarbij belanghebbenden weerstand bieden?

Machtsfactoren zijn in elke organisatie aanwezig, we spreken daarbij over organisationele macht. Ter toelichting van het begrip organisationele macht worden achtereenvolgens de verschillende vormen van macht behandeld. Op basis hiervan wordt een definitie van het begrip organisationele macht gepresenteerd.

Macht

Het begrip macht wordt in deze subparagraaf vanuit drie perspectieven belicht, namelijk vanuit strategisch, sociologisch en organisatiekundig perspectief. Doel van deze meervoudige benadering is het vinden van relevante kenmerken van macht, die gebruikt kunnen worden bij de operationalisatie van het begrip macht in een ERP-implementatie.

Strategisch perspectief

De Wit en Meijer ([Wit04]) onderscheiden een vijftal vormen van macht waarmee invloed kan worden uitgeoefend: legitieme macht, afdwingbare macht, waarderende macht, expertisemacht en referentiemacht. Legitieme macht is macht gebaseerd op formele autoriteit. Afdwingbare macht is aanwezig indien de mogelijkheid bestaat om te straffen. Waarderende macht bestaat indien tot prestaties aangezet kan worden door het geven van beloningen. Expertisemacht is aanwezig indien de medewerker in bezit is van specifieke kennis. Referentiemacht wordt ontleend aan de invloed van een belangrijke omstandigheid.

Sociologisch perspectief

Fincham ([Finc92]) beschrijft drie perspectieven van macht: processuele, institutionele en organisationele macht. Processuele macht vindt haar basis in machtsstrategieën, zoals coalitievorming, manipulatie van informatie en politieke verhoudingen. Deze vindt plaats door sociale interactie. Institutionele macht is gebaseerd op gemandateerde autoriteit vanuit een sociale structuur, zoals maatschappelijke klasse, geslacht, afkomst, beklede posities, en dergelijke. Een externe structuur is bepalend voor deze vorm van macht. Bij organisationele macht is de interne structuur bepalend. Organisationele macht vindt haar basis in hiërarchische mechanismen, bijvoorbeeld in aannamebeleid, carrièreverloop, een dominante coalitie of een andere dominante oorzaak.

Organisatiekundig perspectief

Daft ([Daft01]) maakt een onderscheid tussen individuele macht versus organisationele macht. De hiervoor besproken vijf vormen van macht uit [Wit04] zijn volgens Daft vormen van individuele macht en variaties op hoe een persoon invloed kan uitoefenen op of kan domineren over een andere persoon.

Definitie van macht

Macht is een immateriële kracht in een organisatie ([Daft01]). Zij is niet zichtbaar, maar de effecten kunnen gevoeld worden. Macht wordt vaak omschreven als de potentiële mogelijkheid van een persoon of afdeling om invloed uit te oefenen op andere personen of afdelingen om een bepaalde taak uit te voeren of om dingen te doen die deze personen of afdelingen anders niet zouden doen. Andere definities benadrukken dat het uitoefenen van macht de vaardigheid is om doelen of resultaten te bereiken zoals de machthebbers dat willen. Omdat organisaties gericht zijn op de realisatie van doelstellingen is het behalen van gewenste uitkomsten de basis voor de definitie van organisationele macht. Ook dient de potentie om invloed op anderen uit te oefenen een element te zijn. Op basis van deze overwegingen is de volgende definitie geformuleerd ([Knot07]):

Organisationele macht is de mate waarin een persoon of afdeling in een organisatie anderen kan beïnvloeden tot het realiseren van gewenste resultaten.

Kern van deze definitie is de mogelijkheid om invloed uit te oefenen. Deze beïnvloeding kan gebaseerd zijn op het hebben van specifieke kennis of expertise van een bepaalde persoon, terwijl deze kennis of expertise niet bij anderen aanwezig is.

De verschillende kenmerken waarop macht gebaseerd kan zijn, zijn samengevat in tabel 1. Op basis van deze kenmerken is het begrip macht geoperationaliseerd.

C-2009-2-knotters-t01

Tabel 1. Attributen van macht.

Samenvattend

Macht bestaat alleen in een relatie tussen twee of meer personen. Macht vindt vaak haar oorsprong in de onderlinge relaties. Als de ene partij afhankelijk is van de andere, ontstaat een machtsrelatie, waarbij de partij die de beschikking heeft over de middelen, bijvoorbeeld expliciete kennis van een ERP-systeem, de grootste macht heeft. Als in een relatie het machtselement aanwezig is, dan kan de bezitter van deze macht nakoming van zijn/haar wil bereiken. Naast macht is ook belang een factor waarmee rekening moet worden gehouden. In de volgende subparagraaf wordt de factor belang verder uitgewerkt.

Belang

Voor de inkadering van het begrip belang is een aantal specifieke kenmerken gehanteerd die zijn weergegeven in tabel 2. Belang kan gebaseerd zijn op een mogelijk nut of voordeel dat uit een verandering kan ontstaan. Dit voordeel kan liggen in een efficiëntere werkmethode of een meer doelgerichte, effectieve aanpak. Belangrijk is eveneens in hoeverre dit voordeel voor slechts één of meer personen aanwezig is. Indien meerdere personen baat hebben bij een verandering dan is het aannemelijk dat deze verandering meer prioriteit krijgt dan indien slechts één individu er belang bij heeft. Echter kunnen kleine individuele veranderingen vaak gemakkelijker doorgevoerd worden, zolang het groepsbelang er niet door geschaad wordt.

C-2009-2-knotters-t02

Tabel 2. Attributen van belang.

Belang kan ook gebaseerd zijn op het vergroten van het aanzien. Dit is het geval indien de verandering leidt tot een betere status of grotere waardering van de capaciteiten van één of meer personen. Indien een verandering ontwikkelingsmogelijkheden biedt aan een individu of groep, bijvoorbeeld door het vergroten van kennis en/of ervaring, dan kan dit eveneens een basis voor belang zijn. Ook kan belang afhankelijk zijn van de mate van veranderingsbereidheid. Indien iemand niet bereid is tot een andere werkwijze, dan zal het belang tot veranderen laag zijn. Ten slotte kan de persoonlijke verbondenheid met het collectieve doel de basis zijn voor het belang bij een verandering. Indien iemand zich sterk verbonden voelt met het gemeenschappelijke doel, dan zal deze persoon veranderingen eerder steunen dan iemand die geen band voelt met het collectieve doel.

Macht en belang in model

Het is belangrijk bij een veranderende situatie inzicht te hebben in wat de machts- en belangposities van verschillende stakeholders zijn en in hoeverre deze machts- en belangposities zich wijzigen als gevolg van deze verandering. In deze paragraaf worden voor het monitoren van deze verandering in macht en belang een algemeen en een uitgewerkt model beschreven.

Algemeen model voor macht en belang

Figuur 1 bevat een algemeen model voor de beoordeling van macht en belang van verschillende stakeholders.

C-2009-2-knotters-01

Figuur 1. Generiek model macht en belang van stakeholders (bron: [Jaco05]).

Met behulp van dit model zijn vier categorieën van stakeholders te onderscheiden en zijn verschillende strategieën te formuleren. Zoals uit figuur 1 blijkt, helpt een dergelijk overzicht om verschillende groepen stakeholders te herkennen. Bij deze groepen zullen verschillende strategieën gehanteerd moeten worden; zo zal men niet al te veel tijd besteden aan partijen die belang noch macht bezitten. Daarentegen is er juist aandacht nodig voor de kernspelers, degenen die zowel belang hebben bij een bepaald issue als veel macht bezitten.

Het generieke model voor macht en belang is niet alleen toe te passen op situaties met twee partijen, maar ook op situaties waarin meer dan twee stakeholders aanwezig zijn. Iedere stakeholder krijgt dan een bepaalde positie in de matrix. Tevens kunnen de machts- en belangpositie op verschillende momenten in de tijd in het model worden weergegeven. Vanuit de weergave van posities op verschillende momenten worden verschuivingen in de tijd zichtbaar. In figuur 2 is de machts- en belangpositie van drie verschillende stakeholders op twee verschillende momenten weergegeven. De pijlen geven de verandering van de posities in de tijd aan.

Zo is van stakeholder A de macht afgenomen, bij een gelijkblijvend belang. Dit kan bijvoorbeeld veroorzaakt worden door afname van de kennis op een bepaald gebied door delegatie van een bepaalde activiteit naar een ondergeschikte.

Bij stakeholder B is zowel de macht toegenomen als het belang, bijvoorbeeld door promotie en toename van de veranderingsbereidheid, omdat bij succesvolle afronding van een veranderingstraject een aanzienlijke bonus in het vooruitzicht is gesteld.

Bij stakeholder C is het belang toegenomen, terwijl de macht gelijk blijft, bijvoorbeeld doordat een nieuwe werkmethode een lastige klus vele malen makkelijker uitvoerbaar maakt.

C-2009-2-knotters-02

Figuur 2. Uitgewerkt model ontwikkeling van macht en belang in de tijd van verschillende stakeholders.

Uitgewerkt model voor macht en belang

Voor een casestudie (MKB-/familiebedrijf, ongeveer honderd medewerkers) zijn de veranderingen voor en na implementatie van een ERP-systeem in kaart gebracht. Dit betreft een middelgrote organisatie met discrete productie. Op basis van vragenlijsten en interviews zijn de situaties in kaart gebracht. Bij iedere vraag werd aan de stakeholders gevraagd een waardeoordeel te geven ten aanzien van een bepaald onderwerp. Deze onderwerpen gaan met name in op de attributen van macht en belang zoals onderkend in een vorige paragraaf. Als voorbeeld hebben we enkele bevindingen en scores uitgewerkt.

In figuur 3 zijn de machts- en belangposities van groepen van stakeholders, zowel vóór als ná de implementatie van het nieuwe ERP-systeem, weergegeven in het uitgewerkte model voor macht en belang.

C-2009-2-knotters-03

Figuur 3. Machts- en belangpositie voor en na implementatie.

Het uitgewerkte model voor macht en belang geeft inzicht in de machts en belangposities van de groepen stakeholders. In het model zijn de machts- en belangpositie van deze groepen van stakeholders op twee momenten weergegeven. Dit betreft de positie van macht en belang vóór invoering van het nieuwe ERP-systeem, alsook de positie nadien. Een pijl geeft de veranderingsrichting aan. Opgemerkt wordt dat de weergegeven posities van macht en belang indicatief zijn en derhalve niet een absolute waarde aangeven. Het geeft echter een goed beeld van de veranderingen. Hierin is een toename van zowel macht als belang van de verkoopfunctie waarneembaar. Bij de productiefunctie neemt het belang fors toe, maar blijft de machtspositie nagenoeg gelijk. Bij de restgroep is een kleine toename van macht en belang te zien. De mate van macht en belang, de veranderingen daarin als gevolg van invoering van het nieuwe ERP-systeem, evenals de verschillende kenmerken van macht en belang kunnen per groep geanalyseerd worden.

Voorbeeld vanuit de directie gezien

Mate van macht vóór invoering nieuw ERP-systeem

Deze analyse is gericht op de mate waarin de stakeholders in staat waren invloed op anderen uit te oefenen om een gewenst resultaat te bereiken in de oude werksituatie.

De gemiddelde scores die uit de vragenlijsten resulteren zijn weergegeven in tabel 3. In de tabel is de gemiddelde score voor de verschillende groepen van stakeholders vetgedrukt weergegeven. Ook is de standaarddeviatie vermeld en de gemiddelde scores die aan de groepen van stakeholders zijn gegeven. Zo bevat de kolom ‘Directie’ de gemiddelde score die door de directie aan de in de tabel genoemde groepen van stakeholders is gegeven.

C-2009-2-knotters-t03

Tabel 3. Relatieve machtsperceptie vóór ERP-implementatie.

C-2009-2-knotters-04

Figuur 4. Attributen van macht vóór invoering ERP.

Mate van macht ná invoering nieuw ERP-systeem

In de figuren 4 en 5 zijn de attributen van macht respectievelijk vóór en ná implementatie van het ERP-systeem weergegeven. Uit vergelijking van deze attributen is een goede analyse van wijzigingen in machtspositie mogelijk. Op gelijke wijze is dit in de casestudie toegepast op de attributen van belang.

C-2009-2-knotters-05

Figuur 5. Attributen van macht ná invoering ERP.

De onderlinge afhankelijkheid nam toe, wat inherent is aan het gegeven van integrale informatieverwerking die met een ERP-systeem bereikt wordt. Omdat binnen een ERP-systeem eenmalige vastlegging van gegevens beoogd wordt, neemt de afhankelijkheid van een juiste, tijdige en volledige vastlegging toe.

Hoewel het gezien het bovenstaande mogelijk is om de factoren macht en belang inzichtelijk te maken gedurende een ERP-implementatie, vindt dit op dit moment nog niet veel plaats. Wat kan nu de rol van de QA-functie zijn bij het zorg dragen voor een succesvolle ERP-implementatie? Een IT-auditor is inmiddels vanuit zijn rol vaak betrokken bij selectie- en implementatietrajecten.

Macht en belang en Quality Assurance

Tijdens een ERP-implementatie wordt in toenemende mate een onafhankelijke QA-rol ingevuld. Vanuit QA wordt de stuurgroep ondersteund in haar rol. Veel methodieken en aanpakken voor invulling van de QA-rol zijn inhoudelijk gericht. Deze gaan in op de toepassing van de implementatiemethodiek door leveranciers (bijvoorbeeld ASAP in geval van een SAP-implementatie). De ‘zachte’ kant met de menselijke aspecten, waaronder de factor macht en belang, wordt over het algemeen niet meegenomen. Dat terwijl het nu, ondanks alle professionaliseringsslagen in systemen en projectmanagement, erop lijkt dat met name ‘zachte’ factoren de oorzaak zijn van het niet succesvol zijn van een ERP-implementatie.

Verandering rol IT-auditor

Zowel in selecties als in implementaties moeten de betrokkenen, en met name de QA-rol, rekening houden met de factoren macht en belang. Immers, voor een goede acceptatie van de keuze van het systeem moeten alle stakeholders met enige vorm van macht/belang worden betrokken en overtuigd. Hiermee wordt de basis gelegd voor een succesvolle implementatie. Tijdens de implementatie zal de QA-rol, bijvoorbeeld door middel van periodieke metingen, de machts- en belangpositie in kaart moeten brengen en beoordelen of aan de relevante stakeholders voldoende aandacht wordt geschonken c.q. of deze stakeholders volledig gecommitteerd zijn aan het succes van het project.

Ter illustratie: in de casestudie kon een aantal oorzaak-gevolgrelaties worden herkend vanuit het perspectief van macht en belang bij een ERP-implementatie. Deze zijn samengevat in tabel 4 en enkele hiervan worden toegelicht.

C-2009-2-knotters-t04

Tabel 4. Oorzaak-gevolgrelaties invloed ERP-implementatie op macht en belang.

Centralistische besluitvorming leidt tot uitsluiting van groepen van stakeholders bij uiteindelijke keuze en geeft aanleiding tot weerstand

Het niet betrokken zijn bij de uiteindelijke besluitvorming is aanleiding geweest tot het vormen van weerstand tegen het genomen besluit. In het voorbeeld uitte dit zich in het lage belang van de overige stakeholders vóór invoering van het nieuwe ERP-systeem.

Onbalans in belang leidt tot weerstand

Van een groep stakeholders met een lage machtspositie is niet te verwachten dat deze het initiatief neemt op cruciale momenten. Is de machtspositie groot en het belang laag, dan leidt dit onvermijdelijk tot stagnatie in het implementatieproces. Pas als blijkt dat invoering van het nieuwe ERP-systeem onafwendbaar is, stijgt het belang en worden prioriteiten gesteld tot het oplossen van openstaande punten.

Afhankelijkheid van systemen beïnvloedt belang

Het belang in een goede werking van het nieuwe ERP-systeem stijgt sterk indien het onmogelijk is om op het oude systeem terug te vallen. Dit was in de case vooral het geval voor de productiefunctie, die na het conversiemoment genoodzaakt was de hoogste prioriteit toe te kennen aan het oplossen van nog uitstaande problemen. Andersom blijkt ook het geval: indien de oude systemen nog bestaan, blijft de noodzaak laag om over te stappen. Dit is in de case het geval bij de verkoopfunctie, die de productconfigurator gebruikt naast de vertrouwde calculatiespreadsheets. Het moment van ingebruikname van een nieuw ERP-systeem en het moment van buiten gebruik stellen noodzaakt tot een zorgvuldige afweging van de voor- en nadelen en is afhankelijk van de specifieke omstandigheden in de betreffende organisatie.

ERP-implementatie vergroot de kennis maar ook de afhankelijkheid van de betreffende stakeholders

ERP-implementatie biedt ontwikkelingsmogelijkheden aan de medewerkers. Uit het onderzoek blijkt dat veel medewerkers ontwikkelingsmogelijkheden zien en daardoor een groot belang hechten aan de invoering van een nieuw ERP-systeem. Vooral bij actief bij de ERP-implementatie betrokken medewerkers is een toename van de macht uit kennis waarneembaar. Keerzijde van deze kennisvorming is dat deze specifieke kennis slechts in het bezit is van enkele personen. Indien deze kennis niet vastgelegd is in procesbeschrijvingen, handleidingen en werkinstructies kan bij afwezigheid of vertrek van deze medewerkers de opgedane kennis voor de organisatie verloren gaan.

Conclusies

De invloed van ERP-implementaties op de machts- en belangpositie in een organisatie is evident en mag niet worden onderschat. ERP-implementaties zijn niet alleen technisch gericht, maar hebben een wezenlijke invloed op de onderlinge interactie. Deze invloed is zelfs zo groot dat een effectieve ERP-implementatie noodzaakt tot een organisatieveranderingsproces. De QA-rol kan nog meer toegevoegde waarde hebben als hij/zij zich bewust is van deze machts- en belangfactoren en daarmee rekening houdt tijdens de uitvoering van zijn werkzaamheden. Het voorbeeld zoals uitgewerkt zou periodiek opgesteld kunnen worden, waarbij de verschillen geanalyseerd worden en waarbij wordt beoordeeld in hoeverre de veranderende machts- en belangenverhoudingen tijdens de ERP-implementatie voldoende onderkend worden.

Literatuur

[Daft01] R.L. Daft, Organization Theory and design, Thomson learning USA, 2001.

[Finc92] R. Fincham, Perspectives on Power: processual, institutional and ‘internal’ forms of organizational power, Journal of Management Studies, 1992/6.

[Hoog03] J.P. Hoogstra RE en R. Vermeulen RE, Inrichting en uitvoering van Quality Assurance bij ERP-implementaties, IT-auditor als het schaap met 5 poten, EDP-auditor 2003/2.

[Jaco05] D. Jacobs, Strategie, leve de diversiteit, Pearson Education Benelux, Amsterdam, 2005.

[Knot07] N. Knotters, Invloed van ERP-implementatie op macht en belang, afstudeerscriptie Rijksuniversiteit Groningen, 2007.

[Wit04] B. de Wit en R. Meijer, Strategy, Process, Content, Context, an international perspective, Thomson Learning, 2004.

Older posts
Newer posts